[pmwiki-users] MemberMgmt with UserAuth2 (was: JITS: AuthUser necessary ?)

ThomasP pmwikidev at sigproc.de
Sun May 20 09:53:43 CDT 2007


On Sun, May 20, 2007 15:41, The Editor wrote:
> Actually no, MemberMgmt authenticates against passwords stored in
> Profiles pages (either encrypted or encoded) and then uses authuser's
> AuthUserId( ) function to set the authid variable. Then it extracts
> any user group memberships from Memberships pages and sets those using
> authuser's SessionAuth( ).

(#) (see below)

>
> So MemberMgmt really is it's own authentication system--that rests on
> AuthUser to handle things like permissions and stuff after ZAP log's
> them in. If I can make this work with UserAuth, I'd be more than happy
> to. Just let me know what you have in mind.
>

The thing is that UserAuth2 (like UserAuth) works completely independent
of any AuthUser related functions (*) -- thus SessionAuth() and the
functions that depend on its actions will not being called as soon as
UserAuth2 is activated. Therefore any group membership registrations by
MemberMgmt will not be noticed in this case.

I suggest I simply introduce the array

$UA2UserMemberInGroup

in UserAuth2 which can be populated by MemberMgmt. This array will get
interpreted _additionally_ to UA2-internal membership information as
specified there by the user. If

$UA2UserMemberInGroup['myUser']['myGroup']

evaluates to true, well, then the permissions of that group (as given in
UA2) count towards the privileges of that user.

Would that be enough? (Are there ever needs of resetting the array etc.?
Should there be such an array dedicated only to MemberMgmt (MM)?)


Thomas

> Cheers,
> Dan
>
> PS.  I didn't reply to your long post describing the features of
> UserAuth(2) but I wanted to say I was very impressed. I did not really
> understand what it did before, and I definitely appreciate it's
> philosophy. FWIW, ZAP has been steaily moving that direction in terms
> of how it manages it's security, and I think even Pm will start moving
> that direction from hints of how he will set up the commenting system
> target controls. I personally have found centralizing control to a few
> pages, rather than spreading it out across the wiki is much easier.
>

I have pondered a lot about how to express and store a given permission
setup and have to admit that I finally discovered that a page-oriented way
of storing might at least have an advantage on speed, at least when not
many diversified users are involved. The current AuthUser scheme is also
very fast to handle, e.g. adhoc protecting pages. On the other hand, the
user-oriented approaches play out their quality when it comes to bigger
entities (where things are structured more along responsibilities), and
when user related data has to be saved anyway (settings, profiles).

> Coincidentally, the new wiki engine I'm working on will work VERY much
> like UserAuth in terms of security, user & group mgmt, permissions,
> etc. Very enlightening to read your post. Thanks for the good work you
> are doing with UserAuth!
>
>
> Cheers,
> Dan
>

-----
(*) At least at the moment; I'd like to drive this back where it is
possible, since it would ensure better (automatic) compatibility. But it
is not easy.

(#) To make sure: This probably also means that the page authorization
information is coming from Site.AuthUser?






More information about the pmwiki-users mailing list