[jcifs] Problem with NTLM HTTP Auth Filter (NT4.0 IE5.5 JBoss 3.2.1 /Tomcat 4.1.24 Jcifs 0.7.11

eglass1 at comcast.net eglass1 at comcast.net
Wed Aug 13 20:32:53 EST 2003


> Hi all,
>     I have run into problems trying to use jCIFS and can not find any similar 
> listed in the lists. I wonder if somebody has seen a similar problem.
>    The server comes up OK but if I try to invoke a protected page via IE I get 
> the following error:
> 
> 09:09:11,992 ERROR [Engine] StandardWrapperValve[default]: Servlet.service() for 
> servlet default threw exception
>                      java.lang.IllegalArgumentException: setAttribute: 
> Non-serializable attribute

This was briefly alluded to way back when (although it turned out not to be the
problem we were seeing then):

http://lists.samba.org/pipermail/jcifs/2002-December/001621.html

Basically, servlet containers MUST support serializable objects as session
attributes in a distributed environment.  They MAY support non-serializable
objects, and SHOULD throw an IllegalArgumentException if they don't upon
an attempt to store such an object in the session.  They MUST throw an
IllegalArgumentException if addition of the object would prevent migration
of the session in a distributed environment.  Basically, the object being
added must be serializable, or the container must provide a means of migrating
the object; if no such mechanism is available, the exception will be thrown.

NtlmPasswordAuthentication does not implement java.io.Serializable; when it
is added to a distributed session, this will (typically) result in an
IllegalArgumentException.  A quick fix would be to change
NtlmPasswordAuthentication to implement Serializable.  If the
NtlmPasswordAuthentication object is subsequently migrated, the password
hashes would no longer be associated with a valid SmbTransport object.  This
would prevent the creation of SmbFile objects, etc. using the NPA.

However, this may be an acceptable solution -- while the NPA could not be used
for subsequent authentication, its mere presence in the session will indicate
to the filter that the user has been authenticated.

In any case, the worst case scenario is that an attempt to authenticate using
the NPA happens, resulting in an SmbAuthException.  This would result in
a renegotiation of authentication (which should happen silently), replacing
the NPA in the session with a new, valid one.

I *think* this will be okay; in any case I can't really see any downside to
making NtlmPasswordAuthentication serializable.  I'll do some testing to
make sure it doesn't break anything; in the meantime, try modifying
NtlmPasswordAuthentication to implement java.io.Serializable and see
if it works.

Eric



More information about the jcifs mailing list