You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Norbert Reilly (JIRA)" <di...@incubator.apache.org> on 2005/09/16 08:37:55 UTC
[jira] Commented: (DIREVE-253) escaping problem with custom partition search results
[ http://issues.apache.org/jira/browse/DIREVE-253?page=comments#action_12329515 ]
Norbert Reilly commented on DIREVE-253:
---------------------------------------
I have reduced the problem down to an extremely simple dummy custom partition and I'm attaching this partition class and associated XML config file to activate it.
You then need to connect to Apache DS using JXplorer and the following parameters:
host: localhost
port: 20391
ldap version: 3
base dn: dc=dummy
login dn: uid=admin,ou=system
password: <DS admin password>
Initially you will see an entry under dc=dummy with the correct name "test space". After two refreshes (not sure why two rather then one) you will instead see "test%20space" (as the dummy partition toggles its behaviour between interfering with search results so they work (broken=false) and leaving them alone so that the escaped name appears in JXplorer.
Further debugging (inside JXplorer) has shown that in the broken case the NameClassPair returned in the results has name="ldap://localhost:20391/cn=test%20space" and isRelative=false, where as in the working case it has name "cn=test space" and isRelative=true.
If I understood the MINA stack better I might be able to contribute more then just this test case, but despite attempting to debug with a number of different approaches I'm afraid I only got this far.
> escaping problem with custom partition search results
> -----------------------------------------------------
>
> Key: DIREVE-253
> URL: http://issues.apache.org/jira/browse/DIREVE-253
> Project: Directory Server
> Type: Bug
> Versions: 0.9.3
> Environment: winxp,jdk 1.4.2
> Reporter: Norbert Reilly
> Assignee: Alex Karasulu
>
> 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