db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Created: (DERBY-4975) LDAPAuthenticationTest does not heed port number, and other quirks
Date Tue, 18 Jan 2011 01:29:44 GMT
LDAPAuthenticationTest does not heed port number, and other quirks

                 Key: DERBY-4975
                 URL: https://issues.apache.org/jira/browse/DERBY-4975
             Project: Derby
          Issue Type: Bug
          Components: Test
    Affects Versions:
            Reporter: Dag H. Wanvik
            Priority: Minor

The test fails unless Java system property "derbyTesting.ldapPort" is supplied, but it is
not used, so the test cannot be used against an LDAP serves that uses anything than 389 (default

Additionally, the test property "derbyTesting.dnString" is not what it purports to be, since
the parameter given is used as a value for "o=" when doing a search. The property should contain
the entire relevant dn (distinguised name) string which is the root of the lookup, I think,

-DderbyTesting.dnString="o=myOrg"  or

cf. e.g. http://www.ldapman.org/articles/intro_to_ldap.html (quote):

"The top level of the LDAP directory tree is the base, referred to as the "base DN." A base
DN usually takes one of the three forms:"

- o=foobar.com           (base DN derived from the company's Internet presence) 
- o="FooBar, Inc.", c=US (base DN in X.500 format) 
- dc=foobar, dc=com      (base DN derived from the company's DNS domain components) 

This will make the test more independent of actual LDA server organization.

Similarly, the test specifies that ou=People should be used. I this this should be parameterizable
as well.

The attempt to store the dn locally using the "derby.user.<user>" (to avoid lookup)
doesn't seem to be working.  I think there is a bug in LDAPAuthenticationSchemeImpl as well
in this regard:

    // Retrieve the user's DN (Distinguished Name)
    // If we're asked to look it up locally, do it first
    // and if we don't find it, we go against the LDAP
    // server for a look-up (search)
    if (useUserPropertyAsDN)
            userDN =

The lookup happens against the property "derby.user.", the username is not appended first,
so userDN always returns null, and search ensues before bind. I'll file a separate issue for

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

View raw message