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

[Joachim Durchholz]

Patrick R. Michaud wrote:
> On Tue, Apr 12, 2005 at 11:54:46AM +0200, Joachim Durchholz wrote:
> 
>>> There is an (:if auth ...:) conditional markup available for 
>>> processing depending on the current authorizations in effect. 
>>> [...] This should be very useful in creating action buttons.
>> 
>> This sounds as if (:if auth <action>:) is designed to work now and
>> in the future - good.
> 
> 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?

>> When repeating multiple "id:" tags becomes cumbersome, it's the
>> right time for implementing user groups ;-)
> 
> 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 :-)

>> I'd also like to have exclusion and inclusion facilities. I.e.
>> every blank-separated entry in the authentication string is meant
>> to add to the pool of allowed users, except when it's prefixed with
>> a "-" in which case it subtracts.
> 
> The authorization string already works in exactly this way -- each 
> "id:" statement adds to the pool, and a "-" denies access.

Ah, very good.

> One restriction of the current implementation is that any denials
> need to come first in the authorization string (I may change this
> to allow them anywhere).

Please do.

>> All administrators except "HansB" (sorry Hans *gg*):
>>   grp:admin -id:HansB
>>
>> All administrators except "HansB", and all contributors:
>>   grp:admin -id:HansB grp:contrib
>>
>> Note that the previous example will let HansB in regardless if he 
>> happens to be in group "contrib". If that's not what's wanted, say
>>  grp:admin grp:contrib -id:HansB
> 
> Ouch, these last two examples makes my head hurt (plus I had to
> re-read it three times to understand what you were saying).  
> I don't think anyone would've expected your last example to
> allow HansB in. 

The last one does *not* allow HansB in. It's the second-to-last one.

> I much prefer to just read left-to-right, taking the first condition
> that matches.
> 
>    id:-HansB grp:admin                   # always deny HansB access
>    grp:contrib id:-HansB grp:admin       # allow HansB access if he
>                                          # is in contrib, deny otherwise

Your perspective is: "Given a user, is he authorised?"

My perspective is: "Given an action, what groups of users are authorised?"

No headaches needed to interpret the examples; again:

"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).


I have a strong intuition that the two perspectives are complements of 
each other.
Take an authorisation spec and reverse the items, and you get a spec for 
the other perspective.

>> 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).

>> Some additional considerations: We could say "group:" and "user:"
>> instead of "grp:" and "id:".
> 
> 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.

The correct term for "user" would be "account", but that's too long ;-)

>> Not sure whether having a singular or a plural name would be
>> better. Since user groups will most likely end up with wiki pages
>> of their own, the group names should probably also wikified (i.e.
>> initial capital letter); I'm leaving the examples in all-lowercase
>> here because I'm lazy :-)
> 
> A specific design criterion is that authorization and group
> membership could be specified using systems that don't have anything
> to do with wiki, so the authorization code doesn't (won't) make any
> such assumptions.

Ah, I didn't think of that.

Regards,
Jo