directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Betts <ch...@pegacat.com>
Subject Re: [jira] Commented: (DIRSERVER-374) escaping problem with custom partition search results
Date Wed, 01 Mar 2006 12:42:33 GMT
Hi Norbert,

     if you can explain what the problem is in small words, we'd love  
to accept a bug fix :-).  Is this a referrals problem?  Referrals  
suck in JNDI...

     - Chris Betts (JXplorer project)

On 22/02/2006, at 9:26 AM, Norbert Reilly (JIRA) wrote:

>     [ http://issues.apache.org/jira/browse/DIRSERVER-374? 
> page=comments#action_12367270 ]
>
> Norbert Reilly commented on DIRSERVER-374:
> ------------------------------------------
>
> I think it is fair to say that this problem should no longer be  
> viewed as an ADS bug.
>
> I'm leaning to the opinion that it is either a problem in Sun's  
> client JNDI library (for not unencoding the name part of the URL in  
> this case) or in JXplorer proper. I have a patch to JXplorer which  
> I need to chase up and submit to that project (at least I know how  
> to fix the problem there).
>
>> 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
>


Mime
View raw message