On 04/05/2020 17:18, Shawn McKinney wrote:
On May 4, 2020, at 10:05 AM, Moyer, Steven William <[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
