Bug 4690 - sessions not scoped according to spec section 7.3
Summary: sessions not scoped according to spec section 7.3
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Catalina (show other bugs)
Version: Nightly Build
Hardware: All All
: P3 major with 3 votes (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
: 8213 9116 10886 11879 13516 (view as bug list)
Depends on:
Reported: 2001-11-06 14:22 UTC by John McNally
Modified: 2004-11-16 19:05 UTC (History)
10 users (show)

my attempt to fix the problem, did not work do to use of Facade class (10.75 KB, patch)
2001-11-06 14:41 UTC, John McNally
Details | Diff
Cross Context Patch - Add Cookie if able to (4.64 KB, patch)
2004-08-27 02:38 UTC, David H. DeWolf
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description John McNally 2001-11-06 14:22:12 UTC
The session for a request is set according to the context in which the request
originated.  When a request is passed to a servlet in another context the
session object should not be the same as in the original context.

Looking at the code, it appears this boils down to having the context stored in
the request reflect the actual context where the request is currently being
processed.  A mechanism also needs to be in place so that any sessions initiated
in the second (or greater) context in the chain will have the same id as the
session in the original context.

This bug is present in the current CVS and was reported against tomcat and
servlet 2.2 spec as well.
Comment 1 John McNally 2001-11-06 14:41:52 UTC
Created attachment 771 [details]
my attempt to fix the problem, did not work do to use of Facade class
Comment 2 Remy Maucherat 2001-11-06 17:33:37 UTC
I checked the spec, and it seems you're right. I wouldn't categorize it as high 
priority, as I'm not a big fan of cross context access (for security reasons, 
plus I think that webapps should be as self-contained as possible).

The patch appears far reaching and high risk, so it's not going in 4.0.x 
anytime soon (and will be documented as a known issue in all Tomcat 4.0.x 
versions which do have this problem).
Waiting for Craig's opinion on this subject ...
Comment 3 Remy Maucherat 2001-11-29 10:34:56 UTC
This bug is complex to fix, and for this reason will probably not be fixed in 
the 4.0.x branch, but more likely for 4.1. This will be mentioned in the 
release notes.
Comment 4 Remy Maucherat 2002-04-17 16:27:18 UTC
*** Bug 8213 has been marked as a duplicate of this bug. ***
Comment 5 Remy Maucherat 2002-05-15 17:50:28 UTC
*** Bug 9116 has been marked as a duplicate of this bug. ***
Comment 6 Remy Maucherat 2002-07-17 09:57:11 UTC
*** Bug 10886 has been marked as a duplicate of this bug. ***
Comment 7 Remy Maucherat 2002-08-21 07:09:45 UTC
*** Bug 11879 has been marked as a duplicate of this bug. ***
Comment 8 Remy Maucherat 2002-10-11 05:29:54 UTC
*** Bug 13516 has been marked as a duplicate of this bug. ***
Comment 9 louis 2002-12-20 10:54:39 UTC
I hope someone can solve this problem, this is a serious problem to me, and I 
can't think of a solution to solve my problem other than using cross context.

I working on a project which related to goverment policy.  Therefore the 
application has to change every year (I mean the application calculation engine 
and the jsp page).  Although it change to new year application, but the old 
application still has to stay alive for users who haven't migrate their data to 
new year application.  

Every year I have to deploy a new application and allow old application can 
cross context to talk to new application.  Due to the session problem, the 
whole things cannot be done unless I change to another application server.

Now is already version 4.1.18, this bug still haven't solve yet.  Hope someone 
can consider this issue.

My post in tomcat user mailing list:

Comment 10 Remy Maucherat 2003-04-22 08:44:30 UTC
This will not get fixed in Tomcat 4.1.x. Spec people will have to assess the
severity of the problem.
Comment 11 Remy Maucherat 2003-08-05 13:26:19 UTC
This should now be fixed. The fix will be included in 5.0.7.
Comment 12 David H. DeWolf 2004-08-27 02:36:56 UTC
While the new session is now being created and provided to the included
resource, no cookie is being added to the response to allow the session to be
retrieved when direct requests to the included context are recieved.  

