python-ldap-dev

problem with the case of attributes' names

[Jerome A. <al...@li...>]

Hello,

I encounter some problems with IBM Directory Server and python-ldap

The same app which works just fine with OpenLDAP breaks with IDS
because, it seems, of a problem with the case of attributes' names.

For example, IDS will return things like "objectclass" while
OpenLDAP will return "objectClass", and this seems to cause some
problems when retrieving and/or modifying attributes

Could this be a bug in IDS ?

Is there some rule on how to correctly handle this ?

Should apps expect attributes names in any case or not ?

Shouldn't ldap.modlist handle this automatically (not sure if it
does or not) when updating existing attributes ?

Does python-ldap do something special about name's case or not ?

Thanks in advance for any information on this subject.

Jerome Alet

Re: problem with the case of attributes' names

[<mi...@st...>]

Jerome Alet wrote:
> 
> The same app which works just fine with OpenLDAP breaks with IDS
> because, it seems, of a problem with the case of attributes' names.
> 
> For example, IDS will return things like "objectclass" while
> OpenLDAP will return "objectClass", and this seems to cause some
> problems when retrieving and/or modifying attributes

Your application has to deal with it
(and with more weird alias issues).

> Could this be a bug in IDS ?

No, it isn't.

> Should apps expect attributes names in any case or not ?

Attribute type descriptions should be handled case-insensitive.

> Shouldn't ldap.modlist handle this automatically (not sure if it
> does or not) when updating existing attributes ?

It can handle this automagically if you use ldap.cidict for the entry
dictionaries passed to ldap.modlist.modifyModlist().

> Does python-ldap do something special about name's case or not ?

python-ldap mainly provides ldap.cidict which a dictionary class with
case-insensitive strings as keys.

Another more sophisticated solution is undocumented class
ldap.schema.models.Entry. But have to implement full schema support for
making real use of it.

Ciao, Michael.

Re: problem with the case of attributes' names

[Jerome A. <al...@li...>]

Hi,

On Thu, Mar 31, 2005 at 03:33:26PM +0200, Michael Ströder wrote:
> 
> Your application has to deal with it
> (and with more weird alias issues).
> ... 
> > Shouldn't ldap.modlist handle this automatically (not sure if it
> > does or not) when updating existing attributes ?
> 
> It can handle this automagically if you use ldap.cidict for the entry
> dictionaries passed to ldap.modlist.modifyModlist().

Am I right in thinking that each time I use search_s() I should
transform the result this way so that the app doesn't care :

--- CUT ---    
result = server.search_s(base, scope, fiterexp, attributes)
if result :
    result = [ (dn, ldap.cidict.cidict(attrs)) for (dn, attrs) in result ]
--- CUT ---    
        
> > Does python-ldap do something special about name's case or not ?
> 
> python-ldap mainly provides ldap.cidict which a dictionary class with
> case-insensitive strings as keys.

OK, so if I always transform the search results with the above code,
and if I directly use these transformed results when calling 
modifyModlist() for both old and new entries, all should be fine ?

Do I understand correctly ?

If yes, then this is just great news :-)

(sorry, no more access to an ldap server for today, I can't test this
until tomorrow)

thanks all for your help

Jerome Alet

Re: problem with the case of attributes' names

[<mi...@st...>]

Jerome Alet wrote:
> 
> On Thu, Mar 31, 2005 at 03:33:26PM +0200, Michael Ströder wrote:
> 
> Am I right in thinking that each time I use search_s() I should
> transform the result this way so that the app doesn't care :
> 
> --- CUT ---    
> result = server.search_s(base, scope, fiterexp, attributes)
> if result :
>     result = [ (dn, ldap.cidict.cidict(attrs)) for (dn, attrs) in result ]
> --- CUT ---    

This may solve it. But note that there are also some alias problems. One
example from recent OpenLDAP schema:

( 2.5.4.9 NAME ( 'street' 'streetAddress' ) DESC ... )

> OK, so if I always transform the search results with the above code,
> and if I directly use these transformed results when calling 
> modifyModlist() for both old and new entries, all should be fine ?

In theory everything should be fine regarding case of attribute type
names. But please test yourself!

Ciao, Michael.