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.

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;
    }


Then change HasAccess() function:

from:

                                                   // aha! a user entry.
                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;
                    }


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: Modify the ACLs of this UserGroupPage to reflect who is allowed to manage the group.
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!)


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.

CategoryUserContributions
Comments [Hide comments]
Comment by MovieLady
2005-01-18 03:57:59
This works beautifully, thank you!
Comment by FreekDijkstra
2005-03-01 18:00:44
Just letting you know that I think this is a simple and reasonably good way to maintain user groups. I think it should be implemented in a future release of Wikka.
Comment by NiehLe
2005-03-03 15:49:32
Then please leave a note at WikkaDevelopment, too. So that it's not forgotten and there is a better place for discussions.
Comment by JavaWoman
2005-07-14 08:59:43
I found an interestng idea that could be used as an extension to this here:
http://wackowiki.com/WackoIdeas/show?time=2005-07-13+22%3A38%3A17#h4057-32
Comment by TonZijlstra
2005-09-10 12:39:19
Works fine! Would also suggest it being added to a release of Wikka.
Comment by DarTar
2005-09-10 17:58:12
It is actually among the candidate features for the next release ;)
Comment by TonZijlstra
2005-09-11 10:49:17
cool!
Comment by MasinAlDujaili
2005-09-12 20:05:00
@JavaWoman: I already had the idea of inheritance, but the additions are also interesting. Indeed, I came here looking if grouping of groups might be possible or inheritance of ACLs. Might be a good idea to contribute.
Comment by BrianKoontz
2006-01-15 03:16:53
Works fine for me as well...there's something to be said for simplicity. Too often, people assume that functionality must equate to complexity. I think this is a very elegant solution, and hope it makes the cut for the next major Wikka release.

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!
Comment by AnthonyPetrillo
2006-04-04 13:38:31
NilsLindenberg pointed me to this page. I am an old programmer gone bad (administrator now) and I'm doing some of the searching as our team looks for a wiki community to join. We are approaching it from both the user perspective and the programming and system support perspective. We had designed a tool that we planned to use for our system, but decided to explore the wikis to see if we could do something collaboratively. Anyway, a key issue for us is empowering the user so they can have their own "sphere of influence" as we call it. This includes being able to add users and give them administrative power over a sphere, where they can add users and give them administrative power over a sphere. etc. Typically the spheres would be subsets, but not always. I will not go into more details, but the above sounds like this make be a direction you are going. Being new to this wiki process, I'm curious how I found out how serious you area about this direction?

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
Comment by BrianKoontz
2006-04-04 13:58:16
Actually, this is easily done with group ACLs in Wikka...by controlling the ACLs in individual groups, you can build a "hierarchy" of groups, with the top-level group controlled by an admin:

AdminGroup (r/w/c = JackBlack)
+JackBlack+

TechGroup (r/w/c=AdminGroup)
+NaomiWatts+

TechSubGroup (r/w/c=TechGroup)
+TechGroup+
+AdrienBrody+

etc...
Comment by YaVerOt
2006-11-15 22:24:24
We've added this to the wikka wiki we're using, one thing that isn't clear in the directions is that when editing ACLs, you need to still use the plus signs around the group name for it to work.
ie:
+GroupName+
YaVerOt
not:
GroupName
YaVerOt

We haven't tried negating a goup yet to see how that is done.
Comment by MasinAlDujaili
2006-11-16 03:29:52
While trying to reproduce YaVerOt's problem, I came across some oddity. But first: I couldn't reproduce his problem. In my Wikka it works as described without any plus signs around the group names in the ACLs settings. I need them though in the Wiki pages.

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.
Comment by WazoO
2006-11-17 20:55:07
The on-screen data only shows the 'leading' characters as needed for the page ACLs ...

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+
Comment by YaVerOt
2006-11-18 13:56:44
Rechecked, the leading plus does allow all wiki users (defeating point of usergroups), removal of plus allows only admin and page owner.
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.
Comment by WazoO
2006-11-19 00:40:11
I disagree with the "defeating point of usergroups" statement a bit ... the leading '+' character is a stand-alone bit as far as the Wikka ACLs go .. so the code basically is happy (stops) as soon as it sees the '+' .... most places would tend to descibe this as "user error" due to mis-application of some data ...

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' ...
Comment by YaVerOt
2006-11-25 16:32:34
We applied the patch wrong. Appearently it was for =UserName= not +UserName+ on GroupPage.
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.
Comment by WazoO
2006-11-26 06:08:51
This is one of those confusion factor scenarios ... there is the original Modification 'here' ... there are Tickets in the Tracker that deal with many other changes to a number of handling issues ... for example, one specifically dealinf with ACL data storage and handling (the config file, the code reading and usage of that data, etc.) that Brian did up, code is in the SVN (perhaps for the 1.1.6.3 version?) ... but the next target release seems to be 1.1.7.0 ... so where all this sits is definitly up in the air.

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!
Comment by DbieL
2006-11-26 08:30:41
The one issue that still remains a bit unclear is that of nested groups.
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
Comment by YaVerOt
2006-12-22 16:30:10
User groups aren't nesting on my install either.
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.
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki