Re: [rfc] permissions managment

I had a look at using Auth a long while ago, and ended up not using it - primarily because it did too much already... From my look at Auth it should only do: -- check authentication = $auth->getAuth() -- get a User id = $auth->getUserID(); -- get a User Object = $auth->getUser(); What I would say is unneccessay : HTML login pages: = why assume authentication is always going to be web based - this is part of the applications responsibility.. Sessions := 50/50 if it should be generalized - I use a session ->object var mapper.. - not that fussed if it stays similar to current Auth, how ever would really prefer the use of PEAR::getStaticProperty('Auth','store'); rather than Globals.. list/add/remove Users: = this is really part of the User management responsibity.. (and can be very applications specific).. The model I use for all this: generally any check to see if somebody is logged in: $auth->getAuth(); if I need a finer granined authentication $user = $auth->getUser(); if( !$user->isMember('view naked girls group')) {

        return "No peeking";

} All of the 'Permissions/Group' management is outside the Auth responsibility. - The question really goes what would be a standard interface for the 'person' object. DB_DataObject Provides a good basis for me, however, As long as a 'User' interface could be standardized - you could easily implement wrappers to almost any user database/storage scheme. I do wonder if Auth_Lite, would be a viable package - basically a stripped down Auth (without the HTML stuff.) Auth_Lite Interface:: getAuth(), getID(), getUsername(), getUser() Auth_User Driver

       DB
       DataObject
       File
       Phorum
       Phplib
       my_special_app...

Interface:: getMembershipArray(), isMember(), generatePassword(), setPassword(), checkPassword()

           setMembershipArray($groups_array),
Standard Public Vars:: $id,  $username, $password??  (all other stuff is optional???)
Things that may be difficult to standardize.. (they are part of DataObjects) Interface::   delete(), insert(), update()

(Optional) Auth_Group Driver

       File
       myflatlist
       DB
       DataObject
       ...

Interface:: getMembersArray(), setMembersArray($people_array) Standard Public Vars:: $id, $name Auth_Membership // or Auth_Permissions Driver

       DB
       DataObject
       File    Interface:: staticIsMember($personid|$personname,$groupid|$groupname)

in this manner, it would be possible to support anything from simple on/off permissions fixed group type permissions complex group/member/user table permissions tree based group/member/user permissions.. Obviously I've taken alot of the interfaces from an existing working system. But basically once you understand any permission design, it could be easily mapped into these interfaces.. The updating/deleting etc. of users is a little outside the scope of this as It would be impossible to produce an interface that would cope with the 'nuances' of all the systems out there..... - eg. a bulletin board has the column 'nick' in the person table: does that mean a list of people in an brokage need to have 'nick's the authentication / user stuff should really just be a wrapper for other applications User management systems.... -- In the stuff I do, the person/user data table, grows and shrinks depending on what the project requires, generally the only implication of this is modifying the template, doing the ALTER TABLE..., and running the DB_DataObject generator.. Anyway - more fuel to the fire.. regards alan