[pmwiki-users] "Official" release of UserAuth2 recipe

[ThomasP]

On Thu, May 17, 2007 23:21, The Editor wrote:
> On 5/17/07, Jason Frisvold <xenophage0 at gmail.com> wrote:
>> On 5/17/07, The Editor <editor at fast.st> wrote:
>> > I'd find it helpful to know what advantages UserAuth2 offers over
>> > AuthUser. It would seem finding a way to add those in to AuthUser
>> > would be a preferable path. At least it's what I've tried to do with
>> > the MemberMgmt recipe and ZAP's authentication scheme--which tries to
>> > tie into and expands AuthUser's capabilities.  But then again, if
>> > there are various UserAuth2 features not possible in AuthUser, that's
>> > a different story.
>>
...
>
> Of course, I'm still very interested in UserAuth2, so I'm still
> looking forward to a summary of what it can to that AuthUser can't.
>

Hi Dan,

UserAuth2 has not necessarily more _functionality_ than
AuthUser (apart from the ones I will explain below). The
point is rather that it provides a different way
in which a certain desired permission setup is expressed.
When I came to PmWiki, I had the impression that I wanted
this permission setup to be organized in a different way
than is done with AuthUser, and I had found in (then)
UserAuth the recipe that most closely matched this style.
(By now I would be less sensitive with this, but that's
another story.)

Let's have a look at how things are done in UserAuth2:

For every user (and, later, group) exists a permission record
that specifies what the user is entitled to. We might have
for Alice:

rd_Home.*,
ed_Project1.*,
up_SomeGroup.SomeSpecialPage

(for read, edit and upload actions) and so on. Negations of
permissions are possible as expected, for example

rd_Site.*,
-rd_Site.NotifyList

(This is interpreted in a "last applicable wins" semantic.)

In the permission record also the group membership is specified,
using for example

@editors,
@sitesettingsreaders

(When the user logs in she will implicitly belong to the desired
group, since on a permission query the permission record will be
scanned and a group membership be discovered (and interpreted
accordingly = the permission record of that group is "included").)

The functionality "To specify a password group that allows access
to anyone who is authenticated" (PmWiki.AuthUser) is achieved in
UserAuth2 having a designated LoggedInUsers group, in whose
permission record you specify all the things user should be able to
do that are logged in.

What is currently missing versus AuthUser is definitely support
for alternative password sources, which I would add as soon as the
need arises.





So what is new? Two things that could be difficult to add are

1. Wildcards for specifying page names in permission entries:

As seen above, you can use

rd_Home.*

to make every page in the Home group readable. What is also possible
though is

ed_*.*-Discussion

which makes every page whose page part ends on "-Discussion" editable.
(If one puts this in the GuestUsers account, then everyone can edit
discussion pages right from the start.)

A related thing, though probably not so difficult to address by
some lines of PHP, is

ed_Profiles.{$AuthId}

(put in LoggedInUsers group). This is a generic entry that opens
each user's profile page for her own editing.

2. Delegation mechanism

One really new thing in UserAuth2, whose usability in practice is still
to be confirmed, is the possibility to delegate admin tasks to users.
I have fancied during the course of the programming with this idea and
in the end could not resist to implement it.

The idea is to allow users to create other users (children), which then
have maximally the rights of their parent. (This works recursively of
course.) This would allow to distribute the responsibilities for the
content of some wiki in a decentralized manner over the users (say for
example of some big organization), and could work in connection with
the wildcards scheme for example by having a structured group part at
each wiki page, reflecting the division in the organization:

For example the admin grants to

DepartmentLeader1 =>
xx_D1?.*

DepartmentLeader2 =>
xx_D2?.*

and the department leaders grant respectively to their employees

Employee11 =>
xx_D11.*

Employee12 =>
xx_D12.*

and

Employee21 =>
xx_D21.*

Employee12 =>
xx_D22.*

Obviously this is all fancy stuff, that not necessarily needs to be
done with this module, but simpler versions of this might find
applications.





Other things that could be easier to address in AuthUser are:

3. IP address based silent permission granting:

Whenever a client connects one can grant rights just based on the
pattern of his ip address. For this just a group has to be created
which has the name as the pattern that should match, e.g.

192.168.

which would match all addresses "192.168.*.*". Like with a usual group
pages that should be allowed access to are specified in the permission
record of this "ip range" group.





In the end the aim for this module was also to provide a simple and
easy to start with tool for newcomers, which also can be used without
knowing all the possibilities that might be designed into it. (That's
at least how I'm using it at the moment.)

I have also once thought about introducing a more elaborate profile
support, but seeing MemberMgmt I'm glad not to have pushed this forward
as this covers already quite sufficiently what I might ever like to have.

Thomas

============

Concerning

>
> ZAP is built right onto AuthUser, so you can assign a member to a
> group (or allow them to pick their own groups) then when they login
> (they must use ZAP's login form) settings like @ChessClub for a read
> or edit passwd (on page attributes) goes immediately into effect.
> Standard PmWiki from that point on.
>

If that is sensible should we coordinate that it is usable also with
UserAuth2? How are the group management functions realized? Are you
writing directly into Site.AuthUser?