You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2011/06/06 21:58:05 UTC
DN & Attribute values issue : heads up
Hi guys,
following the two mails I sent today, I'd like to give a bit more heads
up about the pb we are facing
Currently, if we want to get the Dn/Rdn as a String, we have two methods
to do so :
- getName() which returns the User provided Dn's name
- getNormName() which returns the normalized Dn
The toString() method calls getName() internally.
So far, so good, except that it's not enough. There is a confusion
between a 'normalized' DN and a 'Printable' Dn. Let's see with an
example. The following Dn :
"cn= Exa\+mple one "
once parsed, will return the following results :
getName() : "cn= Exa\+mple one "
getNormName() : "cn=Exa\+mple one"
If the Dn is schema aware, the result will be slightly different :
getName() : "cn= Exa\+mple one "
getNormName() : "2.5.4.3=exa\\+mple one"
Now, the problem is that the normalized value is only useful when
manipulating a Dn or a Rdn as a String. There are cases where we want to
compare the Rdn with some AttributeTypeAndValue. For instance, if we
create an entry like :
dn: cn= Exa\+mple one
Objectclass: top
ObjectClass: person
sn: example
cn: exa+mple one
then the server will blow chunks because the CN attribute cannot be
compared to the Rdn ("exa\+mple one" is not equal to "exa+mple one").
I'm not sure right now if the solution would be to normalize the Rdn
again (removing the escaped chars) or to modify the comparison between a
Rdn and an Attribute Value.
Right now, I'm more inclined to investigate the second option, but it
might not work.
In any case, this is a hell of painful issue...
Thoughts ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: DN & Attribute values issue : heads up
Posted by Emmanuel Lécharny <el...@apache.org>.
On 6/7/11 8:22 AM, Stefan Seelmann wrote:
> On Mon, Jun 6, 2011 at 9:58 PM, Emmanuel Lecharny<el...@gmail.com> wrote:
>> Hi guys,
>>
>> following the two mails I sent today, I'd like to give a bit more heads up
>> about the pb we are facing
>>
>> Currently, if we want to get the Dn/Rdn as a String, we have two methods to
>> do so :
>> - getName() which returns the User provided Dn's name
>> - getNormName() which returns the normalized Dn
>>
>> The toString() method calls getName() internally.
>>
>> So far, so good, except that it's not enough. There is a confusion between a
>> 'normalized' DN and a 'Printable' Dn. Let's see with an example. The
>> following Dn :
>>
>> "cn= Exa\+mple one"
>>
>> once parsed, will return the following results :
>> getName() : "cn= Exa\+mple one "
>> getNormName() : "cn=Exa\+mple one"
>>
>> If the Dn is schema aware, the result will be slightly different :
>> getName() : "cn= Exa\+mple one "
>> getNormName() : "2.5.4.3=exa\\+mple one"
> Are there really two backslashes in the normalized DN? That is wrong.
No, it's just a copy from a Java String (so the '\' is duplicated). My bad.
>> Now, the problem is that the normalized value is only useful when
>> manipulating a Dn or a Rdn as a String. There are cases where we want to
>> compare the Rdn with some AttributeTypeAndValue. For instance, if we create
>> an entry like :
>>
>> dn: cn= Exa\+mple one
>> Objectclass: top
>> ObjectClass: person
>> sn: example
>> cn: exa+mple one
>>
>> then the server will blow chunks because the CN attribute cannot be compared
>> to the Rdn ("exa\+mple one" is not equal to "exa+mple one").
> I agree that the DN/RDN's name can't be used. Instead the RDN's AVA
> type and value must be compared with the attribute's type and value.
This is what we do internally, but there are some other problems (see
the mail I sent this morning)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: DN & Attribute values issue : heads up
Posted by Stefan Seelmann <se...@apache.org>.
On Mon, Jun 6, 2011 at 9:58 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Hi guys,
>
> following the two mails I sent today, I'd like to give a bit more heads up
> about the pb we are facing
>
> Currently, if we want to get the Dn/Rdn as a String, we have two methods to
> do so :
> - getName() which returns the User provided Dn's name
> - getNormName() which returns the normalized Dn
>
> The toString() method calls getName() internally.
>
> So far, so good, except that it's not enough. There is a confusion between a
> 'normalized' DN and a 'Printable' Dn. Let's see with an example. The
> following Dn :
>
> "cn= Exa\+mple one "
>
> once parsed, will return the following results :
> getName() : "cn= Exa\+mple one "
> getNormName() : "cn=Exa\+mple one"
>
> If the Dn is schema aware, the result will be slightly different :
> getName() : "cn= Exa\+mple one "
> getNormName() : "2.5.4.3=exa\\+mple one"
Are there really two backslashes in the normalized DN? That is wrong.
> Now, the problem is that the normalized value is only useful when
> manipulating a Dn or a Rdn as a String. There are cases where we want to
> compare the Rdn with some AttributeTypeAndValue. For instance, if we create
> an entry like :
>
> dn: cn= Exa\+mple one
> Objectclass: top
> ObjectClass: person
> sn: example
> cn: exa+mple one
>
> then the server will blow chunks because the CN attribute cannot be compared
> to the Rdn ("exa\+mple one" is not equal to "exa+mple one").
I agree that the DN/RDN's name can't be used. Instead the RDN's AVA
type and value must be compared with the attribute's type and value.
> I'm not sure right now if the solution would be to normalize the Rdn again
> (removing the escaped chars) or to modify the comparison between a Rdn and
> an Attribute Value.
>
> Right now, I'm more inclined to investigate the second option, but it might
> not work.
>
> In any case, this is a hell of painful issue...
>
> Thoughts ?
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>