directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject About userPassword
Date Fri, 14 Mar 2008 22:12:20 GMT
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



Mime
View raw message