Re: [naming] permissions managment

Am Wed, 14 Aug 2002 12:25:54 +0200 schrieb Sandro Zic <Sandro.Zic@oc4ware.org>: > > > What the class can do is: > > > - User management (add/edit/delete users) > > > - Authorization (user login management) > > > - Permission/ACL management > > > > > > So the possibilities I see are: > > > - User_LiveUser > > > - Auth_LiveUser > > > - Perm_LiveUser > > Auth_LiveUser -1 > > I don't see the point why there should be one more package for user > authentication. The current Auth package does all the necessary stuff. There > are some good ideas in Markus' LoginManager class which I would like to see > in the current Auth package - but there's no need to start a new one. I did not intend to make a separate auth package out of the functionality created in LiveUser - I see LiveUser as one integrated package until someone (like Lukas, who´d like to see everything as a single package if I´m not mistaken) convinces me otherwise - but he would need very solid arguments for that. > User_LiveUser -1 > > Furthermore, I have my doubts if it makes sense to have any kind of User_* > package in PEAR if it deals with adding, editing, deleting user data like > firstname, lastname, email, affiliation, etc. This will become a hassle to > find a general purpose solution as such data can vary a lot accross > applications. We would enter a standardisation process looking for the common > denominator of vocabulary to describe user data - and we would have to offer > a mapping mechanism for existing solutions. As far as a new permission > package is concerned, it is sufficient to relate the ID of a user from the > permission schema to a self-made user data schema. > Maybe I understood something wrong here? As stated earlier, the user table is not fixed. There are a few fields that are needed in any case (like unique user ID, handle, password...) but aside from that, you can always write a simple backend class that does all the data retrieval logic and that can of course also add new properties to the user object, so you are totally free about where to store your data, and how. > Perm_LiveUser +1 > > I am very much in favour of adding those parts of Markus' LoginUser class > which deal with permission issues to PEAR - and I would certainly like to > contribute to that. Markus' classes are an excellent starting point! > I'd propose the following approach towards a new permission package: > > Perm/ > > Some abstract permission classes which handle the basic permission methods and > provide containters to access different data sources (e.g. flat files, XML, > RDBMS, SOAP, LDAP, ...) as well as the relevant default schemas (e.g. XML > schema, RDBMS table definition, ...). > > Perm_LiveUser/ > > Extending the Perm/ abstract classes, providing a special purpose API. > > Perm_*/ > > any other permission package, e.g. the 'simple' permission classes. I am okay with putting the whole package unter a Perm/ category. But I´d envision the structure more like this: Perm/ - LiveUser.php (The LoginManager class) - LiveUser/ - examples/ - user_backends/ - backend_mysql.php - backend_db.php - backend_ldap.php - backend_passport.php - backend_phpBB.php ... - acl_backends/ - acl_mysql.php - acl_db.php - acl_soap.php ... - backend_common.php - acl_common.php Regards, Markus -- *21st Media* | Consulting, Konzeption, Produktion für die Bereiche: Markus Wolff | Internet, Intranet, eCommerce, Content Management, Hamburg,Germany | Softwareentwicklung, 3D-Animation, Videostreaming http://21st.de | Tel. [+49](0)40/6887949-0, Fax: [+49](0)40/6887949-1