[pmwiki-users] pmwiki-2.0.beta29 out, needs testers and feedback

[Patrick R. Michaud]

On Wed, Apr 13, 2005 at 01:50:17PM +0200, Joachim Durchholz wrote:
> >Well, it doesn't entirely work yet, since the list of actions
> >is not identical to the set of authorizations.  I haven't yet decided
> >if it will be useful/helpful to have a separate (:if action <action>:)
> >condition that is true if <action> exists and the user is authorized
> >for it.
> 
> How does the list of actions differ from the set of authorisations?

actions:  edit, post, attr, postattr, upload, postupload, rss, rdf,
          refcount, source, browse, publish, diag, phpinfo
authorizations: read, edit, attr, upload, admin

> >Sure, but I'm not sure how groups will (should) be administered. One
> >step at a time, please.  :-)
> 
> Just *design* for groups in the future :-)

Hmm, am I somehow chronically guilty of *not* designing for the future
in PmWiki...?  :-)

> "grp:admin -id:HansB" takes group "admin" and removes user "HansB" from 
> that - what remains is the set of authorised persons.
> "grp:admin -id:HansB grp:contrib" takes group "admin", removes user 
> "HansB", then adds group "contrib".
> "grp:admin grp:contrib -id:HansB" takes groups "admin" and "contrib", 
> then removes "HansB".
> 
> I (somewhat boldly) maintain that whoever sets up the permissions for an 
> action is thinking in terms of user groups, not in terms of a sequence 
> of actions to determine whether a user is allowed (which he would have 
> to mentally translate to the user group perspective to check whether 
> that specification is doing what he wants).

Well, even in your example the admin has to think in terms of a
sequence of operations (add this group to the set, remove this user,
now add this other group, now remove these users...).  This just
convinces me that we shouldn't have any sort of "add/subtract"
operations, and just say that if "id:-HansB" appears anywhere in the
string then HansB is excluded.  (Sorry, Hans! :-)

> >>All anonymous users:
> >>  grp:guests
> >
> >This is already covered (at much less cost) by a blank authorization
> >string.
> 
> A blank string allows both anonymous and logged-in users.
> I meant grp:guests to mean anonymous users only. Some actions are just 
> for anonymous users and anonymous users only; e.g. the "register" action 
> isn't for logged-in users, some sites may want to differentiate between 
> a "login" action (anonymous guests only) and a "re-login" action 
> (logged-in users only).

I understand your desire to look at this in terms of actions, but
it's really *not* the same.  These specifiers are given in the
Page Attributes page, which (at least for now) allow us to specify
"read", "edit", "attr", and "upload" authorization levels.  Each of these
levels are actually used for a number of actions, not a single one.
I don't think we want to require admins to set password strings
for each individual *action* (browse, edit, rss, rdf, refcount, diag,
etc.) because it quickly gets too tedious to do so.

So, your example illustrates the difference well -- where exactly
would you expect a site admin to specify "grp:guests"?  Clearly
it's not likely to go into one of the existing page attribute, 
unless we somehow want reading/editing of pages to be performed 
only by people who haven't logged in.  (OTOH, I can see some benefits
to a purely action-based model -- I'll think about it a bit more.)

At any rate, for the rare case where it might indeed be desirable to
allow only non-logged-in users, a better specification is probably 
"id:-*" instead of "grp:guests".

> >Well, I probably would never choose "grp:" -- my preference at
> >this point is "group:" and "id:".  But I'll switch to "user:" if
> >there's a strong sentiment that direction.  I prefer "id"; the
> >PmWiki internal variable is $AuthId and what we're discussing are
> >indeed identifiers and not users.  OTOH, I guess that most people
> >are so conditioned to think "user:" that I'll have to play along.
> >Cast your votes now.  :-)
> 
> I'm somewhat opposed to "id" because the term could be applied to groups 
> and users.

Well, in the interest of "designing for the future" :-) , I wasn't 
excluding the possibility that an id could be applied to groups.  
In some sense it becomes very nice to be able to say "id:admins,HansB" 
and not have to worry about which is a group and which is a user.  
(Especially if we at some point use wiki pages in Profiles/ to create and
maintain the group memberships.)  I'm not saying we'll go this route,
but I'm not ready to exclude this possibility yet.

Pm