Re: Some docs help

On Sep 12, 2005, at 4:02 AM, Lukas Kahwe Smith wrote:

>>> like i said .. you would have to have multiple entries. in which   
>>> case you would have to remove the primary key .. and you venture   
>>> into untested territory.
>>>
>>>
>> Then why not put the auth_container_name on liveuser_users, and   
>> everything would work fine? Put another way: the current scheme  
>> seems  wrong. The auth_container is surely a property of the  
>> authorization,  not of the user.
>>
>>
>
> because that would be useless.
>
> 1) it would require modification in the auth source which we have  
> ruled out (remember people could be using an LDAP database as their  
> authentication source..)
>

Then I don't understand the purpose of this field. I had thought it  
was an identifier for the foreign source -- an identifier for 'LDAP  
server', another for 'Windows login', and so on. Or it is an  
identifier for the container that provides a bridge to that foreign  
source, effectively the same thing.


> 2) if i have the perm_user_id i would still not be able to match  
> this with an auth user unless the perm_user_id is stored in the  
> auth container database which is clumsy and also violates the  
> principles of liveuser (see 1) again)
>

Again, I'm clearly failing to understand something fundamental here.  
I'd thought your auth user was just a foreign key reference from  
perm, and then in auth, you'd have whatever information the  
"container" needed to represent the user to the foreign authorization  
system. I don't see why you'd need to store anything in the foreign  
system; you store whatever you need to identify against what is  
already in the foreign system in the auth table.

Clearly, I'm missing something important here. Let me give a for  
instance, about how I imagine this system is designed, or ought to  
be, or something:

Let's say the foreign auth system is the local bash shell. In our  
auth table, we would store the user's login name, and some kind of  
reference to a suitable PHP "container". This container would, when  
asked to authorize the user, somehow fire up a bash shell, asking the  
user to log in, and detecting when that had happened. So the auth  
table needs something that says it uses the bash container (so,  
according to my question above, I'm imagining the auth_container_name  
is something that amounts to "BASH bridge"). Then this auth record  
has a FK reference to some suitable perm record that represents this  
same user.

Now, I want to give the user the option to authenticate against a  
windows login, if they're on a windows machine. This would all be the  
same as above, only the auth_container_name amounts to "Windows  
login", and the userid is probably different.

This is what I imagined was meant by separating the canonical  
representation of the user, from the authentication information. And  
it is to identify what authentication system should be used, that I  
thought auth_container_name was for. But that doesn't make sense in  
this scheme, because such an identifier clearly belongs with the auth  
table: one auth_container_name for the bash login, a different one  
for the windows login. If there is only one, on the perm table, what,  
in my example, would it be, and what would it represent?