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

[Glass, Eric]

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

That's kind of a gotcha -- it can't (reliably) be done strictly on the
server side, due to the fundamental issue that HTTP is a stateless protocol;
cookies/URL rewriting (or some other method of telling the client, "when you
come back I need you to give me this so I can identify you") are pretty much
necessary.  IIS appears to handle the client tracking by requiring a
keep-alive; if the subsequent requests came across the same connection, they
are considered part of the same session (for purposes of the NTLM auth
sequence).  Unfortunately, the servlet API doesn't provide access to that
low-level information about the connection between the server and client.

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

The session, once established on the server, will exist until explicitly
closed or until the max inactive interval expires -- as long as the client
gives the server a recognizable token by which the server can retrieve the
session (i.e., cookie or path parameter for the jsessionid), it should be
usable across redirects, etc.

The big caveat with doing a redirect comes with handling POST requests;
according to the HTTP spec, GET and HEAD requests can be automatically
redirected, but clients handling POST redirects must prompt the user before
redirecting.  In actuality, most clients (including, I believe, both IE and
Netscape) change the request to a GET and then redirect automatically.  This
may or may not pose an issue, depending on whether the target actually
requires a POST.


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