About userPassword

[Emmanuel Lecharny <el...@gmail.com>]

Hi guys,

I'm currently dealing with this attribute while integrating the new 
ServerEntry API. In the previous versions of the server, it was 
considered as a String AND as a byte[] (a very quantic attribute... When 
you look at it, it destroys the other possible type :)

Now, I have to be much more strict about such an attribute. It has to be 
String or byte[], but not both. Accordingly to RFC 4511 :

        BindRequest ::= [APPLICATION 0] SEQUENCE {
             version                 INTEGER (1 ..  127),
             name                    LDAPDN,
             authentication          AuthenticationChoice }

        AuthenticationChoice ::= CHOICE {
             simple                  [0] OCTET STRING,
             ...

Here, the credentials is considered to be a byte[], and nothing else. 
The credential is compared to the userPassword attribute stored on the 
server, and this comparison is done using byte[] comparison.

Now, what makes userPassword very special is that users usually type 
their password using their keybord, limitating the password to key chars 
(it's pretty hard to generate a \0 on a keyboard). So the request 
usually comes with a textual userPassword. The very same for search 
requests, where filters contains Strings, and not byte[].However, the 
normalizer interceptor transform a String value into a byte[] in this case.

That being said, there are many places in the code (and mainly in 
tests), where we compare the password as if it was a String. I think 
it's a mistake. I may change this, but I wanted to know if some of you 
have some provision against such a major change (159 references to 
"userPassord " all over the code !)

so, WDYT ?

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: About userPassword

[Alex Karasulu <ak...@apache.org>]

Using byte[] is the way to go.  If it's encountered as a String we should
convert it to a byte[] or remove references to the String all together.

On thing to watch for while doing this is comparisons in code.  Just make
sure you're comparing the content in the array.  Perhaps using
ArrayUtils.isEqual( array1, array2 ).

HTH,
Alex

On Fri, Mar 14, 2008 at 6:12 PM, Emmanuel Lecharny <el...@gmail.com>
wrote:

> Hi guys,
>
> I'm currently dealing with this attribute while integrating the new
> ServerEntry API. In the previous versions of the server, it was
> considered as a String AND as a byte[] (a very quantic attribute... When
> you look at it, it destroys the other possible type :)
>
> Now, I have to be much more strict about such an attribute. It has to be
> String or byte[], but not both. Accordingly to RFC 4511 :
>
>        BindRequest ::= [APPLICATION 0] SEQUENCE {
>             version                 INTEGER (1 ..  127),
>             name                    LDAPDN,
>             authentication          AuthenticationChoice }
>
>        AuthenticationChoice ::= CHOICE {
>             simple                  [0] OCTET STRING,
>             ...
>
> Here, the credentials is considered to be a byte[], and nothing else.
> The credential is compared to the userPassword attribute stored on the
> server, and this comparison is done using byte[] comparison.
>
> Now, what makes userPassword very special is that users usually type
> their password using their keybord, limitating the password to key chars
> (it's pretty hard to generate a \0 on a keyboard). So the request
> usually comes with a textual userPassword. The very same for search
> requests, where filters contains Strings, and not byte[].However, the
> normalizer interceptor transform a String value into a byte[] in this
> case.
>
> That being said, there are many places in the code (and mainly in
> tests), where we compare the password as if it was a String. I think
> it's a mistake. I may change this, but I wanted to know if some of you
> have some provision against such a major change (159 references to
> "userPassord " all over the code !)
>
> so, WDYT ?
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>