Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Thu, 13 Oct 2005 10:08:41 -0700
From: Jan Luehe <Jan.Luehe@Sun.COM>
Subject: Re: Problem with session invalidation in target context of a
 RD.include()
In-reply-to: <20051013023826.25178.qmail@web40623.mail.yahoo.com>
To: Tomcat Developers List <dev@tomcat.apache.org>
Reply-to: Jan.Luehe@Sun.COM
Message-id: <434E9499.8050206@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214
References: <20051013023826.25178.qmail@web40623.mail.yahoo.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 <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