Hi,
> 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.
It should be considered at all. If the cookie does not contain a valid ID,
then check the session id that comes from the URL.
As I pointed out, the session IDs could indeed be different, if in a
previous session the user accepted a cookie and -- after the first session expired
-- starts a new session, but this time rejects the cookie, so URL encoding is
necessary. The browser, however, will still send the old cookie.
In that case the cookies session-id will not lead to a successful
HttpSesison lookup, but the URLs session id will. This is why we need to
check both IDs one after another if the first fails to bring up a
successful session lookup.
Another aspect of the same story is why we have to make the decision,
whether a URL encoding is necessary, make dependent on the fact,
that the requested session id came from a cookie _and_ that this session
id actually is _our_ current, valid session id; this can be fixed
relativly simple:
##########
--- catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java
+++ catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java
@@ -491,7 +491,8 @@
HttpSession session = hreq.getSession(false);
if (session == null)
return (false);
- if (hreq.isRequestedSessionIdFromCookie())
+ if (hreq.isRequestedSessionIdFromCookie()
+ && session.getId().equals(hreq.getRequestedSessionId()))
return (false);
// Is this a valid absolute URL?
##########
The testcase servlet
<http://www.freiheit.com/users/hzeller/SessionBugDemonstration.java>
simulates this.
(probably not a
very likely use-case .. but while testing applications this happens all
the time).
> 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.
No, the use-case is what I mentioned above. The broken client is
hypothetical; the problem was, that I didn't know about the way the client
should send (and suppress) cookies so I assumed that this might be an
additional problem.
> 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 :-).
Even if - it would be good if the server would be robust in that case,
right ?
ciao,
-hen
--
Henner Zeller
Dipl.-Inform. Med.
freiheit.com technologies gmbh
Theodorstr. 42-90 / 22761 Hamburg, Germany
fon +49 (0)40 / 890584-0
fax +49 (0)40 / 890584-20
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
