directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: LDAP API question
Date Mon, 04 May 2020 16:08:06 GMT

On 04/05/2020 17:18, Shawn McKinney wrote:
>> On May 4, 2020, at 10:05 AM, Moyer, Steven William <smoyer@psu.edu> wrote:
>>
>> '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)
convertToLdif(Attribute, int)
convertToLdif(Attributes)
convertToLdif(Attributes, Dn)
convertToLdif(Attributes, Dn, int)
convertToLdif(Attributes, int)
convertToLdif(Entry)
convertToLdif(Entry, boolean)
convertToLdif(Entry, int)
convertToLdif(LdifEntry)
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: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org


Mime
View raw message