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

Patrick R. Michaud pmichaud at pobox.com
Tue Apr 12 08:21:20 CDT 2005


On Tue, Apr 12, 2005 at 11:54:46AM +0200, Joachim Durchholz wrote:
> >Because of this, passwords cannot contain
> >spaces (I hope this won't be a major loss -- let me know if it will).
> 
> It isn't for me, but in some circles, pass phrases are en vogue.

Yes -- I may change this at some point to allow quoted passwords.

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

> I'm a bit adverse to having both 'id:alice,bob,carol' and 'id:alice 
> id:bob id:carol'. Multiple syntaxes are just too good at confusing users 
> and the software likewise. Given that checking whether authentication 
> works as expected is difficult, I'd like to have the mechanism as simple 
> as possible.

The programming is much simpler to allow both syntaxes than to try
to restrict it to one.

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

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

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

> All anonymous users:
>   grp:guests

This is already covered (at much less cost) by a blank authorization
string.

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

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

Pm



More information about the pmwiki-users mailing list