[ http://issues.apache.org/jira/brows...233026
1 ]

Alex Karasulu commented on DIREVE-253:
--------------------------------------

This is really odd because ldapsearch (openLDAP command line tool) returns t
he correct result:

=================================
mac:~/Projects/apache/directory/apacheds/trunk akarasulu$ ldapsearch -h loca
lhost -p 20391 -s one -b 'dc=dummy' -x -w secret -D 'uid=admin,ou=system'
# extended LDIF
#
# LDAPv3
# base <dc=dummy> with scope one
# filter: (objectclass=*)
# requesting: ALL
#

# test space
dn: cn=test space

# search result
search: 2
result: 0 Success
matchedDN: dc=dummy

# numResponses: 2
# numEntries: 1
 ========================================
=====

JXPlorer on the otherhand does not.  It handles the DN replacing the space w
ith a  '%20'.  Just in case I went through all the code to see the encoding 
of the result was done properly.  It all looked just right.  I don't know wh
at could be making JXPlorer
treat this differently.  Just in case I will try another GUI based browser.



> 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
>  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 replac
ed with "%20" so that JXplorer is unable to explore them. The temporary solution I h
ave
in place is to wrap the original search results returned by the remote server using the foll
owing class:
> ============================
>     /**
>      *   ApacheDS seems to have a bug where SearchResult s with relative D
Ns
>      * 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.dere
fAliases");
>         final int           scope = searchControls.getSearchScope();
>         String              attrIds[] = searchControls.getReturningAtt
ributes();
>         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 (not
e 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
 he
nce 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/secur...nistrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

[ Post a follow-up to this message ]