Re: [rfc] permissions managment

> 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(); I don't even agree with the last and i doubt about the second. Getting a user object from which tou get the id should be part of a user class. The aim of a User class would not be to provide a definite scheme but a container-like approach so that people may write their own stuff. > 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"; > } Mmm, i see how you like to name your groups ;)) > 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. Indeed. > 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() Honestly i don't the the Auth_* hierachie is a good idea. Wouldn't User_* (User_Auth, User_Perm, etc) make more sense ? just my .2Euros. > 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.. I ought to give a look at DB_DataObject. Regards, Arnaud. > Anyway - more fuel to the fire.. > > regards > alan