[dev] Identity drivers

[Richard Wallace]

Jan Schneider wrote:
> Zitat von Richard Wallace <rwallace at thewallacepack.net>:
> 
>> I'm working on creating a custom Identity driver for our system.  We
>> could use the $type parameter to Identity::singleton() to have it create
>> an application specific instance of the identity, but the identity
>> itself is going to be used across multiple applications and they
>> shouldn't need to know about the application itself.  It also seems like
>> it would be awkward to have them lookup in the configuration what type
>> of Identity object they should be using.
>>
>> So, I'd like to modify the way the singleton() method works to find the
>> Identity object in the configuration.  This isn't a problem.  What is
>> (or could be) a problem is that there is one Identity object per user.
>> At first glance this makes sense, but when you start thinking about
>> having a LDAP or SQL backend Identity (and a composite cause we'll
>> actually be using both as sources), you're talking about having one
>> connection to the backend per user you want to lookup.  Sure, you could
>> try and do a persistent connection for SQL, but I don't think that
>> really addresses the issue.
> 
> 
> What is so bad about this? We do this all the time with a lot of data we 
> use
> in Horde. If you want to optimize it, you can store the Identity 
> instance in
> the session or in a cache and let singleton() look in the session data
> before it creates a new Identity object.
> 

I shudder anytime I think of putting something that represents a 
connection to a database or other data source in the session.  Just 
because it's there doesn't mean it's valid.  I was thinking of doing 
identities similar to how the groups are done.  You get a reference to 
an Identity object that is really just a factory for getting instances 
of the {Driver}_Identity object for specific users.

>> So, I'm trying to figure out the best way to go about this.  Right now
>> I'm leaning towards the way the Auth class gets its configuration data.
>>   The dev calls Identity::singleton($conf['identity']['driver']) and
>> possibly the $params.  If the $params are not passed then they are
>> looked up with Horde::getDriverConfig().
> 
> 
> Not sure what this has to do with the SQL/LDAP connections, and what I read
> from your first paragraph you want to avoid changing all singleton() calls.
> 

This has everything to do with the SQL/LDAP connections because the 
driver parameters have to be gotten from someplace, right?


I'm trying to figure out, if we were to change the Identity interface to 
make it multi-driver friendly, what the best way to do this would be. 
Yes, the above would require changing all the singleton() calls and I'm 
not against that.  The alternative is to have the Identity class lookup 
the driver it should use and the parameters for that driver.

>> Is this the best way to do this and would you guys be interested in me
>> committing these changes to Horde?
> 
> 
> I don't see us having more than the default identity driver anytime 
> soon, so
> I'm not sure if it's worth the effort. OTOH, we are prepared for new 
> drivers
> without breaking BC if we include the driver name in the singleton() calls.
> I guess I would accept a clean patch.

I'll just implement an application specific driver and customize our 
Identity class to lookup for the type of driver to use in the 
configuration information.  I'll still need to modify the interface to 
Identity so that the default is not 'none' and is null, indicating that 
the thing should try and look in configuration before defaulting to the 
prefs based Identity.

Rich