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

[Michael B. Allen]

On Fri, 27 Sep 2002 07:27:22 -0400
"Glass, Eric" <eric.glass at capitalone.com> wrote:

> > 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:

Well,  maybe I don't need to. What is the preferred way to uniqely identify
a  session? I could just keep a static Hashtable of NtlmHttpSession objects
keyed by something unique about the session? 

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

This could definately be usefull.

> 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);

Funny  you should mention this because I think I will need to do a redirect
for  something  a  little  unrelated.  When  a  user wants to access an SMB
resource  (e.g. a file somewhere) using the credentials negotiated via NTLM
I  have  to  get hashes for *both* the server authenticating the client and
the  server  hosting  the requested resource. If they are separate requests
this  doesn't  occur  but  if  they are authenticating and accessing an SMB
resource  in  the  same  request  I need to do two NTLM HTTP Authentication
negotiations.  I  was  thinking  a redirect might do the trick? If I send a
redirect will that close the session first? Can I reliably request that the
client  re-access  the same resource so I can do the negotiation twice with
two different challenges? 

> 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.

So this is the uniqe bit of information I need.

-- 
A  program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes  the  potential  for it to be applied to tasks that are
conceptually  similar and more importantly to tasks that have not
yet been conceived.