change in python-ldap method?

[Joe Little]

Thoughts at the very end..

On 2/25/02 3:29 PM, "Michael Ströder" <michael at stroeder.com> wrote:

> Joe Little wrote:
>> 
>> When it
>> explodes the DN out of my entry, its string result is:
>> 
>> "(cn=whois\+\+)"
>> [..]
>> However, even before I explode it, I already see the DN is stored in my res
>> as whois\+\+.
> 
> This is perfectly right. See RFC2253, section 2.4. After reading BNF in
> section 3. you might be convinced that you're best bet is to handle DNs
> as opaque. "+" is used to form multi-valued RDNs.
> 
>> Searching on this DN results in an ldap.FILTER_ERROR: {'desc':
>> 'Bad search filter', 'info': ''}
> 
> Special chars in search filters are a different thing, see RFC2254.
> 
>> whois++ has been in /etc/services for quite some time.
> 
> I remember that there was a discussion about this very topic on one of
> the OpenLDAP lists.
> 
>> So one of two things
>> has happened:
>> 
>> 1) python-ldap has changed behavior in some way (whether first pull of data
>> or search filter usage)
>> 
>> 2) MigrationTools (used to load up NIS type data to LDAP) from padl.com,
>> which fixed certain things associated with + and other symbols, can load
>> data correctly into LDAP with Perl ala PerLDAP and PythonLDAP doesn't
>> support the same.
> 
> 3) The LDAP libs/server requires proper escaping/handling DNs which
> translates to "+" need to be escaped nowadays. The application using
> python-ldap has to be fixed.
> 

What I find odd about this is that the data retrieved using one call to
Python-LDAP cannot be in turn used again to write back. You have to take the
results and always un-escape any characters before calling LDAP methods
again on data? It seems somehow very wrong that one can't use the DN that
LDAP returns with a result to refer to the same entry again. Wouldn't you
agree?


> Ciao, Michael.
> 
> 
>