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
