Managing User Groups through ACLs
Working for 1.1.5.3 (according to author) to 1.3.6(latest)
There is already a proposal for this at GroupManagement. However this code doesn't seem to work anymore.My solution
I though about a simpler way to deal with User Groups - my concept is: Give the power to the users and Keep it simple.- The idea is that anyuser could define a new group by creating a dedicated WikiPage: something like MyProjectGroup.
- Then he would write in this page all the user logins he wants to be part of the group (embeded inside plus signs to avoid confusions: +UserLogin1+UserLogin2+).
- He would decide through the ACLs of this page who can manage the group list.
- Then he may use this page name in the ACLs of any page in order to manage the access authorizations.
- The only code needed should be that HasAccess() function has to be modified in order to search if the user is part of the group or not.
Dependency
None that I can figure out. I have it working with 1.1.5.3 version.The code
In wikka.php add the isGroupMember() function (after TrimACLs() function for example):(for version 1.1.6.2, the required file has beem moved and renamed to ...../libs/Wakka.class.php )
// returns true if $who is member of $group
function isGroupMember($who, $group)
{
$thegroup=$this->LoadPage($group);
if ($thegroup) {
$search = "+".$who."+"; // In the GroupListPages, the participants logins have to be embbeded inside '+' signs
return (boolean)(substr_count($thegroup["body"], $search));
}
else return false;
}
function isGroupMember($who, $group)
{
$thegroup=$this->LoadPage($group);
if ($thegroup) {
$search = "+".$who."+"; // In the GroupListPages, the participants logins have to be embbeded inside '+' signs
return (boolean)(substr_count($thegroup["body"], $search));
}
else return false;
}
Then change HasAccess() function:
from:
// aha! a user entry.
default:
if ($line == $user)
{
return !$negate;
}
default:
if ($line == $user)
{
return !$negate;
}
to:
// aha! a user entry.
default:
if ($line == $user)
{
return !$negate;
}
// this may be a UserGroup so we check if $user is part of the group
else if (($this->isGroupMember($user, $line)))
{
return !$negate;
}
default:
if ($line == $user)
{
return !$negate;
}
// this may be a UserGroup so we check if $user is part of the group
else if (($this->isGroupMember($user, $line)))
{
return !$negate;
}
How to use it?
Create a WikiPage to manage a particular user group: a name like UserGroupWikkaCrew makes sense (it exists ;-) ), it could be nice to link to a CategoryUserGroup.Write in all the user login that have to be part of this group inside "+" signs: +UserLogin1+UserLogin2+ is valid as would be:
- +UserLogin2+.
Use the UserGroupPage in any ACLs, they can be can be negated using the "!" character as usual.
To Do
My code needs probably to be reviewed by expert coder as I am not at all a developer (I just rely on the above user group).Any ideas and comments than welcome.
This does not allow to manage Groups of Groups (don't think about using the {{include}} action!)
- This doesn't really make sense, because u can add it as a subgroupe using his page/groupname, no ?
- Correct. I'm using this to control access on my intranet and I've got multiple layers of groups (many that cross over) that allow me to manage groups of groups. Here's how I'm using it:
- Group 1 (UGMetro) has several names: +Reporter1+ +Reporter2+ +Reporter3+ +MetroEditors+
- Group 2 (UGSports) has others: +Reporter4+ +Reporter5+ +Reporter6+ +SportsEditors+
- And the master group (UGNewsroom) looks like this: +UGMetro+ +UGSports+
- Works just fine for me. :) --MovieLady
- Could not get it working with master groups as described by MovieLady, so I changed the IsGroupMember function to recursivly go through all sub groups:
-
// returns true if $who is member of $group
function isGroupMember($who, $group)
{
$thegroup=$this->LoadPage($group);
if ($thegroup) {
preg_match_all("/\+(\V*?)\+/",$thegroup["body"],$group_members);
foreach ($group_members[1] as $group_member) {
if ($who == $group_member) { return true; }
if ($this->isGroupMember($who,$group_member)) { return true; }
}
}
else return false;
}
- Does anybody have an idea why the setup described by MovieLady should work? I my setup members of the Group UGMetro or UGSports did not have access to pages where the read/write acl's were set to UGNewsroom
Security Risks
A hacker may be able to get unauthorized access if they create a new user account with the same name as a groupname. For example, in the above scenario, the hacker may gain unauthorized access if (s)he creates a user with "UserGroupWikkaCrew" as the login name. The easiest way to prevent this from happening is to disallow new users to pick a name which is equal to an existing page.
- This check is already in place as of version 1.1.6.0. --JavaWoman
CategoryUserContributions
http://wackowiki.com/WackoIdeas/show?time=2005-07-13+22%3A38%3A17#h4057-32
One thing I'd like to see in conjunction with this functionality (and I might hack together something if time permits): Pages in the index should be displayed only if they are actually readable by the current user. It's not very nice to lead users astray by enticing them with a page, only to be told they can't access it!
You should know we are nearly sold on going with tiki-wiki because of the number of tools available, but I like that you are using Java, your confirming to standards, speed… and what our team to at least take a look at Wakka.
Thanks, Anthony
AdminGroup (r/w/c = JackBlack)
+JackBlack+
TechGroup (r/w/c=AdminGroup)
+NaomiWatts+
TechSubGroup (r/w/c=TechGroup)
+TechGroup+
+AdrienBrody+
etc...
ie:
+GroupName+
YaVerOt
not:
GroupName
YaVerOt
We haven't tried negating a goup yet to see how that is done.
The oddity: When reading or editing pages all is well. But when I try to create a page, Wikka tells me I had no write access. The oddity is, I can edit all the pages where the default ACLs apply, thus it can't be some problem with the default settings.
My Settings are:
READ: *
WRITE: SpielerACL (consisting of lots user names and another group)
COMMENT: +
My test user is in the sub group of SpielerACL. As I told, editing existing pages works great but creating new pages is not possible.
What I don't understand: How comes, that subgroups are checked against? I worked through the code but cannot see any place where groups are checked recursively. Furthermore: How is circular subgrouping handled?
...
GREAT ERROR OF STUPIDITY! AARGH!
Okay, checked once more:
Editing pages with the default ACLs doesn't work. Why? Because the subgroup is not checked against. Why should it, there's no code there for doing it! The editing of pages worked, where the subgroup itself has been put into the WRITE list.
What was puzzling me was YaVerOt's problem all the time. Now I tried editing a page with the same ACLs as a new page would have -- the default ACLs. Et voilà! I can't. In the ACLs I put the group name in plus signs and it worked, I could edit the page. It even works if I put only one plus sign in front of the group name. It does not work if I put the plus sign behind the group name. And --what evil sorcery might this be-- it works if I put a single plus sign in a line of itself!
Might someone check the function HasAccess? I guess, there are some bugs in it. At least this 'preceding plus sign treated as a plus sign on a line of itself' bug is dangerous for people experimenting with the ACLsWithUserGroups.
YaVerOt, it should work without plus signs. If it doesn't, take them away nonetheless. Any registered user might read or write if they are in there.
Defaults used on a used and much tested system:
'default_read_acl' => '*',
'default_write_acl' => '!WikiGroupRestrictedUsers'."\n".'+',
'default_comment_acl' => '!WikiGroupRestrictedUsers'."\n".'+',
One page looked at with modified ACLs;
Read ACL: *
Write ACL: !WikiGroupRestrictedUsers
WikiGroupFAQdevelopment
WikiGroupModerators
WikiGroupAdministrators
Comment ACL: !WikiGroupRestrictedUsers
+
The "+" itself is enough to satisfy the "check" for page permissions .. as shown above, the requirement just isn't seen for "surrounding" the name in the ACLs
On the other hand, surrounding the name is required for the names placed on the Group "control" page .. maybe this is the confusion???
For example, a snippet of the 'contents' of the WikiGroupFAQdevelopment 'page' shows the names surrounded:
+TestFAQdevelopmentUser+
+WikiGroupModerators+
User names do have plusses around them on the group defining page.
(It appears to ignore user groups, I will check with the owner/admin to see if he put in the patch right... unless there is a way for the user to tell other than "it just works")
IIRC this is the only patch/change we've applied to " Wikka Wakka Wiki 1.1.6.2" running on a Mac OS X machine.
My previous examples shows how things are installed (and working) on the site I run ... note the lack of the '+' in the ACL lists other than the single character under the 'Comment' section .... signifying "Only Registered Users"
As I tried to show, the '+' characters in this Mod are basically only needed to surround the entries on the list of names placed on the 'access page' ...
So since we edited GroupPage right, the mis-applied code didn't find the valid users in the +s.
We now have it working right.
Now on my 'defeating usergroups' statement:
In ACL boxes, every example shows one User, UserGroup, NotUser, or NotGroup per line.
So treating the string "+UserGroup+" as the string "+" is wrong. The entire line is a single command.
If the line:
!YaVerOt WazoO
appearing in an ACL box, what would Wikka do? What Should it do?
1. Nothing the space makes "YaVerOt WazoO" an invalid user name
2. Block YaVerOt and ignore whatever " WazoO" means
3. Block YaVerOt & block WazoO
4. Nothing, Wikka sees the invalid "!YaVerOt WazoO" and doesn't allow the ACLs to be updated.
It would only be a user error if the documentation clearly indicated that "Any line starting with a + or * will be treated as only having a + or * on it"
It may be a documentation error, or a coding error; since the two don't match.
I'll assume documentation error and change the page ACLInfo right now. Hopefully the clairification will be present in 1.1.6.3 since the other feature we want is no longer accessable as a patch but will be standard when that version comes out.
Anyway, my problem is fixed. You can treat my other comments as a thought experiment if you wish.
Thank you for helping me find the problem in my install.
Basically, in the existing codebase, the ACL data is one item, followed by a 'new line' with the second item on the next line .. another 'new line' and a third item .. etc. if needed .... Your issue, experience, example, and question boils down to trying to place multiple items on a single line ... the existing codebase doesn't handle that ... so if I had to guess at an answer right now, the answer to your question would be your listed item #2 ....
Appearances are that future codebase will handle this whole matter differently, assuming Brian's suggested approach gets accepted into that codebase. ???? I believe that the existing documentation does match the existing codebase, although noting that there are assumptions made .... that said, I'll try to locate the ACL information page and see what it says now ... been way too long (for me) to remember exactly where the 'instructions' are actually ... Updated http://wikkawiki.org/ACLInfo
It's sometimes hard for me to point to some simple things here, as I've had to modify my install so much ... it's hard to remember what's 'default' and what I've 'fixed' .... which also has it's ramifications when the next codebase version gets made available .... which of my changes are now part of the base install, which ones work differently, how do I have to modify that 'new' version to then also use the other changes made to the previous running version ... read that as a major headache at times .... it might not be so bad, but this isn't the only application I've got running that has this issue.
Glad you for it working and running!
I would need to do some re-testing, but my experience was that nested groups did not work. To get around that, one had to list all groups individually in the ACL's
Example:
John is a member of GroupAdmin
GroupAdmin is a member of GroupModerator
If GroupModerator is added to the write ACL of TestPage, then all members of GroupModerator will have write access to that page including GroupAdmin but NOT including the members of GroupAdmin. If GroupAdmin is also included in the write ACL list of TestPage, then John would have write access. So unless John is also a member of GroupModerator or included in the ACL write list of TestPage in some other way, such as being a member of another listed group which would include all users if + was included in the ACL list, John would not have write access to TestPage solely based on his membership in GroupAdmin
Not truely understanding the code, I don't see how it detects a nested group to check to see if UserX is part of that other group.
WazoO - thank for explaining how Wikka currently (1.1.6.2) works. Although basic coding should say 'is string "+" ' not 'is next char "+" ' unless + is the delimiter between commands. I've been surfing in multiple tabs so I see this (ACL storage & handling) is a core issue for whenever 1.1.7 comes out. Maybe when I get my development environment up again I'll learn some {whatever language Wikka is in} and help instead of pointing out appearent flaws.