On Wed, 3 Jul 2002, Henner Zeller wrote:
> Date: Wed, 3 Jul 2002 20:33:11 +0200 (CEST)
> From: Henner Zeller <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: [Bug 10419] - Session-ID grabbing from Request accepts
> invalid session cookies in presense of valid URL sessions
>
>
> Hi,
> > > We always have the problem, that we might get multiple session ids (from
> > > the URL, from _multple_ cookies).
> >
> > You should not be getting multiple session id cookies for different
> > webapps unless (a) the context paths overlap, or (b) your client is not
> > following the rules of the specs. See my comments on Bug 10419 for more
> > info on how situation (a) is dealt with.
>
> ok, sounds good.
> Considering that the client sends the right cookie for that context first,
> there is the only problem, that we still can get two session-ids in
> a request
> o from the URL
> o from the cookie.
>
> Currently, a cookie overrides a session-id that has been gotten from the
> URL unconditionally.
True.
> The whole point here is: if that session id from the cookie is
> invalid because:
> a) The session in the cookie is expired or has been invalidated
That does not change the fact that this is the session id that the
application originally requested (as opposed to the current one for this
request). That is what things like getRequestedSessionId() are supposed
to return. Also, the session id requested in the URL is just as likely to
have been expired or timed out as the session id requested with a cookie
-- there is no a priori reason to believe that it would be "better".
If you want the *current* session for this request, you should always call
request.getSession() instead.
> b) The session in the cookie comes from a different application
> context because for _this_ application context there is no
> cookie, thus the other cookie is placed first
> we don't get a HttpSession in the application since it tries to look up
> it with the wrong ID.
>
If case (b) happens, your client is broken. It should not be sending the
session id cookies for webapp "/foo" to webapp "/bar" on the same host,
because that would mean it's ignoring the path attribute on the cookie.
> If users have cookies enabled all the time, this is probably not the case.
> Others might be a bit more picky when to allow cookies and in that case
> the 'override anything requested in the URL' scheme might not be a good
> idea. Dealing with both possible session ids and give preference to the
> one that is currently valid in that context should be the goal.
>
> -hen
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
