IE Cookie Scoping Rules & JSESSIONID

[jim kraai <jk...@murl.com>]

Greetings,

I'm a Tomcat newbie and apologize if this is the wrong forum for this.

The problem:
If a cookie w/ name JSESSIONID is set for domain.com, then it is 
visible to MSIE browsers accessing sub.domain.com.  Or sub.domain.com 
cookies are visible when browsing sub.sub.domain.com servers with MSIE.

This is bad for me if I want to have distinct sessions for distinct 
domains which happen to be 'nested' and when I am trying to do multiple 
virtual hosting.

What I'd like to do is replace "JSESSIONID" with something that 
depends on the full host name, say "JSESSIONID"+request.getServerName().

I can see that I want to drop the Constants.Cookie.SESSION_NAME_COOKIE 
in src/share/org/apache/tomcat/core/ServerSessionManager.java and use 
request.getServerName(), but when I try to run, it gives a runtime 
null pointer exception on startup.

Obviously I'm approaching this from the wrong angle because it looks 
like the Request object is being instantiated at startup, rather than 
on receipt of request.  Is there an object that knows the requested 
host name that gets instantiated at request time that I can query for 
the requested host name?

I would greatly appreciate any/all suggestions.  I would gladly do the 
work and submit any changes for review and inclusion in a later Tomcat 
release.  I want to "Get Involved".

Thanks,

--jim

Re: IE Cookie Scoping Rules & JSESSIONID

[jim kraai <jk...@murl.com>]

Craig,

Thanks for the response.

"Craig R. McClanahan" wrote:
> 
> jim kraai wrote:
> 
> > Greetings,
> >
> > I'm a Tomcat newbie and apologize if this is the wrong forum for this.
> >
> 
> This is the right forum.
> 
> > What I'd like to do is replace "JSESSIONID" with something that
> > depends on the full host name, say "JSESSIONID"+request.getServerName().
> >
> > [...]
> 
> The cookie name "JSESSIONID" is required by the servlet 2.2 specification,
> so that proxy servers and load balancing implementations can portably
> recognize session id cookies.  Therefore, this change is not the right thing
> to do.

Ok, suppose that I do something like:

  setAttribute(request.serverName,MySessionObject)
where MySessionObject is a Hash with whatever goodies that I want to 
associate with that particular host.

Since I don't currently make use of session id, or creation/access times, 
I don't suppose I'll start missing them now--nor is there anything 
preventing me from adding those attribs to MySessionObject myself.

> > Obviously I'm approaching this from the wrong angle because it looks
> > like the Request object is being instantiated at startup, rather than
> > on receipt of request.  Is there an object that knows the requested
> > host name that gets instantiated at request time that I can query for
> > the requested host name?
> 
> What really needs to happen is that Tomcat's support for virtual hosts needs
> to be more robust.  It should be feasible to use the same cookie name (as
> the spec requires) for different virtual hosts, and different web apps on
> the same virtual host, with no conflicts.

Um, since I know nothing :-) about how well Tomcat does virtual hosting 
I suppose I'll just learn the hard way about what it does do.

> There's (at least) two primary efforts going on right now for you to look
> at.
> 
> On the main code branch in the CVS repository, efforts are going on to clean
> up and rearrange the current code base (Costin is the primary person doing
> the heavy lifting).  It would be helpful to evaluate and propose bug fixes
> related to virtual host support on this path (but the changes need to be
> compliant with the servlet spec :-).

I'll be reading the servlet spec in detail (time to battle _that_ white whale, 
anyway) right away.  Hate not knowing what I'm talking about--like now.

> A second discussion called "Catalina" is going on, regarding a proposal for
> a component-oriented architecture for the guts of the Tomcat servlet
> engine.  The source code (and proposal doc) can be found under the
> "proposals/catalina" directory in the source tree.  At this point there are
> example implementations of some of the components, but it is not yet a fully
> functional servlet container.  Help would be appreciated there as well.

ok, I'll browse after I digest the servlet spec.

Thanks!

--jim

Re: IE Cookie Scoping Rules & JSESSIONID

["Craig R. McClanahan" <cm...@mytownnet.com>]

jim kraai wrote:

> Greetings,
>
> I'm a Tomcat newbie and apologize if this is the wrong forum for this.
>

This is the right forum.

>
> The problem:
> If a cookie w/ name JSESSIONID is set for domain.com, then it is
> visible to MSIE browsers accessing sub.domain.com.  Or sub.domain.com
> cookies are visible when browsing sub.sub.domain.com servers with MSIE.
>
> This is bad for me if I want to have distinct sessions for distinct
> domains which happen to be 'nested' and when I am trying to do multiple
> virtual hosting.
>
> What I'd like to do is replace "JSESSIONID" with something that
> depends on the full host name, say "JSESSIONID"+request.getServerName().
>
> I can see that I want to drop the Constants.Cookie.SESSION_NAME_COOKIE
> in src/share/org/apache/tomcat/core/ServerSessionManager.java and use
> request.getServerName(), but when I try to run, it gives a runtime
> null pointer exception on startup.
>

The cookie name "JSESSIONID" is required by the servlet 2.2 specification,
so that proxy servers and load balancing implementations can portably
recognize session id cookies.  Therefore, this change is not the right thing
to do.

>
> Obviously I'm approaching this from the wrong angle because it looks
> like the Request object is being instantiated at startup, rather than
> on receipt of request.  Is there an object that knows the requested
> host name that gets instantiated at request time that I can query for
> the requested host name?
>

What really needs to happen is that Tomcat's support for virtual hosts needs
to be more robust.  It should be feasible to use the same cookie name (as
the spec requires) for different virtual hosts, and different web apps on
the same virtual host, with no conflicts.

>
> I would greatly appreciate any/all suggestions.  I would gladly do the
> work and submit any changes for review and inclusion in a later Tomcat
> release.  I want to "Get Involved".
>

There's (at least) two primary efforts going on right now for you to look
at.

On the main code branch in the CVS repository, efforts are going on to clean
up and rearrange the current code base (Costin is the primary person doing
the heavy lifting).  It would be helpful to evaluate and propose but fixes
related to virtual host support on this path (but the changes need to be
compliant with the servlet spec :-).

A second discussion called "Catalina" is going on, regarding a proposal for
a component-oriented architecture for the guts of the Tomcat servlet
engine.  The source code (and proposal doc) can be found under the
"proposals/catalina" directory in the source tree.  At this point there are
example implementations of some of the components, but it is not yet a fully
functional servlet container.  Help would be appreciated there as well.

>
> Thanks,
>
> --jim
>

Craig McClanahan