Re: [Phplib-users] phplib app integration

[giancarlo p. <gia...@na...>]

Stephen Woodbridge wrote:
...
> 
> An application is accessible by an authorized user.
> An application provides access based on the authorization level of the
> user.
> Different application need to have different authorization levels for
> its users.
> A single user might have different authorization levels depending on the
> application.
> The information to define a user is different for different apps.

I am supposing that we are having user/groups/perms, as in a new design
see:
http://www.geocrawler.com/archives/3/195/2001/7/150/6234214/

With such, you could set a new group, 'bugtraq users', with permissions
'users' (or add the user to a group 'users' with permissions
'bugtraq_users', or both) 
That design doesn't actually allows to add groups to groups, but maybe
is better. Too much confusion then.

A single user can belong to more than a group and more than one
permission can be assigned to each individual users or to groups.


> 
>     I think this much is correct, did I miss anything?
> 
> This seems to imply that phplib needs a generic Auth module that is
> application and user independent - its job would be to asertain if a
> user is how they say they are via their password, then return there
> unique user id.
> 

It is already so.

> Applications need to register themselves at installation with the Auth
> module and define there authorization levels.

I'd say that the admin should add the groups and perms the installation
needs.

> 
> There needs to be a generic User module the defines and or updates a
> user and assigns him a unique id. If the user already has an identity,
> then he can login and only update those fields that are required for the
> new application.

This part is missing. How to automate the differences in what is
required by different apps is hard. If the sites only requires name and
email, and appA requires address, an user that is already registered
should complete his  registration info to use appA. That is add the
address which is missing..

> 
> There needs to be a way for an application create a new user or extend
> an existing user to be authorized at some level for that application.
> 

For an application, I wouldn't pretend phplib to be able to do this. I
see difficult here anyway. This has to be done. Some major stuff should
go in the auth_user table (or related, because someoe keeps the
auth_user table at minimum, and join it to other user_related tables, eg
user_anagraphic, user_history, etc.) Minor stuff could have a place in
the $user->$BigBagName[app] array as user persistent stuff. Stuff that
wouldn be too much needed for stats.

> Applications need to register user specific data they might want to
> store for a user with the user module if there is a common one used by
> all apps.

As I said, here is only a questio of using the same class name and top
data contaner name. Avoid the intialization of user stored objects by
extended methods of th user class. Use application methods. In practice
use only the name and root container structure of the user class. Write
the methods that treat this data in the application, not as new methods
of the user class.

> 
> Then you have a common user login that will allow him/her to move
> between authorized applications.
> 

Hopefully

> This also seems to imply that the application does not nessisarily own
> the User of the Auth tables and they might not been in the same database
> as the application tables, especially if there are multiple databases.

Recomandable. I like this. It can use an Auth class whose name is a
defined constant, not even knows the name of the Auth class (and the
User and session class BTW...) 
Dreams?

- Gian

> 
> This is grain for the mill, feel free to grind it up :)
> 
> -Steve