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

[anshuman_aggarwal at non.agilent.com]

My original problem remains the same!!! since the cookies are enabled is there anything else esp. from the PDC side that needs to be done for NTLM authentication

Thanks in advance,

> -----Original Message-----
> From: Michael B. Allen [mailto:miallen at eskimo.com]
> Sent: Friday, September 27, 2002 12:47 PM
> To: Glass, Eric
> Cc: jcifs at lists.samba.org
> Subject: Re: [jcifs] Null Pointer Exception on using NTLM 
> Authenticaion
> wi th jcifs 0.7 .0 b3 w/Tomcat 4.1.12
> 
> 
> 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. 
>