Re: Problem with NON-ASCII chars in DNs when using OpenLDAP 2.1.x libs (ITS#1923)

[Kurt@OpenLDAP.org]

At 12:25 AM 2002-07-10, michael@stroeder.com wrote:
>Kurt D. Zeilenga wrote:
>> Thanks for the detailed information.  This the same issue
>> reported in ITS#1890.
>> 
>> The ldap_explode_dn() returns string representations of RDNs which
>> conform to the syntax detailed in RFC 2253.  Both 2.0 and 2.1 version
>> can and will produce strings which included escaped values.  In a
>> number of cases, escaping is required by the technical specification.
>> 2.1, however, will actively escape values and/or escape values
>> differently than presented in its input.  While this is a change
>> in behavior from 2.0, it is not expected to cause problems with
>> any application which is designed to properly handle the RDN escaping
>> (which 2.0 produces in certain cases).  That is, any application which
>> has a problem with the change likely has bugs in its design.  This
>> change will aggravate those bugs.
>
>My misleading error report was due to ldap_search() returning 
>LDAP_NO_SUCH_OBJECT when passing a DN as search root based on the 
>output of ldap_explode_dn(). See this python-ldap trace log 
>(Python script attached):
>
>*** _ldap.<built-in function is_ldap_url> 
>(('ldap://localhost:1389',),{})
>=> result: 1
>*** ldap.ldapobject.SimpleLDAPObject.initialize 
>(('ldap://localhost:1389',),{})
>=> result: <LDAP>
>*** _ldap.<built-in function explode_dn> (('cn=Michael 
>Str\xc3\xb6der+mail=michael@stroeder.com,ou=Testing,dc=stroeder,dc=com', 
>0),{})
>=> result: ['cn=Michael Str\\C3\\B6der+mail=michael@stroeder.com', 
>'ou=Testing', 'dc=stroeder', 'dc=com']
>*** ldap.ldapobject.SimpleLDAPObject.search (('cn=Michael 
>Str\\C3\\B6der+mail=michael@stroeder.com,ou=Testing,dc=stroeder,dc=com', 
>0, '(objectclass=*)', ['cn'], 0),{})
>=> result: 1
>*** ldap.ldapobject.SimpleLDAPObject.result ((1, 1, -1),{})
>=> LDAPError: {'info': '', 'matched': 
>'ou=Testing,dc=stroeder,dc=com', 'desc': 'No such object'}
>
>> We, however,
>> don't believe the change impacts any properly designed application.
>> That is, properly designed applications should expect that RDN
>> strings may contain escaped values.
>
>And how should the application handle them?

Well, in general, as opaque values.

>I mostly treat DNs to be opaque.

mostly opaque != opaque

>But I'm eliminating spaces from DNs because it caused 
>problems with some LDAP servers.

It likely would be much easier to walk through string
and trim the extraneous spaces.  This can be in place.
Just watch out for escaping which might appear in the
string.

>E.g. web2ldap transforms
>uid=michael, dc=stroeder, dc=com
>to
>uid=michael,dc=stroeder,dc=com
>before passing it back into python-ldap which directly wraps 
>ldap_search() and ldap_result() etc.

The problem above is that server fails to recognize
all the possible string representations of the DN.
That is, that server doesn't recognize that both strings
represent the same DN.

>> I note that any application which wants to get at the value portion
>> of the AVAs within the RDNs of a DN, should consider using
>> ldap_str2dn(3) and, conversely, ldap_dn2str(3) which provides
>> significant control over generation of DN (and RDN and AVA) string
>> representations.
>
>I will dig into that.

Likely overkill for what you are doing...