JDK-4307193 : JNDI/LDAP does not handle slashes in DN.
  • Type: Bug
  • Component: core-libs
  • Sub-Component: javax.naming
  • Affected Version: unknown
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2000-01-26
  • Updated: 2000-02-10
  • Resolved: 2000-02-10

Name: krT82822			Date: 01/25/2000

(see also 4238917, 4083434)

java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-O)
Java(TM) HotSpot Client VM (build 1.3beta-O, mixed mode)

This bug is related to JNDI & LDAP. (Directory used is Nestcape Directory 4)

When creating an entry in a directory whose directory has a slash,
(With another tool than JNDI since you can't create an entry with slashes)
The directory handle the case with double quotes, the dn looks like:


When performing a search or a list that have this kind of DN as a result,
JNDI returns names as expected (with quotes and slashes).

At this point, all is OK. But when trying to access an entry with this kind of
DN, or perform a search on it, JNDI throws a javax.naming.InvalidNameException:

javax.naming.InvalidNameException: "cn=group/test",ou=foo,o=somecompany.com: close
quote appears before end of component can't perform list()

What's strange is that dn with quotes and slashes is legal for LDAP name parser,
this example works well:

        DirContext ctx=getDirContext("ldap://rantanplan/o=somecompany.com","","");
	NameParser parser=ctx.getNameParser("");
	Name name=parser.parse("\"cn=group/test\",ou=groups,o=somecompany.com");

	Enumeration e=name.getAll();
	while(e.hasMoreElements()) {

It gives the following result:



1/24/2000 eval1127@eng -- additional comments from user, in reply to our asking whether "/" is really valid in the middle of  a DN:

 it is difficult to know if / is a valid character or not but it seems to be, here is the DN grammar from 
RFC 1779 (http://rfc.fh-koeln.de/rfc/html/rfc1779.html).
<name> ::= <name-component> ( <spaced-separator> )
          | <name-component> <spaced-separator> <name>
   <spaced-separator> ::= <optional-space>
   <separator> ::=  "," | ";"
   <optional-space> ::= ( <CR> ) *( " " )
   <name-component> ::= <attribute>
           | <attribute> <optional-space> "+"
             <optional-space> <name-component>
   <attribute> ::= <string>
           | <key> <optional-space> "=" <optional-space> <string>
   <key> ::= 1*( <keychar> ) | "OID." <oid> | "oid." <oid>
   <keychar> ::= letters, numbers, and space
   <oid> ::= <digitstring> | <digitstring> "." <oid>
   <digitstring> ::= 1*<digit>
   <digit> ::= digits 0-9
   <string> ::= *( <stringchar> | <pair> )
            | '"' *( <stringchar> | <special> | <pair> ) '"'
            | "#" <hex>

   <special> ::= "," | "=" | <CR> | "+" | "<" |  ">"
            | "#" | ";"
   <pair> ::= "\" ( <special> | "\" | '"')
   <stringchar> ::= any character except <special> or "\" or '"'

   <hex> ::= 2*<hexchar>
   <hexchar> ::= 0-9, a-f, A-F
So Is "/" part of "any character except <special> or "\" or ' " '   " ?  ;)
All this problems because one of our customer have a directory with slashes everywhere....
Netscape Directory returns DN like   "cn=group/test",ou=.......
But I think it should be cn="group/test",ou=.......
But this is a case that doesn't work too.
(Review ID: 100229) 

EVALUATION scott.seligman@Eng 2000-02-09 First a few quick comments: - The relevent LDAP RFC is 2253. - Slash ('/') is not a special character in LDAP, so an LDAP DN containing a slash does not -- according to RFC 2253 -- need to contain quotes. - Quotes may optionally be added, although this is deprecated. The format is cn="foo" rather than "cn=foo". The real issue here is that slash ('/'), while not being special to LDAP, is a special character to JNDI. The JNDI rules for escaping special characters in names are documented in the javadoc for the CompositeName class. This can be confusing at times since there are potentially three levels of escaping to consider: at the JNDI level, at the LDAP level, and at the Java language level (for string literals). If the DN is cn=group/test,ou=foo,o=somecompany.com, then a correct JNDI lookup might look like this: ctx.lookup("cn=group\\/test,ou=foo,o=somecompany.com"); The backslash character escapes the slash so that JNDI does not treat it specially, and instead passes it unmodified to the LDAP layer. More generally, suppose you have a string dn containing an arbitrary LDAP DN: String dn = getSomeValidLdapDn(); If you cannot be sure that dn does not contain any JNDI meta-characters, it is not safe to do this: ans = ctx.lookup(dn); Instead, you could do something like this: Name n = new CompositeName().add(dn); ans = ctx.lookup(n); The variable n contains a JNDI composite name whose first and only component is the LDAP DN. There is no need to do any escaping.