[pmwiki-users] pmwiki-2.0.beta29 out, needs testers and feedback
Joachim Durchholz
jo at durchholz.org
Wed Apr 13 06:50:17 CDT 2005
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
More information about the pmwiki-users
mailing list