directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Fwd: Re: LDAP API question
Date Mon, 04 May 2020 20:51:15 GMT

Forwarded to the mailing list...

-------- Forwarded Message --------
Subject: 	Re: LDAP API question
Date: 	Mon, 4 May 2020 16:37:15 +0000
From: 	Moyer, Steven William <>
To: 	Emmanuel Lécharny <>

Thanks for the quick responses gents!

I'll create a ticket in Jira for further discussion by the team.  I do 
like the idea of attribute creation/addition being validated based on 
the syntax that the schema defines for the attribute ... including the 
escape of restricted classes.  I don't know the internals of the library 
well enough to say how that should be done in a generic fashion but 
would be happy to help.

In the short term, I'll put rudimentary postalAddress escaping in place 
to address the failures we've been seeing.

Thanks again!

*From:* Emmanuel Lécharny <>
*Sent:* Monday, May 4, 2020 12:08 PM
*To:* <>
*Subject:* Re: LDAP API question

On 04/05/2020 17:18, Shawn McKinney wrote:
 >> On May 4, 2020, at 10:05 AM, Moyer, Steven William <> 
 >> 've got a question about the intended behavior of the LDAP API with 
respect to LDAP syntax that require escaping (or encoding?).  We've had 
multiple occurrences of users creating their entries with back-slashes 
in the postalAddress attribute (This seems to be common in some 
countries/regions).  Should we expect the LDAP API to encode these 
dstring values for us or should we perform that transformation before 
setting the attribute's value? Note that there's no complaint when an 
illegal attribute value is added to an entry.
 > Hey Steve,
 > I could see how an encoding feature would be useful in the API.  I’ll 
let the others chime in if it’s available (in the api), my assumption, not.

So it all depends on the context. There are many places where such an
escaping should kick in.

First, PostalAddress - and I'm just focusing on this attribute type as
an example, but it's valid for all the other attribute types - has a
syntax defined in RFC 4517 :

        PostalAddress = line *( DOLLAR line )
        line          = 1*line-char
        line-char     = %x00-23
                        / (%x5C "24")  ; escaped "$"
                        / %x25-5B
                        / (%x5C "5C")  ; escaped "\"
                        / %x5D-7F
                        / UTFMB

So bottom line, we accept any UTF-8 char, but the '$' and '\' chars 
which get escaped.

Now, let's devise the cases where we need more escaping :
- filters
- DN

LDIF are not included in those use cases, because there is no reason to 
escape anything that
is not ASCII, or that collide with LDIF specificities (like '\n', ':', 
'>'...) because in this case, the value is Base 64 encoded.

The API already deal with that when you call one of the LdifUtils methods :
convertToLdif(Attribute, int)
convertToLdif(Attributes, Dn)
convertToLdif(Attributes, Dn, int)
convertToLdif(Attributes, int)
convertToLdif(Entry, boolean)
convertToLdif(Entry, int)
convertToLdif(LdifEntry, int)

In the eventually where the postalAddress is used in a DN (a bit of an 
insane decision, but remind that it applies to *any* other attribute type),
then you have to depend on the Dn methods to deal with escaping.
If it's used in the filter, same story.

Now, we don't have any implemented solution to deal with auto-escaping - 
accordingly to the RFC of course - of a value that is provided. Again,
for PostalAddress, where '$' and '\' must be escaped, those chars *have* 
to have been escaped before hand. We *could* so this escaping within the
API though: everytime you create an Attribute, the value is controlled 
against the associated SyntaxChecker - which in the postalAddress case is
clearly lacking, as we don't check if the '$' and '\' chars escaping is 
not checked).

I think that could be a good addition to the API, and we could do that 
in each AttributeType SyntaxChecker. That would not be complex not costly
to add, except that we have many SyntaxChecker classes (76) although not 
all of them require auto-escaping.

I would suggest you create a JIRTA for that task.

Thanks !

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message