[jcifs] Null Pointer Exception on using NTLM Authenticaion wi th jcifs 0.7 .0 b3 w/Tomcat 4.1.12
Michael B. Allen
miallen at eskimo.com
Sat Sep 28 05:47:13 EST 2002
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
> 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 =
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.
More information about the jcifs