Pete,
this is a fairly common limitation with setting cookies, as it is difficult
for a container to tell what the domain actually is to set - specially
if multiple ports and/or virtual hosts are involved.
However, in the 4.1.0 release of Jetty, just gone out the door and
coming to a JBoss release near you very soon...
There is a support for a context init param org.mortbay.jetty.servlet.SessionDomain
which if set, is used as the domain of all session cookies from that context.
Ditto for o.m.j.s.SessionPath, if you want some for of single signon between
multiple contexts (will need a distributed session manager)
Ditto for o.m.j.s.MaxAge
cheers
> I think I may have discovered a nasty bug in Jetty's cookie based
> session management.
>
> I'm using version JBoss 3.0.2 and Mozilla 1.0 and here's the problem I'm
> encountering.
>
> When jetty creates a cookie for a session (named jsessionid) it doesn't
> set the domain that it applies to. This results in Mozilla (and
> probably other browsers) using the hostname and portnumber to identify
> the cookie.
>
> What this means is that if you switching between SSL and non-SSL mode on
> the same application, you can get *two* cookies (one for each port
> number) and hence two sessions. Therefore you lose your session
> information going between the two.
>
> I can imagine some applications where this may be what you want, but my
> guess is that the majority of web-apps would want to share session
> information between secure and non-secure parts of the site.
>
> Now I can probably write a patch for the Jetty part of JBoss' source
> tree that will fix this problem, but is this the right solution?
>
> Does anyone have any suggestions for me?
--
Greg Wilkins<[EMAIL PROTECTED]> Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http://www.mortbay.com
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
