Creation of entry with special (and escaped) character in RDN leads to wrong attribute value

• Key: DIRSERVER-631
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Emmanuel Lecharny
• Reporter: Stefan Zoerner
• Affects Version/s: 1.0-RC3

Environment

ApacheDS 1.0 RC 3
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Microsoft Windows XP version 5.1 Service Pack 1

Description

If one creates an entry with a special character in its RDN value (e.g. #, <, ...) which is escaped in the (R)DN, the resulting entries has the escape char (\) in its attribute value as well. Example:

Creating this entry:

dn: cn=Bush\, Kate,dc=example,dc=com
objectclass: person
objectclass: top
sn: Bush
cn: Bush, Kate

like this

$ ldapmodify -h localhost -p 10389 -D "uid=admin,ou=system" -w ****** -a -f KateBush.ldif
adding new entry cn=Bush\, Kate,dc=example,dc=com

leads to an entry like that

$ ldapsearch -h localhost -p 10389 -b "dc=example,dc=com" -s sub "(sn=Bush)"
version: 1
dn: cn=Bush\, Kate,dc=example,dc=com
objectclass: person
objectclass: top
sn: Bush
cn: Bush\, Kate

The expected for cn is "Bush, Kate", as provided by the LDIF above. The same error occurs with several characters (other than comma). I'll attach a JNDI JUnit test which demonstrates the issue with test methods using different characters (and the test passes on other directory servers).

Note: This problem may be related to DIRSERVER-628.

Comments

[Stefan Zoerner]

This is the JUnit test using JNDI ops to create entries with special characters in their RDNs.

[Emmanuel Lecharny]

This is a really bad problem we have ...

Some explainations on how DN should be treated can be found here : http://docs.safehaus.org/display/APACHEDS/DN+normalization+and+parsing

This is supposed to be done this way, but it's not. The normalizationService does not transform the DN accordingly to the AttributeType.

Changing that will cost time, and tests.

Unless I'm totally wrong, of course :)

[Emmanuel Lecharny]

The code has been modified to handle the vast majority of the cases. However, I still have an issue remaining : escaped hexPairs.

For instance, the DN :
cn=L\C3\E9charny

should have this internal value :
cn=Lécharny

no?

But in this case, what about :
cn=L\C3charny

It should generate an exception, because \C3 is not a valid UTF-8 multi-byte char, no?

wdyt ?

PS: the code has not been committed

[Alex Karasulu]

Yes if it is not a UTF-8 multibyte char then it is invalid. I would through an exception on this one. If the attribute is binary does not matter.

[Emmanuel Lecharny]

Ok, I think it has been solved, but it needs a full load of unit tests...

[Stefan Zoerner]

This has been fixed by Emmanuel and Alex more than a month ago.