RE: permUser information

>  
> No, since you cannot authenticate against one container and pull data
> from another one. In that case we would expect you to store that
> information inside the LDAP container.

But what if I authenticate using POP3? If a user supplied credentials and
successfully logs on to a certain domain, I can't store information like a
handle, first or lastname on the POP server. 

Our biggest client has an Oracle server witch contains the authentication
information. They wanted one login but did not allow us to search the
tables. Instead we made an Auth container to see if a user could connect
successfully to Oracle with the supplied credentials. On success a user was
authenticated as a valid user to our application. If so, you would have a
authenticated user, an unique 'auth_user_id' + 'auth_container_name' but no
custom fields.

It's just that I love the idea of liveuser that a user can login on many
different ways but always have the same permissions and its strange that
user information isn't handled the same way. 

So if I authenticate using 4 different containers e.g. NTLM, LDAP,
Custom-Oracle and DB I would have to administer all 4 containers to greet
the user with "Hello Julien Hofstede your last visit was on 30 may 2005.".
And in case of NTLM and the custom Oracle container it even wouldn't be
possible to show the name because I can't 'edit' these containers. 

> 
> But what if someone wants to store the last login time on a per auth
> container basis? 

It would provide valuable information I do agree, but again, what if the
container is not writable which is the case with many of the PEAR::Auth
containers (POP3, LDAP, IMAP, Vpopmail, RADIUS, SAMBA password files, SOAP,
Oracle)? This problem can be solved to store this information in the
perm_users table. Take this example:

liveuser_users
+ auth_user_id
+ handle
+ passwd

liveuser_perm_users
+ perm_user_id  
+ auth_user_id  
+ perm_type
+ auth_container_name
+ lastLogin  
+ owner_user_id  
+ owner_group_id
+ isActive

liveuser_perm_userinfo
+ perm_user_id  
+ firstname
+ lastname
+ email
+ isActive
+ [add custom fields here]

You could control usage (isActive) of a container and store last login time
for each container, even if the container isn't writable by nature! And you
would have one place to get your user information regardless what container
is used. I know this idea does not comply with the fact that authentication
is required and permissions are optional. Or one should say that that
authentication is required and permissions and user information are
optional.
 
> It is currently possible to extend the perm_users table with any field
> (aside from is_active and last_login fields) and I can see us adding
> fetching of all of these fields into a property into the permission
> containers. Open a feature request so we can ponder this some more.
> 
Hmmz I think I lost you there... I do not see any use of this but I think I
just don't exactly understand what you mean...

Regards,

Julien Hofstede