[jcifs] Null Pointer Exception on using NTLM Authenticaion wi th jcifs 0.7 .0 b3 w/Tomcat 4.1.12

[Glass, Eric]

> -----Original Message-----
> From: Michael B. Allen [mailto:miallen at eskimo.com]

> 
> Err, so if cookies are disabled you can't store objects in the
> HttpSession? That doesn't seem right.
> 
The servlet spec discusses 3 methods of maintaining the session:

1. The JSESSIONID Cookie (the most common, and the only method a servlet
container is required to support)

2. SSL sessions (SSL provides a mechanism for tracking client requests, so
the spec suggests that this would be an easy way to support sessions over
HTTPS).

3. URL rewriting, supported by HttpServletRequest.encodeURL and
.encodeRedirectURL.  This is not strictly required by the spec, but is
fairly universally supported by real-world containers.  This involves
rewriting a URL such as "http:/somehost/example.jsp" as a path parameter
named "jsessionid" like "http://somehost/example.jsp;jsessionid=1234".

According to the Javadoc for HttpServletRequest.encodeURL,

"For robust session tracking, all URLs emitted by a servlet should be run
through this method. Otherwise, URL rewriting cannot be used with browsers
which do not support cookies."

However, there isn't any real way to do this in the NTLM filter, since there
isn't anything to rewrite.  What happens is:

1.  Client connects and requests the resource.

2.  The servlet container creates a new HttpSession object on demand and
stores the NtlmHttpSession object in it.  The filter sends the 401 response
with the type 1 message, and the servlet container adds the JSESSIONID
set-cookie response header.

2.  Client replies with the type 2 response, but has declined the cookie, so
doesn't send the cookie request header.

3.  The servlet container determines that this is a new session (since it
received neither a cookie or a rewritten request) and creates a new session
when the NtlmHttpFilter calls request.getSession().

4.  When the filter attempts to retrieve the NtlmHttpSession object from the
HttpSession, it gets a null and throws a NullPointerException on line 162.


I can't think of any easy way to finagle the filter to support URL
rewriting; I suppose you could do something like:


1.  When the initial request comes in, access the session and check
session.isNew().  If the session is not new, proceed normally.

2.  If the session is new, we can't determine reliably whether the client
supports cookies (since we haven't sent them one yet); redirect the client
to an encoded URL:

	String encoded =
response.encodeRedirectURL(request.getRequestURL().toString());
	response.sendRedirect(encoded);

3.  When the client reconnects, the session should be established.  Since
they are accessing the resource via the encoded URL, the subsequent type 1
and type 3 requests should contain the encoded session ID as well.


> > msg.substring( 5 )));" in line 162 is redundant -- this 
> could be rewritten
> > as "Base64.decode(src);" to avoid the overhead of 
> re-decoding the message
> > content.
> 
> Or just decodeType3Message( src ).
> 
>

Sorry -- that's what I meant (confused fingers).
 
**************************************************************************
The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.