Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Message-ID: <1792210213.1127789088920.JavaMail.jira@ajax.apache.org>
Date: Tue, 27 Sep 2005 04:44:48 +0200 (CEST)
From: "Norbert Reilly (JIRA)" <directory-dev@incubator.apache.org>
To: dev@directory.apache.org
Subject: [jira] Commented: (DIREVE-253) escaping problem with custom partition
 search results
In-Reply-To: <1988969031.1126852015259.JavaMail.jira@ajax.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/DIREVE-253?page=comments#action_12330536 ] 

Norbert Reilly commented on DIREVE-253:
---------------------------------------

I tried Softerra's LDAP Browser 2.6 and it didn't have a problem either.

based on the following input (which I wasn't aware of):

" Marc Boorshtein  <mboorshtein@gmail.com> to Apache, me 
  More options   Sep 23 (4 days ago) 

JNDI will return an LDAP URL as the name of an entry if it falls outside of the the search base (ie if a referral to another server was followed that uses a different namespace)."

I have talked to the author of JXplorer and determined that I will provide him a patch to deal with the problem on the client side.

Three points of confusion remain:
    1. How/where the LDAP URLs come in to play: I presume the Sun JNDI library somehow determines that a SearchResults object from one namespace is being passed back through a different LDAP connection and decides that LDAP URLs must be used.
   2. How a proxy partition can convince the offending party not to convert the names of NameClassPairs returned to LDAP URLs, because the results look fine when the proxy partition sees them and even when they leave ApacheDS but seem to be adjusted by the JNDI layer on the client.
   3. Even when LDAP URLs come in to play, it seems strange that they are presented URL-encoded in the client. Is it really a requirement on JNDI clients that they need to scan search results and possibly perform URL-decoding?


> 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 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