01232: AuthUser: groups included in other groups
Description: Feature request split from PITS:01201 Excluding members from AuthUser groups doesn't work.
From Eemeli Aro:
Thinking on this a bit more, it is actually possible to get a key starting with '@' into $auth, by including the following in SiteAdmin.AuthUser:
@fruits: @apples, @oranges
At the moment, this does nothing -- but it would only take a minor addition to make this work, at least one level deep; instead of the patch above, use the following:
Index: authuser.php
===================================================================
--- authuser.php (revision 2560)
+++ authuser.php (working copy)
@@ -79,12 +79,14 @@
$authlist[$g] = 1;
foreach(preg_grep('/^@/', (array)@$auth['*']) as $g)
$authlist[$g] = 1;
- foreach(preg_grep('/^@/', array_keys($auth)) as $g)
- if (in_array($authid, $auth[$g])) $authlist[$g] = 1;
if ($auth['htgroup']) {
foreach(AuthUserHtGroup($pagename, $id, $pw, $auth['htgroup']) as $g)
$authlist["@$g"] = 1;
}
+ foreach(preg_grep('/^@/', (array)@$auth["-$authid"]) as $g)
+ unset($authlist[$g]);
+ foreach(preg_grep('/^@/', array_keys($auth)) as $g)
+ if (@$authlist[$g] > 0) foreach($auth[$g] as $h) $authlist[$h] = 1;
SessionAuth($pagename, array('authid' => $authid, 'authlist' => $authlist));
}
Then, the following in SiteAdmin.AuthUser:
alice: HASH @apples bob: HASH @fruits @fruits: @apples, @oranges
Would let both alice and bob be members of @fruits.
The documentation for AuthUser just gave the example of excluding Fred, but didn't describe the concept - so I'm not sure what would be a "bug". In theory can we define groups by reference to groups? (That would reduce the risk of user error.) For example:
@wholeoffice: *
@managers: Fred,Susan
@nonmanagers: @wholeoffice,-@managers
RandyB July 07, 2010, at 12:07 AM
I fear that single-level user-subgroups may not be enough for some admins, or may be confusing - and that we should either implement full multi-level recursive subgroups, or not at all. Let's think about it and see if many existing wikis really requre this feature. --Petko November 10, 2010, at 05:43 PM
Moreover, with @group1: @group2 it is not clear which group is a "member" of the other, otherwise which is parent and which is child. Currently both @group: user and user: @group mean that user is member of @group. --Petko November 11, 2010, at 01:54 AM
The question to me is not whether many existing wikis need this feature, but what doors does the feature open to encourage new websites. For example, without the feature, I find it hard to visualize administering a website that allows 5000 @writers and 500 @moderators. So yes, someone who wants to build such a site will not do so. Consequently, no existing site will need the feature.
You could treat every @group that is defined to include another @group as a parent, regardless of whether it is also defined as a child.
I assume that during login, PmWiki parses each line in Site.AuthUser, or wherever the information is stored if elsewhere, building a set of authorization groups for the person who is logging in. You probably know a smarter way to do this, but off the cuff I would think something like the following would work:
While parsing each line, whenever you see a group referencing another group (e.g. @editors: id:person, @writers), you could check the groups added to the person's set so far to see if the referenced group (@writers) has already been encountered. If it has been, you would add the referencing group ("parent"), and every known parent of it to the person's authorization group set. (You could keep a separate list of groups and their children encountered so far for this purpose.) At the end, the person should have every appropriate group in the list.
While the admin could make errors more easily due to the indirection, the code that has to be foolproof is just any @group definitions that include other @groups. Hopefully such errors will be semantically obvious.
If I define id:me as a member of @writers, and @writers as a child of @trusted, and @trusted as a child of @admins, then yes I will have admin authorization by virtue of being a trusted writer. Any admin who defines person as "trusted" needs to know the implications of doing that. If by "trust" you don't mean "administrative level trust", then don't make "@trusted" a child of "@admins".
-- RandyB November 18, 2014, at 05:01 PM
With the useradmin recipe under renewed development, there is now more need for this feature.
PmWiki's lack of tools for user administration makes it hard to have a large number of accounts. (Especially needed is self-registration and password self-change functionality.) When a site has thousands of accounts, it can be burdensome on admins to do the permission updating. But trusting users to edit the AuthUser page isn’t always feasible.
Allowing indirect group memberships could facilitate the creation of user admininstration recipes that make PmWiki more feasible for use on certain types of large sites. Large sites are good for the community, because they bring in lots of users, some of whom in turn want to create their own sites.
Currently PmWiki requires explicit membership in all authorization groups. When the relationship is hierarchical, or has some kind of logic, this requires redundant work, is error prone, and makes it harder to make changes.
A static approach to allowing indirect memberships makes the most sense to me:
@admins: @powerusers, @moderators @moderators: @writers @admins: id:me @powerusers: id:smartie @moderators: id:trusteduser @writers: id:noviceuser
Then if I am a member of @admins, I am also automatically a member of @powerusers and @moderators. Being a member of @moderators in turn makes me a member of @writers. I don’t have to add or remove my name for all three groups.
However, if it's easier to implement, a dynamic mechanism for setting group membership would actually provide greater power, though at the risk of creating greater confusion:
(:if authgroup @admins:) (:join @writers:) (:ifend:)
If the above were only functional on the SiteAdmin.AuthUser page, it might work without causing too much confusion.
Regarding the question of which group belongs to which:
@group1: @group2 -- means to me that all members of @group2 are members of @group1. It says nothing about who belongs to @group2. It's parallel to the syntax for PTVs or wikistyle definitions. This doesn't in any way change the existing syntax. @mygroup: id:Jane means that "Jane" is a member of "@mygroup". The reverse was never true.
-- RandyB September 23, 2015, at 07:37 PM
According to PmWiki:AuthUser#auth_groups both @mygroup: Jane and Jane: @mygroup are acceptable (not id:Jane). --Petko September 24, 2015, at 01:24 AM