(Pluto bug PLUTO-53 depends upon a fix to this issue:

I have have attached a patch.
Comment 13 David H. DeWolf 2004-08-27 02:38:22 UTC
Created attachment 12542 [details]
Cross Context Patch - Add Cookie if able to
Comment 14 Eric Dalquist 2004-08-30 17:13:01 UTC
I tried applying the specified path to 5.0.27 My portlet test still failed. The
portlet's session ID was different than the servlet's session ID.
Comment 15 Yoav Shapira 2004-09-20 18:56:27 UTC
There have been two Servlet Spec versions and many more Tomcat versions since 
this bug was originally filed.  Does this still matter to anyone, or at least 
to the original poster?

Is the latest Servlet Spec (v2.4) clear on this issue?  How is it handled in 
the latest stable Tomcat (5.0.28 at the time of this writing)?  Who would 
object if this issue is closed as WONTFIX, since that's been the effective 
status for a year now?
Comment 16 John McNally 2004-09-20 22:45:27 UTC
I was the original poster and I obviously haven't been waiting 3 years hoping it
will be fixed and I am less dependent on the cross-context behavior now than I
was then.  I simply filed the issue as a failure in the reference implementation
to meet the specification.  

But there are others who are still suffering from this problem and many dupes
were filed as well.  Remy indicates that it should have been fixed, but it
appears there is still a bug.  The problem in Tomcat 4.x was deep in the
architecture, but  it sounds like a solution is closer at hand now, it would
seem a shame to declare it a WONTFIX, if the current bug turns out to be simple.

Resetting this to Tomcat 4 and declaring it WONTFIX while also entering a more
specific defect report in Tomcat 5 might be a reasonable route though. 
Comment 17 David H. DeWolf 2004-09-20 23:37:03 UTC
I would also object.  The Portlet Specification depends upon cross context
functionality working properly and there have been several complaints on the
Pluto user and dev lists about this.  I'm pretty sure that the underlying
problem is in tomcat and not in pluto.  

As I stated before, the fix seems to be implemented halfway.  The session which
is passed to the target context is now unique, however, it is not permenantly
associated with the context and thus can't be retrieved during future requests.
Comment 18 Remy Maucherat 2004-09-21 16:17:51 UTC
I completely disagree with this.
The included session is merely a shadow of the including session. As a result,
it will not be handled as an actual session with an independant cookie. This is
not specified, so this is my interpretation, which should stand until
crosscontext session lifecycle and behavior is actually fully specified.
Comment 19 David H. DeWolf 2004-10-07 05:17:45 UTC
Can you provide some insight on why your interpretation is that this session is
a mere shadow?  What use would a session be if it can't be retrieved later on
for use by subsequent requests?

Can you provide any ideas on how we can meet the requirements of the portlet
specification's Application Scoped attributes (15.3) with your interpretation.
I'm not necessarily a fan of cross context apps either, however, our issue is
that we're trying to implement a specification which *seems* to require a
different interpretation of the servlet spec than yours.  Any help would be
greatly appreciated.
Comment 20 Eric Dalquist 2004-10-07 16:30:11 UTC
I just voted for this bug and wanted to voice a comment as well. uPortal 2.3 and
higher uses the Pluto JSR-168 portlet container in it's framework and is running
into this bug as well. This issue is more pronounced in a portal environment
since the abaility to share a session in the manner described in the bug is
essential for a portlet to securly pass session scoped data to a servlet outside
of the portal to initiate a download or similar action.
Comment 21 Remy Maucherat 2004-10-07 16:32:19 UTC
It's not my fault if the portal JSR decided to make asumptions about the servlet
specification, and then, to be sure that they would piss off people, included
their dubious asumptions in their TCK.
Comment 22 Nick Lothian 2004-10-07 23:29:47 UTC
It seems to me that the only assumption that was made was that sessions would
work normally when used from a cross-context dispatcher. Why is this such a
dubious assumption?
Comment 23 Yoav Shapira 2004-10-10 20:54:32 UTC
I think this is an issue to be resolved between the Portlet Spec people and 
the Servlet Spec people.  Tomcat's implementation is strictly according to the 
Servlet Spec, and is valid (passes all TCKs 100%) according to that Spec.  IF 
the Spec specifies cross-context behavior that we don't support (it doesn't), 
then you'd have a legit Tomcat bug.  

If the Portlet Spec relies on behavior that is unspecified or unclear in the 
Servlet Spec, contact the JSR 154 team (jsr-154-comments@jcp.org) to address 
the issue.  The Servlet Spec, like the Portlet Spec, is very much alive.  I 
would not be surprised to see clarification on this cross-context stuff in 
v2.5 of the Servlet Spec.  And needless to say, the next major Tomcat version 
will implement the next Servlet Spec version accurately and fully, just as it 
does now.  But until such a Spec change is made, this is not a Tomcat bug.
Comment 24 David H. DeWolf 2004-10-14 13:11:07 UTC
This bug has been resolved through the patch referenced to below:


Anyone wanting to use this functionality must remember to set the
"emptySessionPath" attribute in their connector configuration.  An example is below.

<Connector port="8080" maxThreads="150" minSpareThreads="25"
           maxSpareThreads="75" enableLookups="false"
           redirectPort="8443" acceptCount="100"
           connectionTimeout="20000" disableUploadTimeout="true"
           emptySessionPath="true" /> 

Many thanks to the Tomcat team for working with us to find an acceptable
solution to all parties!