[jcifs] A bug in 1.2.17 ?
asaf.mesika at gmail.com
Mon Nov 26 08:49:06 GMT 2007
I suspected so, but from some reason changing it to Arrays.equals solves a
special case I've built in our product:
We have a web application, running on JBoss (with embedded Tomcat). The
security model in JBoss is split to two parts:
2. JAAS Login Module.
I wanted to implement an NTLM authentication scheme, thus I had to split the
Servlet Filter in the jCIFS package in two parts:
The 1st part, the Authenticator, handles the negotiation with the client,
until an NtlmPasswordAuthentication is obtained.
The 2nd part, the Login Module, performs the login to the domain controller,
using the NtlmPasswordAuthentication (with the SmbSession.logon).
The NtlmPasswordAuthentication object is passed between the two parts using
XStream, which means its converted to XML and back to an object.
The XML method creates the situation in which the auth.challenge is not the
same object as session.transport.server.encryptionKey but *contains the same
What do you think?
Maybe you can give me some pointers to understand why there's need to check
it is the same object and not check the contents alone?
On Nov 26, 2007 12:47 AM, Michael B Allen <miallen at ioplex.com> wrote:
> On Sun, 25 Nov 2007 17:43:28 +0200
> "Asaf Mesika" <asaf.mesika at gmail.com> wrote:
> > The following condition:
> > *auth.challenge != session.transport.server.encryptionKey
> > *checks for equality between two byte *arrays* .
> Hi Asaf,
> That is not a bug.
> There is a difference between checking the equality of the contents of
> two byte arrays and determining if two variables refer to exactly the
> same array. In the above case we are checking to see if auth.challenge
> and session.transport.server.encryptionKey refer to the same exact
> array object.
> Don't worry, you're not the only person to report this "bug" :->
> Michael B Allen
> PHP Active Directory SPNEGO SSO
-------------- next part --------------
HTML attachment scrubbed and removed
More information about the jcifs