Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core HttpServletResponseFacade.java

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Jason Hunter wrote:

> craigmcc@locus.apache.org wrote:
> >
> > craigmcc    00/04/05 12:40:22
> >
> >   Modified:    src/share/org/apache/tomcat/core
> >                         HttpServletResponseFacade.java
> >   Log:
> >   Correct the implementation of encodeURL() and encodeRedirectURL() so that
> >   they correctly determine when encoding should take place.  For the record,
> >   those rules are as follows:
> >   - We are in a valid session
> >   - The session ID was not requested with a cookie
> >   - The URL to be encoded references a URL within the current
> >     web application (that is, we match on the scheme, host, port,
> >     and context path of the absolute URL that corresponds to
> >     the specified URL if it is relative)
>
> Is that last bullet right?  Shouldn't we do encoding for the entire
> server?  It wouldn't harm anything.  The user would still have different
> HttpSession objects per context, but the user could go from webappA to
> webappB and back without losing their session.  We set a cookie for the
> entire site (or at least we used to).  Why not do encoding the same way?
>

You're correct that we used to set the cookies for the entire site.  The problem
was that you DID lose your session when you went from one webapp to another on the
same machine, because the new webapp scribbled on the old session id cookie (same
name + same host === same cookie as far as the browser was concerned).  This was
fixed by setting the "path" property of the cookie to the context path of the
webapp -- in other words, you're effectively creating a cookie per webapp.

On URL encoding, one potential "harm" to encoding based on the same host, instead
of the same host+context path, is that you're exposing your session key to a
(potentially malicious) "other" application, which can now use it to impersonate
you on the original app.  That would not be a Good Thing (tm).  By the way, the
cookie fix described above avoids this problems for cookies, because the browser
sends only the relevant cookie for whichever webapp you're sending a request to at
the time.

>
> On a related note....
>
> The 2.2 spec says in 11.6 that "a servlet container is required to track
> authentication information at the container level and not at the web
> application level allowing a user who is authenticated against one web
> application to access any other resource managed by the container which
> is restricted to the same security identity."
>
> Considering that form-based auth is commonly based on session tracking,
> how are we to satisfy this requirement between web apps?
>

Its going to have to be done in a container-specific manner outside the servlet
spec -- probably with a site-wide cookie issued by the container.  Don't bother to
look at the current Tomcat code for form-based authentication; it's nowhere near
complete yet, and the current architecture makes this particular functionality
pretty difficult to impement.

>
> -jh-
>

Craig

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core HttpServletResponseFacade.java

[Jason Hunter <jh...@acm.org>]

Craig R. McClanahan wrote:
> you're exposing your session key to a
> (potentially malicious) "other" application
> which can now use it to impersonate
> you on the original app.  
> That would not be a Good Thing (tm).  

Good Point (tm).

Wonder how many other servers realize this?

-jh-