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 <elecharny@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