You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Stefan Seelmann <ma...@stefan-seelmann.de> on 2016/02/22 21:02:31 UTC

Multi-valued RDN with same attribute allowed?

Hi,

I'm currently looking into DIRSTUDIO-987. The latest comment shows an
multi-valued RDN which uses the same attribute multiple times:

    dn: l=eu + l=de + l=Berlin + l=Brandenburger Tor, ...

Is that valid? Our Rdn class doesn't allow that. RFC 4512 section 2.3.1
doesn't forbid that.

Kind Regards,
Stefan

Re: Multi-valued RDN with same attribute allowed?

Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
On 02/24/2016 01:10 AM, Emmanuel Lécharny wrote:
> Le 23/02/16 19:34, Emmanuel Lécharny a écrit :
>> Le 22/02/16 21:02, Stefan Seelmann a écrit :
>>> Hi,
>>>
>>> I'm currently looking into DIRSTUDIO-987. The latest comment shows an
>>> multi-valued RDN which uses the same attribute multiple times:
>>>
>>>     dn: l=eu + l=de + l=Berlin + l=Brandenburger Tor, ...
>>>
>>> Is that valid? Our Rdn class doesn't allow that. RFC 4512 section 2.3.1
>>> doesn't forbid that.
>>>
>>> Kind Regards,
>>> Stefan
>> Hmmm...
>>
>> It's not that simple to implement. I can easily have the RDN accepting
>> multiple AVAs with the same type, but then we need to change the
>> equals() method :
>>
>>         Rdn rdn1 = new Rdn( schemaManager, " cn = c + cn = b " );
>>         Rdn rdn2 = new Rdn( schemaManager, " cn = b + cn = c " );
>>        
>>         assertEquals( rdn1, rdn2 );
>>
>> fails.
> Ok, here is what I suggest :
> 
> - first, we accept a RDN with more than one AVA with the same AT (but
> the value must be different).
> 
> For instance : cn=a + cn=b will be accepted, but cn=a + cn=A will be
> rejected
> 
> - second, we will order the AVA by their AT first, then by their value
> (assuming we have a ORDERING matching rule, of course)
> 
> currently, we order those AVA by the AVA's attributes only (because we
> weren't accepting multiple AVAs with the same AT). It will not be
> complicated to order the values too.
> 
> This should not be such a big change.
> 
> In any case, it deserves a JIRA.
> 

Thanks Emmanuel! Jira is DIRAPI-271.


Re: Multi-valued RDN with same attribute allowed?

Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 23/02/16 19:34, Emmanuel Lécharny a écrit :
> Le 22/02/16 21:02, Stefan Seelmann a écrit :
>> Hi,
>>
>> I'm currently looking into DIRSTUDIO-987. The latest comment shows an
>> multi-valued RDN which uses the same attribute multiple times:
>>
>>     dn: l=eu + l=de + l=Berlin + l=Brandenburger Tor, ...
>>
>> Is that valid? Our Rdn class doesn't allow that. RFC 4512 section 2.3.1
>> doesn't forbid that.
>>
>> Kind Regards,
>> Stefan
> Hmmm...
>
> It's not that simple to implement. I can easily have the RDN accepting
> multiple AVAs with the same type, but then we need to change the
> equals() method :
>
>         Rdn rdn1 = new Rdn( schemaManager, " cn = c + cn = b " );
>         Rdn rdn2 = new Rdn( schemaManager, " cn = b + cn = c " );
>        
>         assertEquals( rdn1, rdn2 );
>
> fails.
Ok, here is what I suggest :

- first, we accept a RDN with more than one AVA with the same AT (but
the value must be different).

For instance : cn=a + cn=b will be accepted, but cn=a + cn=A will be
rejected

- second, we will order the AVA by their AT first, then by their value
(assuming we have a ORDERING matching rule, of course)

currently, we order those AVA by the AVA's attributes only (because we
weren't accepting multiple AVAs with the same AT). It will not be
complicated to order the values too.

This should not be such a big change.

In any case, it deserves a JIRA.

Re: Multi-valued RDN with same attribute allowed?

Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 22/02/16 21:02, Stefan Seelmann a écrit :
> Hi,
>
> I'm currently looking into DIRSTUDIO-987. The latest comment shows an
> multi-valued RDN which uses the same attribute multiple times:
>
>     dn: l=eu + l=de + l=Berlin + l=Brandenburger Tor, ...
>
> Is that valid? Our Rdn class doesn't allow that. RFC 4512 section 2.3.1
> doesn't forbid that.
>
> Kind Regards,
> Stefan
Hmmm...

It's not that simple to implement. I can easily have the RDN accepting
multiple AVAs with the same type, but then we need to change the
equals() method :

        Rdn rdn1 = new Rdn( schemaManager, " cn = c + cn = b " );
        Rdn rdn2 = new Rdn( schemaManager, " cn = b + cn = c " );
       
        assertEquals( rdn1, rdn2 );

fails.

Re: Multi-valued RDN with same attribute allowed?

Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 22/02/16 21:02, Stefan Seelmann a écrit :
> Hi,
>
> I'm currently looking into DIRSTUDIO-987. The latest comment shows an
> multi-valued RDN which uses the same attribute multiple times:
>
>     dn: l=eu + l=de + l=Berlin + l=Brandenburger Tor, ...
>
> Is that valid? Our Rdn class doesn't allow that. RFC 4512 section 2.3.1
> doesn't forbid that.
>
> Kind Regards,
> Stefan
IMO, we should accept such DN. There is nothing in the RFC that
explicitely forbid it.

The code that checks that an AVA is not already in use can be found in
teh AVA class :


    /* Unspecified protection */void addAVA( SchemaManager
schemaManager, Ava value ) throws LdapInvalidDnException

            ...
            case 1:
                // We already have an Ava. We have to put it in the HashMap
                // before adding a new one.
                // Check that the first AVA is not for the same attribute
                if ( avaType.equals( normalizedType ) )
                {
                    throw new LdapInvalidDnException( "Invalid RDN: the
" + normalizedType
                        + " is already present in the RDN" );
                }
            ...
            default:
                // Check that the AT is not already present
                if ( avaTypes.containsKey( normalizedType ) )
                {
                    throw new LdapInvalidDnException( "Invalid RDN: the
" + normalizedType
                        + " is already present in the RDN" );
                }
            ...

In order to fix the bad behaviour, we would have to change the way we
feed the avaTyps, which is a multiMap anyway (ie, teh key is associated
to a list, so adding a new value would work).