tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yoav Shapira <yo...@apache.org>
Subject Re: Problem with session invalidation in target context of a RD.include()
Date Thu, 13 Oct 2005 17:43:10 GMT
Hi,
Ahh, good.  I didn't consider that use-case, and it's evil indeed.  Thank you
for pointing that out.  Option 2 seems better as you suggested.

Yoav

--- Jan Luehe <Jan.Luehe@Sun.COM> wrote:

> Hi Yoav,
> 
> Yoav Shapira wrote On 10/12/05 19:38,:
> > Hi,
> > I don't want to chop off any parts of your email because it nicely
> establishes
> > the context for the question, so I'll leave it all below.
> 
> Thanks!
> 
> > It's not obvious to me that option #1 is not acceptable.  It raises the bar
> on
> > the includer, perhaps, but it's not obviously unacceptable.  Am I missing
> some
> > relevant portion of the Servlet Spec here?
> 
> No. I agree Option 1 raises the bar on the includer, but not every
> includer may be aware of it.
> 
> If only the includer needed to be aware of this, Option 1 may not be
> so unacceptable, but in the case where the includer issues multiple
> RD.include() operations in parallel, the issue becomes more serious.
> 
> For example, the portal server (webapp) simultaneosuly executes several
> portlets (from different webapps) aggregated on a portal page, by
> spawning as many threads and having each thread perform a RD.include()
> to the target portlet.
> 
> If any of the portlets acquire a session, invalidate it, and then
> request a new session, Option 1 would require not only the session in
> the origin context, but any session in any of the other portlets to be
> invalidated as well, because the session in the origin context and the
> sessions in the target (portlet) contexts all share the same id.
> 
> With Option 2, neither the session in the origin context nor the
> sessions in any of the other portlets would be affected.
> 
> 
> Jan
> 
> 
> > 
> > Yoav
> > 
> > --- Jan Luehe <Jan.Luehe@Sun.COM> wrote:
> > 
> > 
> >>I have a question regarding session invalidation in the target context
> >>of a RequestDispatcher.include().
> >>
> >>Some background info: The current impl of package
> >>org.apache.catalina.core.ApplicationHttpRequest.getSession() creates a
> >>session in the target context of a RD.include() as follows:
> >>
> >>- Checks if the origin context has any active session.
> >>- If the origin context has no active session, creates a session in
> >>  the origin context.
> >>- Creates a session in the target context, and assigns to it the
> >>  id of the session in the origin context.
> >>
> >>The requirement of having the sessions in the origin and target
> >>contexts share the same session id is due to the fact that any context
> >>that is the target of a RD.include() must not change any of the
> >>response headers (and therefore must not add any Set-Cookie response
> >>header) as per the Servlet Spec (SRV.8.3).
> >>
> >>This approach has worked well - as long as the target context
> >>does not decide to invalidate its session and acquire a new
> >>session. In that scenario, the current impl returns the invalidated
> >>session as the new session, causing IllegalStateException to be thrown
> >>when the session is accessed. This is because we currently don't
> >>check if "localSession", which is assigned as follows:
> >>
> >>    localSession = context.getManager().findSession(other.getId());
> >>
> >>is valid before returning it.
> >>
> >>We can easily fix this so that the invalidated session is no longer
> >>returned, but what should the newly generated session look like?
> >>I can see the following options:
> >>
> >>If the target context invalidates its session and then requests a new
> >>session ....
> >>
> >>- OPTION 1:
> >>
> >>  ... we also invalidate the session in the origin context, create
> >>  a new session in the origin context, create a new session in the
> >>  target context, and assign the id of the new session in the origin
> >>  context to the new session in the target context. Obviously, this
> >>  option is unacceptable as it destroys any session data in the origin
> >>  context.
> >>
> >>- OPTION 2:
> >>
> >>  ... in the target context, we purge the invalidated session immediately
> >>  before creating a new session and assigning to it the session id
> >>  of the invalidated session (which is still equal to the id of the
> >>  session in the origin context). This approach would violate the
> >>  uniqueness requirement of session ids per context, but I don't see
> >>  this as a problem, because this is happening within the same request.
> >>
> >>
> >>Any other opinions?
> >>
> >>
> >>Thanks,
> >>
> >>
> >>Jan
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >>For additional commands, e-mail: dev-help@tomcat.apache.org
> >>
> >>
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message