Re: [rfc] permissions managment

Markus Wolff wrote:

Am Wed, 14 Aug 2002 10:55:43 +0800 schrieb Alan Knowles <alan@akbkhome.com>:

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

+1

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

I don´t quite understand what you mean here... can you describe in more detail what your session->object var mapper does? Its a pretty simple little routine,

http://docs.akbkhome.com/akpear/HTML_FlexyFramework_Session.html ** load should really be staticLoad, and called without a variable, as $this would carry forward on a static method call.. basically loads session data into the current object and creates session items if the variable name is var $s_user; etc. It makes documenting what is 'sessionized' nice and easy..

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.

LiveUser allows you to write your own backend classes that can retrieve user data from any kind of data source you want. The LoginManager class that you use in applications doesn´t need to know how the data is actually stored. can you post the link again - I coulnt find it on this thread... :)

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

In the past, I´ve always had a generalized users table which contained data on all users who were allowed to login in any form. This table always contains only the data necessary for the login process itself (well, and there are of course the permission tables that are referencing the user table). All profile data, such as ie. adress, gender, credit card numbers and the like is stored in one or more separate tables that may change from application to application. If a person that has a profile also has an online account, its ID in the user table is just referenced in the profile table. I really don´t see the need to change the user table for each application - it should be used to store always the same kind of data. i do it mainly for speed. - saves an extra sql call to another table.. - the idea that you can allow a flexible user table means that you could then apply the infratructure to existing systems - bbforum, midgard .. or whatever..... or even ldap...

Regards, Markus