[dev] Auth drivers and configurable capabilities, ldap groups hierarchy

[Jan Schneider]

Zitat von Ben Klang <ben at alkaloid.net>:

> On May 29, 2009, at 8:15 AM, Jan Schneider wrote:
>
>> Zitat von Lukas Macura <macura at opf.slu.cz>:
>>
>>> Next, we need to solve problems with LDAPg groups. In latest version,
>>> there is bug (or feature? ) ;) that we can see groups only from one
>>> context. Not from subcontexts. Problem is in Group/ldap.php where ldap
>>> drivers expects hierarchi al group tree but "forget" that to see parent
>>> groups, we need to interpret ous as groups. I found, that it probably
>>> worked some time ago, but was rollbacked at
>>> http://cvs.horde.org/co.php/framework/Group/Group/ldap.php?r=1.28
>>> Am I right?
>>>
>>> I made small patch  for Group/ldap.php which enables to see all LDAP
>>> groups as flat groups without hierarchy when config option 'flat_ldap'
>>> is true. So now we can see all groups from entire LDAP tree and it is
>>> partialy solved. It is trivial patch, I can post it but I would want to
>>> discuss if it is right way to implement LDAP groups or if it will be
>>> hierarchical again.
>>
>> They should work hierarchically again IMO. Please test if this is a  
>> problem with the LDAP groups driver, or with the way we use the  
>> groups API. As Ben mentioned in that commit message, using colons  
>> as group separators (like the datatree driver) doesn't make any  
>> sense for other drivers. LDAP has it's own way of creating  
>> hierarchies, the group driver should use that, and anything inside  
>> Horde should solely use the group API to display and manage group  
>> hierarchies.
>>
> LDAP Groups do not work hierarchically today.  The problem isn't in  
> the LDAP Groups driver, at least not directly, but rather in the UI.  
>  Because of the Datatree heritage, the UI assumes that groups in a  
> hierarchy are delimited by colons, and this is assumed as well by  
> the Group API.  This was the reason for the patch that I originally  
> wrote and was reverted above (r=1.28).  I can see two possible  
> solutions to the problem:
>
> 1) Allow colons to be the group hierarchy delimiter throughout  
> Horde.  This has the advantage of minimizing changes to the Horde  
> codebase, but the disadvantage of breaking any group names that  
> contain a colon.

I guess that would be the only solution then, if we want to fix it in Horde 3.

> 2) Find a new way to represent hierarchical groups within the Horde  
> UI.  This may require breaking BC by changing the way we pass in  
> hierarchical group information to the Group API as the old Datatree  
> driver expects hierarchical groups to be passed in as  
> colon-delimited string.

This might be suitable for Horde 4, colons could be valid characters  
in group ids in certain backends.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.horde.org/archives/dev/attachments/20090529/393b36dc/attachment.bin>