You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jan Luehe <Ja...@Sun.COM> on 2005/10/13 03:43:17 UTC
Problem with session invalidation in target context of a RD.include()
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
Re: Problem with session invalidation in target context of a RD.include()
Posted by Yoav Shapira <yo...@apache.org>.
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 <Ja...@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 <Ja...@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
Re: Problem with session invalidation in target context of a
RD.include()
Posted by Jan Luehe <Ja...@Sun.COM>.
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 <Ja...@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
Re: Problem with session invalidation in target context of a RD.include()
Posted by Yoav Shapira <yo...@apache.org>.
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.
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?
Yoav
--- Jan Luehe <Ja...@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