You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Luke Taylor (JIRA)" <di...@incubator.apache.org> on 2006/01/30 16:04:32 UTC
[jira] Created: (DIRLDAP-87) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Incorrect SearchResult name and "compare" failure using CoreContextFactory
--------------------------------------------------------------------------
Key: DIRLDAP-87
URL: http://issues.apache.org/jira/browse/DIRLDAP-87
Project: Directory LDAP
Type: Bug
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
Attachments: 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.
-
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
[jira] Commented: (DIRSERVER-169) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-169?page=comments#action_12372854 ]
Emmanuel Lecharny commented on DIRSERVER-169:
---------------------------------------------
No time frame available right now :(
We are busy on very time consuming tasks atm, and it's very difficult for us to find some spare time out of our spare time we spend on ADS:)
However, I think that as soon as we have a fix for the concurrence problem we have on ADS, we will be able to spend some more extra time on a few bugs in the bug list, like your one. Another possibility is that we just get fed of working hard on hard stuff, and try to clear our mind buffers by fixing your problem, just to feel that we are usefull :)
Don't be afraid to do some polling on us, that's just cool.
> Incorrect SearchResult name and "compare" failure using CoreContextFactory
> --------------------------------------------------------------------------
>
> Key: DIRSERVER-169
> URL: http://issues.apache.org/jira/browse/DIRSERVER-169
> Project: Directory ApacheDS
> 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
> Attachments: 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.
-
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
[jira] Updated: (DIRSERVER-169) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alex Karasulu updated DIRSERVER-169:
------------------------------------
Affects Version/s: 1.5.0
1.0.1
Fix Version/s: (was: 1.5.0)
(was: 1.0.1)
1.0.2
1.5.1
Pushing a fix for this to 1.0.2 and 1.5.1.
> 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
> Affects Versions: 1.0.1, 1.5.0
> 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.5.1, 1.0.2
>
> 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.
[jira] Commented: (DIRSERVER-169) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Luke Taylor (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-169?page=comments#action_12372861 ]
Luke Taylor commented on DIRSERVER-169:
---------------------------------------
Thanks for the update :). I'll try and have a browse through the latest source sometime and check the tests are still applicable.
> Incorrect SearchResult name and "compare" failure using CoreContextFactory
> --------------------------------------------------------------------------
>
> Key: DIRSERVER-169
> URL: http://issues.apache.org/jira/browse/DIRSERVER-169
> Project: Directory ApacheDS
> 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
> Attachments: 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.
-
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
[jira] Commented: (DIRSERVER-169) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Luke Taylor (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-169?page=comments#action_12429210 ]
Luke Taylor commented on DIRSERVER-169:
---------------------------------------
I don't think there are any Acegi specifics, apart from the DIT name. There's a JUnit class which contains two test methods, demonstrating each of the two issues, and a separate class which contains the embedded server. Did you have a problem running it? I haven't checked that it still compiles against the latest apache-ds code. The report was pre-1.0, but we're currently using 1.0-RC1 as a dependency and still have problems with that.
> Incorrect SearchResult name and "compare" failure using CoreContextFactory
> --------------------------------------------------------------------------
>
> Key: DIRSERVER-169
> URL: http://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
> Attachments: 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.
-
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
[jira] Reopened: (DIRSERVER-169) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-169?page=all ]
Emmanuel Lecharny reopened DIRSERVER-169:
-----------------------------------------
Reopened to be sure we have investigated all the consequences of the fix.
> Incorrect SearchResult name and "compare" failure using CoreContextFactory
> --------------------------------------------------------------------------
>
> Key: DIRSERVER-169
> URL: http://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.5.0, 1.0-RC4
>
> 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.
-
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
[jira] Assigned: (DIRSERVER-169) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-169?page=all ]
Alex Karasulu reassigned DIRSERVER-169:
---------------------------------------
Assignee: Alex Karasulu
> Incorrect SearchResult name and "compare" failure using CoreContextFactory
> --------------------------------------------------------------------------
>
> Key: DIRSERVER-169
> URL: http://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
> Attachments: 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.
-
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
[jira] Commented: (DIRSERVER-169) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-169?page=comments#action_12430804 ]
Alex Karasulu commented on DIRSERVER-169:
-----------------------------------------
On commit revision 437255 I made it so SearchResult.isRelative() returns the correct value. This will allow you to detect whether or not the search results returned are relative names or absolute names. The core JNDI provider will always return absolute names. Here's a link to svn for your convenience:
http://svn.apache.org/viewvc?view=rev&revision=437255
This fixes 1/2 of your issue. The second problem you're facing is the same as DIRSERVER-715. Basically binary attributes in search filters are causing big problems within ApacheDS. I'm going to try to fix this tomorrow night with Emmanuel. Thanks for the solid test case Luke we really appreciate it.
> Incorrect SearchResult name and "compare" failure using CoreContextFactory
> --------------------------------------------------------------------------
>
> Key: DIRSERVER-169
> URL: http://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
> 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.
-
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
[jira] Commented: (DIRSERVER-169) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Luke Taylor (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-169?page=comments#action_12431044 ]
Luke Taylor commented on DIRSERVER-169:
---------------------------------------
Great! Thanks for the fix(es). Look forward to the next release.
> Incorrect SearchResult name and "compare" failure using CoreContextFactory
> --------------------------------------------------------------------------
>
> Key: DIRSERVER-169
> URL: http://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.1.0, 1.0-RC4
>
> 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.
-
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
[jira] Commented: (DIRSERVER-169) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-169?page=comments#action_12429291 ]
Alex Karasulu commented on DIRSERVER-169:
-----------------------------------------
Luke if you could write a unit test case which starts ApacheDS and does some operations against it to exactly isolate your problem I can get you a fix quickly. Take a look at how to write a unit test case from here as an example:
Here's one that does not startup ApacheDS networking but uses the core JNDI provider directly:
http://svn.apache.org/viewvc/directory/branches/apacheds/1.0/core-unit/src/test/java/org/apache/directory/server/core/jndi/CreateContextITest.java?revision=428079&view=markup
Here's a test case that starts up networking so you can hit the embedded apacheds through SUN JNDI:
http://svn.apache.org/viewvc/directory/branches/apacheds/1.0/server-unit/src/test/java/org/apache/directory/server/ModifyRemoveTest.java?revision=430261&view=markup
If you could be so kind as to set up a test case in either of these areas depending on whether or not you use ApacheDS JNDI or SUN JNDI providers I can fix this issue of yours very quickly. Plus I can add the test case to our codebase if you attach it as a patch (JIRA attachment) using svn diff.
And yes if you worked against the current 1.0-RC4-SNAPSHOT'd branch that would be best for us. I want to make sure we're up to date and kill this bug of yours.
Thanks very much!
> Incorrect SearchResult name and "compare" failure using CoreContextFactory
> --------------------------------------------------------------------------
>
> Key: DIRSERVER-169
> URL: http://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
> Attachments: 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.
-
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
[jira] Commented: (DIRLDAP-87) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Emmanuel Lecharny (JIRA)" <di...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/DIRLDAP-87?page=comments#action_12364472 ]
Emmanuel Lecharny commented on DIRLDAP-87:
------------------------------------------
Hi Luke,
The first point seems to be just the normal behavior of the SearchResult.getName() method. You have a method isRelative() that should tell you if the getName() returns a name relative to the current context, or not.
This is a point that should be investigated a littlmle bit more.
I did not had time to dig yur second point.
> Incorrect SearchResult name and "compare" failure using CoreContextFactory
> --------------------------------------------------------------------------
>
> Key: DIRLDAP-87
> URL: http://issues.apache.org/jira/browse/DIRLDAP-87
> Project: Directory LDAP
> Type: Bug
> 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
> Attachments: 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.
-
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
[jira] Updated: (DIRSERVER-169) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Luke Taylor (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-169?page=all ]
Luke Taylor updated DIRSERVER-169:
----------------------------------
Attachment: LdapTestServer.java
I've attached the latest version of the LdapTestServer we are running against apache-ds-rc1, in case the API has changed.
I'll see if I can update our dependencies to the latest version and try runnng against that. Let me know if there's anything else I can do to help.
> Incorrect SearchResult name and "compare" failure using CoreContextFactory
> --------------------------------------------------------------------------
>
> Key: DIRSERVER-169
> URL: http://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
> Attachments: 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.
-
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
[jira] Commented: (DIRSERVER-169) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-169?page=comments#action_12428895 ]
Alex Karasulu commented on DIRSERVER-169:
-----------------------------------------
Is there any way I can get a test case that is a patch which isolates this problem without all the ACEGI specifics? Any status on this issue?
> Incorrect SearchResult name and "compare" failure using CoreContextFactory
> --------------------------------------------------------------------------
>
> Key: DIRSERVER-169
> URL: http://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
> Attachments: 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.
-
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
[jira] Commented: (DIRLDAP-87) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Luke Taylor (JIRA)" <di...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/DIRLDAP-87?page=comments#action_12364477 ]
Luke Taylor commented on DIRLDAP-87:
------------------------------------
Hi Emmanuel,
Thanks for the response. My understanding of isRelative() is that it should return true unless the name in the result is from a referral and is a full URL, otherwise it
should be relative to the "target context" (the context the search is performed in). There is some info on this in the Java tutorial:
http://java.sun.com/products/jndi/tutorial/ldap/search/result.html
Though that may not be correct :).
In any case, the behaviour doesn't appear to be consistent. If I modify the test to use
if(searchResult.isRelative()) {
if(searchBase.length() > 0) {
userDn.append(",");
userDn.append(searchBase);
}
userDn.append(",");
userDn.append(ctx.getNameInNamespace());
}
The isRelative() method returns "true". In this case the name should be relative to "ou=people,dc=acegisecurity,dc=org", since I'm passing "ou=people" to the search method. However the name of the search result is "uid=bob,ou=people,dc=acegisecurity,dc=org".
> Incorrect SearchResult name and "compare" failure using CoreContextFactory
> --------------------------------------------------------------------------
>
> Key: DIRLDAP-87
> URL: http://issues.apache.org/jira/browse/DIRLDAP-87
> Project: Directory LDAP
> Type: Bug
> 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
> Attachments: 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.
-
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
[jira] Commented: (DIRSERVER-169) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471272 ]
Emmanuel Lecharny commented on DIRSERVER-169:
---------------------------------------------
Ok, we need to take a decision about this issue.
First, the second part of the issue (binary value used as a filter) seems to be fixed. We have a unit test for it : http://svn.apache.org/viewvc/directory/branches/apacheds/1.0/core-unit/src/test/java/org/apache/directory/server/core/jndi/DIRSERVER169ITest.java?view=markup&pathrev=437314
On the other issue, I do think that JNDI approach might not fit our need. With Alex patch, we can just check if the returned entry name is absolute and relative, so I guess we are ok. In my mind, returning a relative name (which is, in fact, the DN) seems a nonsense : to get back the DN, you will have to concatenate the context path to the relative returned result. Why do a user should bother about it? Anyway, this is JNDI spec ...
In my mind, we should just let it be. Sorry or the spec breakage, but it's quite a reasonnable position regarding LDAP specs - we are not really writing a JNDI implementation, but a LDAP server.
wdyt ?
> 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.
[jira] Updated: (DIRSERVER-169) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alex Karasulu updated DIRSERVER-169:
------------------------------------
Affects Version/s: 1.0.2
1.0
1.0-RC4
1.0-RC3
1.0-RC2
1.0-RC1
pre-1.0
I don't think it's worth making this change for 1.0.x considering the possible destablization that may result. It's best that we fix this issue in the 1.5.x branch where we have the freedom to refactor for it.
> 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
> Affects Versions: 1.0.2, 1.0.1, 1.5.0, 1.0, 1.0-RC4, 1.0-RC3, 1.0-RC2, 1.0-RC1, pre-1.0
> 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.5.1, 1.0.2
>
> 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.
[jira] Closed: (DIRSERVER-169) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-169?page=all ]
Alex Karasulu closed DIRSERVER-169.
-----------------------------------
Fix Version/s: 1.1.0
1.0-RC4
Resolution: Fixed
For 1.0 branch:
http://svn.apache.org/viewvc?view=rev&revision=437312 for shared LDAP
http://svn.apache.org/viewvc?view=rev&revision=437314 for apacheds
For 1.1 branch:
http://svn.apache.org/viewvc?view=rev&revision=437313 for shared LDAP
http://svn.apache.org/viewvc?view=rev&revision=437315 for apacheds
> Incorrect SearchResult name and "compare" failure using CoreContextFactory
> --------------------------------------------------------------------------
>
> Key: DIRSERVER-169
> URL: http://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.1.0, 1.0-RC4
>
> 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.
-
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
[jira] Commented: (DIRSERVER-169) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Luke Taylor (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-169?page=comments#action_12445357 ]
Luke Taylor commented on DIRSERVER-169:
---------------------------------------
"On commit revision 437255 I made it so SearchResult.isRelative() returns the correct value. This will allow you to detect whether or not the search results returned are relative names or absolute names. The core JNDI provider will always return absolute names."
This still seems potentially inconsistent with the discussion above and the quotations from the Java tutorial - that the search result should be relative to the target context the search is performed in and isRelative() should return true unless the name is a URL.
> Incorrect SearchResult name and "compare" failure using CoreContextFactory
> --------------------------------------------------------------------------
>
> Key: DIRSERVER-169
> URL: http://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.1.0, 1.0-RC4
>
> 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.
-
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
[jira] Commented: (DIRSERVER-169) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522799 ]
Emmanuel Lecharny commented on DIRSERVER-169:
---------------------------------------------
Should we postpone again ?
> 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
> Affects Versions: 1.0.2, 1.0.1, 1.5.0, 1.0, 1.0-RC4, 1.0-RC3, 1.0-RC2, 1.0-RC1, pre-1.0
> 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
> Assignee: Alex Karasulu
> Fix For: 1.5.1
>
> 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.
[jira] Commented: (DIRLDAP-87) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Luke Taylor (JIRA)" <di...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/DIRLDAP-87?page=comments#action_12364489 ]
Luke Taylor commented on DIRLDAP-87:
------------------------------------
Thanks a lot Emmanuel. Let me know if I can do anything to help.
> Incorrect SearchResult name and "compare" failure using CoreContextFactory
> --------------------------------------------------------------------------
>
> Key: DIRLDAP-87
> URL: http://issues.apache.org/jira/browse/DIRLDAP-87
> Project: Directory LDAP
> Type: Bug
> 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
> Attachments: 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.
-
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
[jira] Updated: (DIRSERVER-169) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-169?page=all ]
Alex Karasulu updated DIRSERVER-169:
------------------------------------
Component: core
> Incorrect SearchResult name and "compare" failure using CoreContextFactory
> --------------------------------------------------------------------------
>
> Key: DIRSERVER-169
> URL: http://issues.apache.org/jira/browse/DIRSERVER-169
> Project: Directory ApacheDS
> 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
> Attachments: 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.
-
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
[jira] Updated: (DIRSERVER-169) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alex Karasulu updated DIRSERVER-169:
------------------------------------
Fix Version/s: (was: 1.0.2)
> 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
> Affects Versions: 1.0.2, 1.0.1, 1.5.0, 1.0, 1.0-RC4, 1.0-RC3, 1.0-RC2, 1.0-RC1, pre-1.0
> 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.5.1
>
> 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.
[jira] Commented: (DIRSERVER-169) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "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.
[jira] Updated: (DIRLDAP-87) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Luke Taylor (JIRA)" <di...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/DIRLDAP-87?page=all ]
Luke Taylor updated DIRLDAP-87:
-------------------------------
Attachment: TestCase.zip
> Incorrect SearchResult name and "compare" failure using CoreContextFactory
> --------------------------------------------------------------------------
>
> Key: DIRLDAP-87
> URL: http://issues.apache.org/jira/browse/DIRLDAP-87
> Project: Directory LDAP
> Type: Bug
> 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
> Attachments: 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.
-
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
[jira] Commented: (DIRLDAP-87) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Emmanuel Lecharny (JIRA)" <di...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/DIRLDAP-87?page=comments#action_12364479 ]
Emmanuel Lecharny commented on DIRLDAP-87:
------------------------------------------
Luke,
you are totally right. Excerpt from the tutorial :
"If you need to get the entry's full DN, then you can either do some bookkeeping to keep track of the ancestors of the SearchResult or use Context.getNameInNamespace()(in the API reference documentation)."
So I bet we will have to propose a fix for this, too :(
Ok, don't worry. We will try to debug this and give you a reasonnable timeframe for a working patch. Let say a few days ;)
> Incorrect SearchResult name and "compare" failure using CoreContextFactory
> --------------------------------------------------------------------------
>
> Key: DIRLDAP-87
> URL: http://issues.apache.org/jira/browse/DIRLDAP-87
> Project: Directory LDAP
> Type: Bug
> 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
> Attachments: 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.
-
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
[jira] Commented: (DIRSERVER-169) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Luke Taylor (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-169?page=comments#action_12372838 ]
Luke Taylor commented on DIRSERVER-169:
---------------------------------------
Anyone know if these points are still an issue in the latest codebase? Still waiting for Emmanuel's patch timeframe estimate ;-) .
> Incorrect SearchResult name and "compare" failure using CoreContextFactory
> --------------------------------------------------------------------------
>
> Key: DIRSERVER-169
> URL: http://issues.apache.org/jira/browse/DIRSERVER-169
> Project: Directory ApacheDS
> 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
> Attachments: 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.
-
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
[jira] Closed: (DIRSERVER-169) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alex Karasulu closed DIRSERVER-169.
-----------------------------------
Resolution: Later
> 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
> Affects Versions: 1.0.2, 1.0.1, 1.5.0, 1.0, 1.0-RC4, 1.0-RC3, 1.0-RC2, 1.0-RC1, pre-1.0
> 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
> Assignee: Alex Karasulu
> Fix For: 1.5.1
>
> 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.
[jira] Updated: (DIRSERVER-169) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Luke Taylor (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-169?page=all ]
Luke Taylor updated DIRSERVER-169:
----------------------------------
Attachment: DIRSERVER169TestCase.java
Ok. Here's an updated test.
I can't build the RC4 code since I'm running into issues with tools.jar as a dependency (a maven problem with OS X, I believe), but I ran it against the RC3 jars.
The password comparison now appears to work if a string is used for the attribute, but fails for a byte array.
The SearchResult name still appears to be wrong.
Thanks,
Luke.
> Incorrect SearchResult name and "compare" failure using CoreContextFactory
> --------------------------------------------------------------------------
>
> Key: DIRSERVER-169
> URL: http://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
> 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.
-
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
[jira] Updated: (DIRSERVER-169) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny updated DIRSERVER-169:
----------------------------------------
Fix Version/s: (was: 1.0-RC4)
1.0.1
Has to be clearly fixed for 1.0.1 and 1.5.0
> 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.
[jira] Commented: (DIRSERVER-169) Incorrect SearchResult name and
"compare" failure using CoreContextFactory
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472777 ]
Alex Karasulu commented on DIRSERVER-169:
-----------------------------------------
Emmanuel I agree with you on this one but I want to find a reasonable solution for
Luke that fits the expected behavior recommended by JNDI.
However there are some trade off with doing this when dealing with the LDAP
service that sits on top of the server-side JNDI LDAP provider. Namely for efficiency
the LDAP service uses absolute names in the search results to minimize the overhead
of tracking separate contexts and having to assemble the DN. The LDAP service uses
the root context for all operations so DNs and not relative names can be used for search
requests.
Now Luke is using the embedded provider and his issue is with this behavior. What
we can do is make the embedded provider follow the spec yet have the LDAP server
provide an additional environment parameter to always request the absolute DN. However
I don't want to try this without some good amount of testing and we don't have time for
1.0.1. What I will do is put this issue off for 1.0.2 and we can really try to find a reasonable
approach that will make everyone happy.
> 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.