[dev] Identity drivers

[Jan Schneider]

Zitat von Richard Wallace <rwallace at thewallacepack.net>:

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

I didn't mean to stick the resource in the session, that doesn't work
anyway. I talked about the Identity *data*.

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

Then your first paragraph was a bit misleading.

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

Both is possible, passing the driver to the singleton method is the cleaner
solution, but if I was to implement a local driver, I'd probably stick with
the solution that requires the fewest changes.

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

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/