python-ldap-dev

Re: Escaping of binary characters

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

Mark Hammond wrote:
> 
> I don't actually have neat sample code - I'm observing this inside Zope.

Is this a publicly available Zope component like LDAPUserFolder?

> However, what happens is:
> 
> * We query for the attribute 'objectGUID'.  We get back a 16 byte string - a
> raw binary representation of the 128-bit GUID.  This part works fine - we
> get the binary value from LDAP correctly.

Just curious because I'm always interested to learn anything people are
doing via LDAP:

Do you store the objectGUID to reference the single entry later?

Does this reference has to survive renaming of the entry?
If no, why don't you use the DN of the entry for a base level search later?

> * Later, we call search_s with a filter string '(objectGUID={string})',
> after calling escape_filter_chars with the exact value as previously
> fetched.  The filter fails, but succeeds with my implementation of
> escape_filter_chars.

Is this code specific for Active Directory (seems so to me)? Or does
your code has to work with any LDAP server with a configurable unique
and DN-independent attribute similar to objectGUID (e.g. entryUUID comes
to mind for OpenLDAP 2.2+)?

IMHO searching with the exact objectGUID returns exactly one entry
anyway. Therefore you could also use the entry's DN and retrieve the
entry with a base level search.

Well, I still didn't get the point of why you need a octet string
objectGUID in a search filter.

> it should read:
> 
> if c < ' ' or c > '~' or c in "\\*()":
> 
> which includes some extra punctuation. As far as I can tell, that
> will leave all 'printable' characters alone and should leave things
> as readable (even if slightly different than) the current
> implementation

Hmm, if I got you right this still escapes NON-ASCII chars which
otherwise could be displayed as UTF-8 encoded Unicode chars.

I'm also afraid this significantly slows down this function which is
probably not a big deal in most applications.

Ciao, Michael.

Re: Escaping of binary characters

[Jens V. <je...@da...>]

On May 11, 2005, at 18:52, Michael Str=F6der wrote:

> Mark Hammond wrote:
>
>> I don't actually have neat sample code - I'm observing this inside =20=

>> Zope.
>>
>
> Is this a publicly available Zope component like LDAPUserFolder?

Yes, Mark uses that truly brilliant piece of software ;)



> Do you store the objectGUID to reference the single entry later?
>
> Does this reference has to survive renaming of the entry?
> If no, why don't you use the DN of the entry for a base level =20
> search later?

That's an excellent question. Mark, is that what you are trying to =20
do, identify one specific entry by using the objectGUID?

But then again, even if he could use the DN, I suppose the real =20
problem is that you cannot "round trip" the value. You can't just =20
grab it from a search result and use it to formulate another query, =20
even if you send it through ldap.escape_filter_chars, if I understand =20=

the problem correctly.

jens

Re: Escaping of binary characters

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

Jens Vagelpohl wrote:
> 
> But then again, even if he could use the DN, I suppose the real  problem
> is that you cannot "round trip" the value. You can't just  grab it from
> a search result and use it to formulate another query,  even if you send
> it through ldap.escape_filter_chars, if I understand  the problem
> correctly.

After all it seems to me the idea of "the right" implementation of
ldap.escape_filter_chars() is broken. Basically one has to escape the
assertion value based on subschema knowledge (the LDAPSyntax here).

Note: I'm rather scared of escaping all chars by default since it could
also break interoperability with some badly implemented LDAP servers.

My suggestion for a workaround is to add both implementations and let
the application developer decide which to use. We could make the
differences clear in the __doc__ string.

This could be achieved by a flag passed as arg to ldap.escape_filter_chars()

def escape_filter_chars(assertion_value,escape_all_chars=0):

A schema-aware application could simply set this flag if it determines
that the assertion attribute has a syntax which is not human-readable.

Ciao, Michael.