No continuation references for referrals returned for some search filters

• Key: DIRSERVER-806
• Type: Bug
• Status: Reopened
• Priority: Minor
• Assignee: Emmanuel Lecharny
• Reporter: Stefan Zoerner
• Component/s: core
• Affects Version/s: 1.0.1, 1.0
• Fix Version/s: 1.0.3

Environment

* ApacheDS 1.0.1 (SNAPSHOT)
* Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
* Windows XP Professional SP2

Description

I have created a referral entry below the example partition like this:

dn: cn=theReferral,dc=example,dc=com
objectclass: top
objectClass: referral
objectClass: extensibleObject
cn: theReferral
ref: ldap://someHost:389/cn=somewhere

Afterwards I have performed some searches in order to check whether ApacheDS returns a search result continuation reference. I used JNDI and set Context.REFERRAL to "throw" in order to check whether I get a ReferralException.

Case 1:
Base: dc=example,dc=com
Filter: (objectClass=*)
Scope: sub

=> ApacheDS delivers a continuation reference with the search result. I get an exception at the client.

Case 2:
Base: dc=example,dc=com
Filter: (cn=Nick Cave)
Scope: sub

=> Other than expected, ApacheDS does not deliver a continuation reference with the search result. No exception occurs.

Note that the only change is the filter expression.

I have created a JUnit testcase to demonstrate the situation. It has been successfully tested with other Directory servers (OpenLDAP, IBM, Sun). I'll attach it soon.

Comments

[Stefan Zoerner]

Here is a JUnit testcase which uses JNDI to demonstrate the problem described in this issue. It contains to tests and passes completely with the following servers:

* Sun Java System Directory Server 5.2
* IBM Tivoli Directory Server 6.0
* OpenLDAP 2.3

With ApacheDS 1.0.1, one of the two tests (testSimpleContinuationWithCnFilter) fails, no referral is returned.

[Emmanuel Lecharny]

To be fixed in 1.0.1 and 1.5.0

The problem is that the current server doe snot natively handle such searches for refferal : you have to add the Context.REFERRAL=throw property in order to get a referral exception. The current default implementation is to ignore the referral.

If one add this property to the request, both tests are passing.

I guess that we should change this behavior to default to THROW instead of IGNORE.

[Stefan Zoerner]

Emmanuel, thanks for your investigations! Do you mean that it is sufficient to change the configuration within server.xml?
Something like this?

...
<bean id="environment" class="org.springframework.beans.factory.config.PropertiesFactoryBean">
    <property name="properties">
      <props>
        <prop key="java.naming.security.authentication">simple</prop>
        <prop key="java.naming.security.principal">uid=admin,ou=system</prop>
        <prop key="java.naming.security.credentials">******</prop>
        <prop key="java.naming.referral">throw</prop>
        ...

I'll try this out. Perhaps it is an option for my customer to simple configure the server that way.

[Emmanuel Lecharny]

Stefan, this is so good to work with smart people :) I wasn't even aware of such a property in the configuration file !

Ok, I can't guarantee that it will solve the problem, but maybe. Give it a try and give us some feedback !

[Alex Karasulu]

RE changing the default to THROW instead of IGNORE:

(1) is this the expected default for JNDI Providers?

(2) what side effects do we expect to see if we do this?

Yes and try mucking with the parameter in the configuration file :).

[Stefan Zoerner]

Unfortunately, simply adding the parameter in the server.xml does not cause the test case to pass.

Please note that this is a problem which currently blocks blocks both 1.0.x and 1.5.x from passing the STANDARD profile of the Open Group Certification. But because the 1.0 is certified for the BASE profile only, this issue is not a blocker for a 1.0.1 release. The latter would still be certified with the same level as the 1.0.0 (which obviously is expected by our users), because it can pass all relevant tests, without fixing this issue.

[Emmanuel Lecharny]

Postponed to 1.0.2. This bug is not serious (we can live with it for a little while), but fixing it is quite complicated.

The idea is to release the 1.0.1 version now, so that users can have a better version (1.0.0 has serious issues that we can't live with).

[Emmanuel Lecharny]

I may have fixed this issue in 1.0.2 :
http://svn.apache.org/viewvc?view=rev&rev=523116
and the test :
http://svn.apache.org/viewvc?view=rev&rev=523115

I hope this is correct !

[Emmanuel Lecharny]

Ok, after more investigation this morning ( the patch has been committed yesturday evening, 2 am, and I was too tired to confirm the fix), I saw that in 1.5.0, the code has been fixed. I just forgot to backport it to 1.0.2, so I guess it was a corrct patch because I fixed it twice in the same way :)

Marked as resolved, unless Stefan disagree.

[Stefan Zoerner]

Unfortunately, the method testSimpleContinuationWithCnFilter of the provided JUnit test still fails with the 1.0.2-SNAPSHOT.

[Emmanuel Lecharny]

As the 1.0.2 release has been issued, push this bug to 1.0.3