Hi all!

I have found the cause for defect DIRSERVER-606. In fact there are two
problems within class OldAuthorizationService. I will provide a patch
for your verification soon. But there is still one thing, I do not
understand (and which looks more important to me).

class org.apache.directory.shared.ldap.name.LdapName has an equals
method, which is frequently used within OldAuthorizationService, and
which is case sensitive:

LdapName name1 = new LdapName("cn=Fiona Apple,ou=users,ou=system");
LdapName name2 = new LdapName("cn=fiona apple,ou=users,ou=system");
System.err.println("name1               = "+name1);
System.err.println("name2               = "+name2);
System.err.println("name1.equals(name2) = "+name1.equals(name2));

prints out

name1               = cn=Fiona Apple,ou=users,ou=system
name2               = cn=fiona apple,ou=users,ou=system
name1.equals(name2) = false

Is this intended? Or is it a bug? (=> JIRA?)

Thanks in advance, Stefan

[ Post a follow-up to this message ]

Stefan Zoerner a écrit :

> Hi all!
>
> I have found the cause for defect DIRSERVER-606. In fact there are two
> problems within class OldAuthorizationService. I will provide a patch
> for your verification soon. But there is still one thing, I do not
> understand (and which looks more important to me).
>
> class org.apache.directory.shared.ldap.name.LdapName has an equals
> method, which is frequently used within OldAuthorizationService, and
> which is case sensitive:
>
> LdapName name1 = new LdapName("cn=Fiona Apple,ou=users,ou=system");
> LdapName name2 = new LdapName("cn=fiona apple,ou=users,ou=system");
> System.err.println("name1               = "+name1);
> System.err.println("name2               = "+name2);
> System.err.println("name1.equals(name2) = "+name1.equals(name2));
>
> prints out
>
> name1               = cn=Fiona Apple,ou=users,ou=system
> name2               = cn=fiona apple,ou=users,ou=system
> name1.equals(name2) = false

Well, there is no way to compare two different DNs without knowing about
the  syntax of the types. LdapName  has no information about how to
compare two CNs, or two OUs, or whatever Attribute type. So the straight
comparizon is done using a case sensitive approach.

From a user standpoint, true, both DN are equals. But from LdapName,
they are different.

In the server, DN comparizon are done using another mechanism, because
the server is aware of AttributesType. It knows that CN values are to be
trimmed and case insensitive should be done.

So the pb in DIRSERVER-606 is related to the straight use of equals
method, which shoul dnot be used (we should compare internal
representation on DNs, not String representation, so we must first parse
the string and then compare the result with the other parsed string.)

I gonna have a look at this problem, may be Alex could confirm my
opinion about this point, or correct me if I'm wrong.

Emmanuel

[ Post a follow-up to this message ]

Emmanuel Lecharny wrote:
> Stefan Zoerner a écrit :
> 
>
> Well, there is no way to compare two different DNs without knowing about
> the  syntax of the types. LdapName  has no information about how to
> compare two CNs, or two OUs, or whatever Attribute type. So the straight
> comparizon is done using a case sensitive approach.
>
>  From a user standpoint, true, both DN are equals. But from LdapName,
> they are different.

Yes, this is probably a reasonable decision. But note that class
javax.naming.ldap.LdapName (Java 5) ignores case (same situation: you
can create DNs from a String without schema information). Maybe it would
be better to have a comparable behavior here.

> In the server, DN comparizon are done using another mechanism, because
> the server is aware of AttributesType. It knows that CN values are to be
> trimmed and case insensitive should be done.
>
> So the pb in DIRSERVER-606 is related to the straight use of equals
> method, which shoul dnot be used (we should compare internal
> representation on DNs, not String representation, so we must first parse
> the string and then compare the result with the other parsed string.)

I will try to create a solution for DIRSERVER-606. This
OldAuthorizationService seems to be somehow deprecated, but as long as
we ship with it (service is enabled by default), it should work
properly. Currently, we have for instance this problem (not filed in
JIRA yet, same cause):

Standard installation 1.0RC1,

$ ldapsearch -D "uid=admin,ou=system" -w ****** -h localhost -p 10389 -b
"uid=admin,ou=system" -s base "(objectclass=*)"

lists the admin entry (as expected), but this here lists nothing:

$ ldapsearch -D "uid=Admin,ou=system" -w ****** -h localhost -p 10389 -b
"uid=admin,ou=system" -s base "(objectclass=*)"

(bind is successful, but result list is empty due to
OldAuthorizationService + equals for principalDn "uid=Admin...").

> I gonna have a look at this problem, may be Alex could confirm my
> opinion about this point, or correct me if I'm wrong.

Thanks for clarification, Emmanuel !

[ Post a follow-up to this message ]

Stefan Zoerner a écrit :
 
>
>
> Yes, this is probably a reasonable decision. But note that class
> javax.naming.ldap.LdapName (Java 5) ignores case (same situation: you
> can create DNs from a String without schema information). Maybe it
> would be better to have a comparable behavior here.

That's a pretty valid point. I think it will close the discussion 

The problem is that LdapName.equals is heavily used (135 references
through the project), so modifying it will be costly !!! However, the
sooner we start, the sooner it will be fixed 

Emmanuel

[ Post a follow-up to this message ]