On Wed, 3 Jul 2002, Henner Zeller wrote:
> Date: Wed, 3 Jul 2002 21:10:14 +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,
> > If you want the *current* session for this request, you should always call
> > request.getSession() instead.
>
> Yes. This is correctly working in tomcat 3.x: the getRequestedSessionId()
> returns one of the IDs with preference to the cookie; the getSession()
> returns the current session. perfect.
>
> However: in tc 4.x this does not work anymore since
> internal lookup uses the requestedSessionId:
>
> (From HttpRequestBase:)
> -------
> if (requestedSessionId != null) {
> try {
> session = manager.findSession(requestedSessionId);
> } catch (IOException e) {
> session = null;
> }
> }
> if ((session != null) && !session.isValid())
> session = null;
> -------
>
> But this should be something like
> -------
> if (requestedSessionIdFromCookie != null) {
> try {
> session = manager.findSession(requestedSessionIdFromCookie);
> } catch (IOException e) {
> session = null;
> }
> }
> if ((session != null) && !session.isValid())
> session = null;
>
> // if the session still is null, then consider the id from the URL.
> if (session == null && requestedSessionIdFromURL != null) {
> try {
> session = manager.findSession(requestedSessionIdFromURL);
> } catch (IOException e) {
> session = null;
> }
> }
> if ((session != null) && !session.isValid())
> session = null;
>
> -------
> Thats my whole point.
>
OK, but why should the requested session id from the URL be considered any
more likely to be valid than a session id from the cookie? They both got
created at the same time (when this page was generated), and will have the
same value if you did the normal thing of using response.encodeURL() to
create the rewritten URL.
>
> > If case (b) happens, your client is broken.
>
> admitted ;-)
>
That's the only scenario I can think of where you'd get a cookie with a
session id from some other webapp, which seems to be the use case you'd
want this change of behavior for. Is there another one that I'm missing?
And if it really is a broken client that causes this, I don't think that's
a very compelling reason to change the server's behavior :-).
> -hen
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
