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 <[email protected]>
To: Emmanuel Lécharny <[email protected]>
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!
Steve
------------------------------------------------------------------------
*From:* Emmanuel Lécharny <[email protected]>
*Sent:* Monday, May 4, 2020 12:08 PM
*To:* [email protected] <[email protected]>
*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 <[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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
