[jira] Commented: (DIRSERVER-169) Incorrect SearchResult name and "compare" failure using CoreContextFactory

["Emmanuel Lecharny (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DIRSERVER-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471158 ] 

Emmanuel Lecharny commented on DIRSERVER-169:
---------------------------------------------

>From JNDI tutorial :

"LDAP names as they are used in the protocol are always fully qualified names that identify entries that start from the root of the LDAP namespace (as defined by the server). Following are some examples of fully qualified LDAP names.

    cn=John Smith, ou=Marketing, o=Some Corporation, c=gb
    cn=Ted Geisel, ou=People, o=JNDITutorial

In the JNDI, however, names are always relative; that is, you always name an object relative to a context. For example, you can name the entry "cn=Ted Geisel" relative to the context named "ou=People, o=JNDITutorial". Or you can name the entry "cn=Ted Geisel, ou=People" relative to the context named "o=JNDITutorial". Or, you can create an initial context that points at the root of the LDAP server's namespace and name the entry "cn=Ted Geisel, ou=People, o=JNDITutorial". "

I guess that if someone is using JNDI to use a Ldap Server, then it's the responsibility of the JNDI layer to strip the absolute part before returning the response.

We have to check that our implementation of JNDI does respect this contract.

> Incorrect SearchResult name and "compare" failure using CoreContextFactory
> --------------------------------------------------------------------------
>
>                 Key: DIRSERVER-169
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-169
>             Project: Directory ApacheDS
>          Issue Type: Bug
>          Components: core
>         Environment: OS X,
> java version "1.5.0_05"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-83)
> Java HotSpot(TM) Client VM (build 1.5.0_05-48, mixed mode, sharing)
>            Reporter: Luke Taylor
>         Assigned To: Alex Karasulu
>             Fix For: 1.0.1, 1.5.0
>
>         Attachments: DIRSERVER169TestCase.java, LdapTestServer.java, TestCase.zip
>
>
> Attached is a test case following on from my post a while back to the mailing list, viz:
> My setup is like this:
> I have a simple DIT with a root "dc=acegisecurity,dc=org". This has two subcontexts "ou=people" and "ou=groups" for my users and roles respectively. When the test base class instantiated, I create a
> MutableStartupConfiguration and add a partition to it with the suffix "dc=acegisecurity,dc=org". I then create a context with this configuration as follows:
>     env.setProperty( Context.PROVIDER_URL, "dc=acegisecurity,dc=org" );
>     env.setProperty( Context.INITIAL_CONTEXT_FACTORY,
>              CoreContextFactory.class.getName());
>     env.putAll( cfg.toJndiEnvironment() );
>     serverContext = new InitialDirContext( env );
> When I need a context in my tests it is created the same way.
> Bind authentication works fine in both scenarios. I have problems with two things when trying to use CoreContextFactory :
> 1. The name returned by a search. When I do a search for a user in the directory, I get back the full DN rather than the name relative to the context I search in. So if I call
>    ctx.search("ou=people", "(uid={0})", new String[] {"bob"}, ctls);
> on a context obtained as above, I get back a SearchResult with name
> "uid=bob,ou=people,dc=acegisecurity,dc=org"
> whereas with the full server (or OpenLDAP) I get
> "uid=bob"
> as expected. This then unfortunately leads to an attempt to bind with an an unknown DN which causes the infinite recursion problem.
> 2. Performing "compare" operations. I had problems with this before, as reported in
> http://issues.apache.org/jira/browse/DIRLDAP-77
> but this now works with the full server, thanks to Emmanuel's speedy response. Running the same search code against a context obtained from CoreContextFactory fails however. A compare is never performed and the search returns an empty enumeration. Is there some way I can get my client code (as posted in JIRA):
>      SearchControls ctls = new SearchControls();
>      ctls.setReturningAttributes(new String[0]);
>      ctls.setSearchScope(SearchControls.OBJECT_SCOPE);
>      String filter = "(userPassword={0})";
>      NamingEnumeration results = ctx.search(dn, filter, new
>            Object[]{password.getBytes()}, ctls);
> to trigger a compare call on the context? The compare/search also fails for non-binary attributes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.