tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Luehe <Jan.Lu...@Sun.COM>
Subject Problem with session invalidation in target context of a RD.include()
Date Thu, 13 Oct 2005 01:43:17 GMT
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


Mime
View raw message