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

[The Editor]

On 5/20/07, ThomasP <pmwikidev at sigproc.de> wrote:

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

Yes that would be easy enough to do, but better for me, would be
simply to have UserAuth2 read the session variable member mgmt sets
directly and use it. That would not require any changes in ZAP,
eliminates storing the group memberships data redundantly, and has the
advantage that UserAuth2 could then work with any authentication
method in AuthUser, and perhaps go a big step toward making the two
work more harmoniously.

I mean suppose someone want to use AuthUserDB (database) or DFaure's
fine Htpasswd recipe for managing stuff. If UserAuth2 just read
PmWiki's authlist, it could work it seems with all of these.

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

For my purposes (zapwiki), where I have at least a dozen site actions
and potentially dozens more--all constructed dynamically within the
wiki--having a centralized control center makes much more sense.
Otherwise any kind of group attributes page is going to get very
unwieldy. But ZAP is definitely more CMS in its approach than wiki so
perhaps that's why it's more in harmony with UserAuth than AuthUser in
philosophy. And why PmWiki is setup like it is.

Cheers,
Dan