[pmwiki-users] Rethinking passwords and authorization

[Américo Albuquerque]

Patrick R. Michaud wrote:
> I looking at how to provide a "list of all pages with
> passwords" capability, as well as a few other features, it
> occurs to me that *maybe* we should just revamp the entire
> password system we're using to become a little more regular.
> 
> At the moment things get a bit complex because we have three
> ways of authorizing access:
> 
>    - based on a password              ("secret_pw")
>    - based on an authenticated id     ("id:alice")
>    - based on membership in a group   ("@authors")
> 
> So, someone can use ?action=attr to set an edit password like:
> 
>     quick id:alice @authors id:bob
> 
> and this means that "alice", "bob", anyone in the "@authors" group,
> or anyone who knows the password "quick" is allowed to edit
> the page.
> 
> The above looks clean, but we start to run into difficulty
> when people expect to be able to mix the syntax at will:
> 
>     id:alice,bob, at authors quick
> 
This isn't really mixed syntax but aggregated syntax. The syntax is the 
same as before:
id:* for users, @* for groups and * for passwords
We're just joining together the same identifiers
id:alice,bob means user alice and user bob.

although you can have id:@group_name it would be simpler for the user if 
you just did @group_name

then you could use the same aggregated syntax for groups:
@group1_name,group2_name

The password could have comas on it because it wouldn't have an 
identifier (id: or @) attached. So, "password, with comas" would be used 
as is. The password could even have ':' and '@' on it as long the string 
didn't started with 'id:' or '@'.

> This gets very difficult for PmWiki to parse.  It will get worse
> when we try to allow userids with spaces in them:
> 
>     id:"Alice Adams", at authors,"Bob Barker" "multi word password"
> 
> or when we try to revoke access:
> 
>     @authors id:"Alice Adams",-carol,"Bob Barker"
> 
That is true if you want to parse it in just one step. You could do it 
in two steps.
1st step: parse the different entities:
   ent1: id:"Alice Adams", at authors,"Bob Barker"
   ent2: "multi word password"

2nd step: parse each entity according to it's type:
   ent1: type=id (we're setting an id based password), user "Alice 
Adams", group @authors and user "Bob Barker"
   ent2: type=password (we're setting the password), "multi word password"

In this step we check to see if the token has a '-' attached, if so then 
we're negating instead of allowing

> Does anyone have any suggestions for how we might clean up 
> the syntax a bit?  Or is this about the best we can do given 
> the overall flexibility desired?
> 
I find the current syntax very clear and easy to use from the user 
perspective. The problem is not the syntax but how to deal with it 
programatically

> Just for background:  I think we need to be able specify
> authorization based on (1) knowledge of a password, (2) authenticated
> identity (userid), and/or (3) membership in a group.  It would also be
> nice to have a way to revoke access based on userid or group
> membership (e.g., "everyone in this group except XYZ").
> 
> Thanks in advance for any suggestions,
> 
> Pm
> 

Américo Albuquerque