[ http://issues.apache.org/jira/browse/DIRSERVER-374?page=comments#action_12369132 ]
Norbert Reilly commented on DIRSERVER-374: ------------------------------------------ Came across this listing http://mail-archives.apache.org/mod_mbox/directory-commits/200602.mbox/[EMAIL PROTECTED] (included in case link goes away) which explains how the problem occurs as a result of com.sun.jndi.ldap.LdapSearchEnumeration's behaviour: =============================Dear Wiki user, You have subscribed to a wiki page or wiki category on "Directory Wiki" for change notification. The following page has been changed by MarcDexet: http://wiki.apache.org/directory/LdapSearch New page: Describe LdapSearch here. Stuff about LpadSearch and SearchResult == Some little things you could use == === DN from my search are looking like URL with true escape code inside === Oh my god I get search result with ugly ldap url "ldap://127.0.0.1:389/"; in front of. Is it a bug ? No, it's normal and written in RFC 2251. An LDAP URL is returned for an alias that falls outside of the search base. You haven't aliasing in your context ? Maybe you use the Sun Ldap factory ? Let's see what happens: The URL format is set as name to the SearchResult if this one is NOT relative. cf. http://java.sun.com/products/jndi/tutorial/ldap/referral/follow.html And how could JNDI guess SearchResult is unrelative ? If you take a look [http://www.jsourcery.com/output/sun/j2se/j2sdk/1.4.2_04/com/sun/jndi/ldap/LdapSearchEnumeration.source.html to sun LdapSearchEnumeration source] who creates SearchResult, relativity is set to false if the DN doesn't contain the search base DN. So assume you get such a search {{{ ldapUrl=ldap://dir.acme.com baseDn ="dc=acme,dc=com" filter="(&(sn=foo)(employeetype=dreamer))"; attrs =[]; }}} If a LdapName is {{{ cn=John FOO,ou=dreams }}} it's deducted as unrelative and you will get {{{ dn=ldap://dir.acme.com/cn=John FOO,ou=dreams }}} But if LdapName is {{{ cn=John FOO,ou=dreams,dc=acme,dc=com }}} is deducted as relative and you will get {{{ dn=cn=John FOO,ou=dreams }}} Don't forget LdapName checking is what happen ''inside'' LdapSearchEnumeration, not what you could see at result enumeration. ============================= > escaping problem with custom partition search results > ----------------------------------------------------- > > Key: DIRSERVER-374 > URL: http://issues.apache.org/jira/browse/DIRSERVER-374 > Project: Directory ApacheDS > Type: Bug > Components: core > Environment: winxp,jdk 1.4.2 > Reporter: Norbert Reilly > Assignee: Alex Karasulu > Attachments: DummyProxyPartition.java, apacheds-dummy-partition.xml > > I have observed a strange problem in implementing a custom partition that > proxies to another remote LDAP server: the results of search() operations > have blanks replaced with "%20" so that JXplorer is unable to explore them. > The temporary solution I have in place is to wrap the original search results > returned by the remote server using the following class: > ============================ > /** > * ApacheDS seems to have a bug where SearchResult s with relative DNs > * have URL encoding applied twice, so blanks come out as %20. > */ > public static final class AvoidEscapingNamingEnumeration > implements NamingEnumeration > { > private final String baseDN; > private final NamingEnumeration ne; > public AvoidEscapingNamingEnumeration(final String baseDN, > final NamingEnumeration ne) > { > this.baseDN = baseDN; > this.ne = ne; > } > public void close() throws NamingException > { > ne.close(); > } > public boolean hasMore() throws NamingException > { > return ne.hasMore(); > } > public Object next() throws NamingException > { > final SearchResult sr = (SearchResult)ne.next(); > final String fullDN; > final SearchResult sr2; > final String name = sr.getName(); > if (!sr.isRelative() || (name == null) || "".equals(name)) > return sr; > fullDN = name + "," + baseDN; > sr.setName(fullDN); > sr.setRelative(false); > return sr; > } > public boolean hasMoreElements() > { > try > { > return hasMore(); > } > catch (NamingException e) > { > log.error(this.getClass().getName() > + ": error in hasMoreElements", e); > return false; > } > } > public Object nextElement() > { > try > { > return next(); > } > catch (NamingException e) > { > log.error(this.getClass().getName() > + ": error in nextElement", e); > return null; > } > } > } > ========================== > where the search method itself looks like this: > ========================== > public NamingEnumeration search(Name base, final Map env, > final ExprNode filter, final SearchControls searchControls) > throws NamingException > { > final String deref = > (String)env.get("java.naming.ldap.derefAliases"); > final int scope = searchControls.getSearchScope(); > String attrIds[] = > searchControls.getReturningAttributes(); > final String newFilter; > final StringBuffer sb; > final String baseDn; > final String[] attrNames; > final String last; > if (attrIds == null) > attrIds = BLANK_ATTRS; > sb = new StringBuffer(); > filter.printToBuffer(sb); > newFilter = sb.toString(); > baseDn = base.toString(); > last = base.get(0); > if (! "dc=etadb".equals(last)) > { > // don't want to change name seen by outside world > base = (Name)base.clone(); > base.add("dc=etadb"); > } > attrNames = normaliseAttrNames(attrIds); > final SearchControls sc = new SearchControls(); > sc.setSearchScope(scope); > sc.setReturningAttributes(attrNames); > sc.setDerefLinkFlag(Boolean.valueOf(deref).booleanValue()); > final NamingEnumeration ne = _ctx.search(base, newFilter, sc); > return new AvoidEscapingNamingEnumeration(baseDn, ne); > } > ========================== > so it seems whatever is doing the escaping leaves results with full DNs alone > (note that just setting sr.setRelative(false) has no effect by itself). I'm > not familiar enough with the DS architecture yet to work out where the > escaping is occurring and hence come up with a better fix. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
