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? _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
