[jcifs] jcifs on J2EE compliant server

[Allen, Michael B (RSCH)]

> -----Original Message-----
> From:	Glass, Eric [SMTP:eric.glass at capitalone.com]
> Sent:	Wednesday, December 11, 2002 6:23 AM
> To:	'Allen, Michael B (RSCH)'; Tieu, Kiet L
> Cc:	jcifs at lists.samba.org
> Subject:	RE: [jcifs] jcifs on J2EE compliant server
> 
> 
> > 
> > > This is fairly interesting... one of the internal Sun One 
> > classes is 
> > > apparently attempting to cast the 
> > NtlmPasswordAuthentication object to 
> > > something it does not implement.  Since it couldn't 
> > conceivably have any 
> > > knowledge regarding the internal jCIFS classes, my only 
> > guess would be 
> > > that it is attempting to serialize the objects in the 
> > HttpSession (and 
> > > is casting the NtlmPasswordAuthentication object to 
> > > java.io.Serializable).  This would require more investigation to 
> > > confirm, however.  If this turns out to be the case, 
> > > NtlmPasswordAuthentication could be made to implement Serializable 
> > > fairly easily; in fact, you could just add it to the 
> > implements class 
> > > and recompile the jCIFS classes if you wanted to test this out.
> > > 
> > 	I don't see how this would work. The ansiHash and 
> > unicodeHash are
> > 	specific to a particular SmbTransport. If an 
> > NtlmPasswordAuthentication
> > 	object is marshalled into another/new VM using some 
> > form of serialization
> > 	the hashes will be wrong. Or is this not what the 
> > container is trying to do?
> > 
> > 
> > 
> 
> That was pure speculation on my part -- servlet containers are required to
> support storage of Serializable objects in the session, but are NOT required
> to support storage of non-serializable objects (although most do, and simply
> throw exceptions upon attempts to actually serialize the session).  The
> container is supposed to throw an IllegalArgumentException upon insertion
> into the session of an invalid object (defined by the spec as "objects where
> the container cannot support the mechanism necessary for migration of a
> session storing them").  I was just speculating that the container was
> instead simply casting to Serializable.  This is incorrect -- I downloaded
> the Sun One application server (a hefty 97 MB) and did some further
> investigation.  One of the app server's internal classes is attempting to
> do:
> 
> if (httpservletrequest.getUserPrincipal() != null) {
>     WebPrincipal webprincipal = (WebPrincipal)
> httpservletrequest.getUserPrincipal();
>     ....
> }
> 
> It is essentially trying to cast the principal object (in our case, an
> NtlmPasswordAuthentication) to an internal principal implementation (which
> would work if our filter was not being applied).  This will fail when any
> filter is used which applies a request wrapper and overrides
> getUserPrincipal to return a different implementation.  This would appear to
> be a bug in the Sun One application server; according to the servlet spec:
> 
> "Central to the notion of filtering is the concept of wrapping a request or
> response in
> order that it can override behavior to perform a filtering task. In this
> model, the
> developer not only has the ability to override existing methods on the
> request and
> response objects, but to provide new API suited to a particular filtering
> task to a
> filter or target web resource down the chain. For example, the developer may
> wish to
> extend the response object with higher level output objects that the output
> stream or
> the writer, such as API that allows DOM objects to be written back to the
> client.
> 
> In order to support this style of filter the container must support the
> following
> requirement. When a filter invokes the doFilter method on the container's
> filter
> chain implementation, the container must ensure that the request and
> response
> object that it passes to the next entity in the filter chain, or to the
> target web
> resource if the filter was the last in the chain, is the same object that
> was passed
> into the doFilter method by the calling filter."
> 
> 
> In other terms, when our filter calls:
> 
> 	chain.doFilter(new NtlmHttpServletRequest(req, ntlm), response);
> 
> it is the container's responsibility to ensure that the next filter (or
> target resource) in the chain receives the NtlmHttpServletRequest object we
> passed in.  It is therefore NOT safe for the application server to assume
> that any specific implementation will be provided.
> 
> It IS required that the wrapper class wrap the request provided to the
> doFilter method (this ensures that at the top of the wrapped "stack" the
> container's implementation class is present); therefore, one correct
> approach for the Sun One class would be:
> 
> 
> while (httpservletrequest instanceof HttpServletRequestWrapper) {
>     httpservletrequest = (HttpServletRequest)
>             ((HttpServletRequestWrapper) httpservletrequest).getRequest();
> }
> if (httpservletrequest.getUserPrincipal() != null) {
>     WebPrincipal webprincipal = (WebPrincipal)
> httpservletrequest.getUserPrincipal();
>     ....
> }
> 
> 
> That is, they need to fully unwrap the request to ensure that they are
> dealing with the base request object.
> 
	So you make it sound like it is legal to override getUserPrinciple. If so then
	it's a bug in their server to assume they will get a WebPrinciple. Sounds like
	jCIFS will just not work with the Sun One server period.