directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Norbert Reilly (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DIRSERVER-374) escaping problem with custom partition search results
Date Tue, 07 Mar 2006 02:47:30 GMT
    [ 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/%3C20060211150823.1566.99558@ajax.apache.org%3E
(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


Mime
View raw message