This is a static dump of issues in the old "Flyspray" bugtracker for DokuWiki. Bugs and feature requests
are now tracked at the issue tracker at Github.
Closed
Fixed
FS#2039 ACL and spaces
ACL & Authentication
2010-09-25Pontiac76
There seems to be a problem with the ACL authenticating against names that contain underscores or spaces.
Here is how to reproduce.
In the acl.auth.php file, add the following
* @ALL 1
users:%USER% %USER% 8
(Substitute my spaces for tabs, of course)
Have three regular users created with @USER access.
userA
userB
user_Space
When creating [user_Space] with an actual SPACE instead of the underscore, users.auth.php does get entered with an underscore in the name successfully.
As an admin user, create two pages to look at
users:usera
users:userb
Doesn't matter what the content is, so long as data exists.
Log in as usera. This user should have full access to do whatever they want in [users:usera] and should have read only access in [users:userb]. Same is reversed when logged in as userb. userb has full access to [users:userb] but has read only access to [users:usera]. This is expected and desired as per the ACL rules.
However, the story changes with [user_space]. Both pages [users:usera] and [users:userb] are fully modifiable by [user_space].
I've changed the auth.php file to spit out the $_SERVER variables and I don't see anything really wrong. When logged in, [REMOTE_USER] contains pontiac_76 which is expected.
2010-09-25Pontiac76
I went through and started looking at some of the code that is actually doing the authentication, specifically in auth.php and the function auth_aclcheck. I put an ECHO before and after the line:
[code]
$user = auth_nameencode($user)
[/code]
and found that it had changed $user from pontiac_76 to pontiac%5f76. Thinking this to be wrong, I commented out the $user assignment line, and refreshed the page. I then went to [users:usera] and had read-only access. I put the $user assignment back in, refreshed, and I had full access again.
So far, my thoughts lean towards that there isn't a problem with the actual authentication, but, more so with how the auth_nameencode is doing a blind conversion of all non-really-HTML friendly code to hex values.
At the moment, I don't know HOW leaving this line commented out is going to affect things elsewhere as of yet. Looking to see if I can band-aide at least prevent changing the underscore to a web-safe hex code.
2010-09-25Pontiac76
I should also comment that part of my testing involved using pontiac_76 to create a [users:pontiac_76] name space, and successfully have full access to it. I logged in as another non-admin user and have read-only access to [users:pontiac_76].
2010-09-25Pontiac76
Fixed.
In auth_nameencode, I changed both preg_replace parameters so that it skipped x5f.
Function is:
function auth_nameencode($name,$skip_group=false){
global $cache_authname;
$cache =& $cache_authname;
$name = (string) $name;
The problem is that there are different encoding mechanisms used in the ACL system and that auth_nameencode escapes characters that are not filtered/escaped by cleanID. %USER% is replaced by the username in the form it is accepted by the authentication system (it might even contain spaces!). Then in the regex the username is additionally escaped by auth_nameencode. Thus it no longer matches the value in %USER%. Now Pontiac76 has the following two rules:
* @user 8
users:* %USER% 1
As the second rule is not matched when auth_nameencode changes the username the first rule is the matching one and all pages in users: are writable. I propose the following changes:
- Escape the username that is inserted at the place of %USER% using auth_nameencode
- Don't escape characters in auth_nameencode that are valid page ids (e.g. . or _)
They should ensure that the acl string is still valid when the authentication system accepts strange usernames and that in every case %USER% is matched. And additionally they ensure that at least with the plain authentication system every user can have a matching page/namespace. I think an additional wildcard with the username cleaned using cleanID should be added in order to allow (possibly colliding) user pages in authentication systems that allow characters that aren't valid page ids (e.g. spaces) where the admin can accept collisions or knows they won't happen because e.g. every username is in the form first_name last_name and underscores won't occur.