Duplicate ? [Bug 10899] = 10711
Hi, I think, this is a duplicate for http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10711 The patch given for that (see bug report) should fix the same problem. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10899 jsp:forward page=../test.jsp / Summary: jsp:forward page=../test.jsp / Product: Tomcat 4 Version: 4.1.7 Platform: All OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The relative url can't be converted to absolute url. I think it's useful. -- 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]
Re: [Bug 10419] - Session-ID grabbing from Request accepts invalidsession cookies in presense of valid URL sessions
Hi, [- this disucsses Bug 10419 and 10418. See details in http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419 and http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10418 with a bug-demonstration servlet http://www.freiheit.com/users/hzeller/SessionBugDemonstration.java this works with JServ and tomcat 3.2 but fails with tc 4.x --- ] Your statement is incorrect. URL encoding does work, but it is a all-or-nothing situation (ie, either you allow session cookies or you don't). Users do sometimes allow cookies for one situation and not for another. The applications shouldn't fail because of this - at least should the application server (tomcat) not make decisions that only the application developer can do. And letting an application fail because once the client used cookies but then in another session chooses not to is not good. Especially, since you cannot do anything to work around this problem in the application since this decision is made in tc. This makes things more fragile which is never good for enterprise quality. And I hope enterprise quality is what we should expect from the flagship of servlet engines! We always have the problem, that we might get multiple session ids (from the URL, from _multple_ cookies). The expected behaviour of getRequestedSessionId() is of course, that it should return a session ID that is (if possible) valid in our context, not just _any_ of the session IDs we got. The servlet spec is not very precise in this point stating, that the getRequestedSessionId() might not necessarily the same as the session in use. However, tomcats lookup mechanism for HttpSessions, does: the id returned by getRequestedSessionId() is the _same_ that is used to lookup the session in the context -- and if this is not a valid session id, we don't get _any_ HttpSession. Or a different problem caused by the same behaviour: Think of the simple use case that is explained in Bug #7588: if we have multiple sessions in different contexts that all use cookies, then all sessions will fail to work but the first one (having the first cookie) Problem here is: there are multiple cookies, but only one of it is valid in an specific context. Just fetching the _first_ cookie ist not possible: only the first application will work (because it can look up a valid HttpSession with the session id), but others not: the first cookie does not denote a valid session id in that context. So: if we use the result of getRequestedSessionId() to lookup the HttpSession (which makes sense), that we _have_ to make sure that we extract the sessionid from the multiple sessionids we might get in the request that actually makes sense in that context. Suggestion: The alternative would be to make getSession() [ HttpRequestBase.doGetSession() ] look itself in the http-request to look for a valid session id from the assortment of possible session ids. instead of using requestedSessionId. Even better would be to delay the determination of requestedSessionId until the context is known: on the first call of getRequestedSessionId() in the application [ and cache the result ]. This would enhance the performance as well in the HttpProcessor.parseHeaders(), since we do the check only if it is necessary at all (Delaying expensive operations is always a good idea). Ok, I'll prepare a patch for this, then we can discuss this. ciao, -hen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Bug 10419] - Session-ID grabbing from Request accepts invalidsession 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. 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 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 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 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Bug 10419] - Session-ID grabbing from Request accepts invalidsession 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.
If case (b) happens, your client is broken.
admitted ;-)
-hen
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Bug 10419] - Session-ID grabbing from Request accepts invalidsession cookies in presense of valid URL sessions
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]
4.0/4.1: Session handling without cookies broken
Hi Guys,
I recently had the pleasure to work more with web applications and am now
finding my way back to the server source. First impression: tomcat grew
big, compared to JServ times .. but it seems, that its actual main aim,
being a small, robust and fast servlet engine - isn't as dominant as it
used to be ... (any folks here from the good ol' JServ times ? At least I
see Pier quite often in the list).
Anyway, while making the wingS application framework
(http://wings.mercatis.de/) work with Tomcat 4.x, I've
found two bugs in TC, that go hand in hand, but basically make
working with URL encoded sessions unpredictable or basically not working.
(If applications rely on URL-encoding, then these can be regarded as
critical bugs).
Both bugs show up, if invalidated sessions come via cookies from the
browser.
Bug #2 can have an impact as well if multiple session cookies for
different servlet contextes on that hosts are available: only the first
cookie is accepted. Didn't verify this, but if failing as expected,
then this is a severe bug, because only the first servlet context will
work with a session ...
These bugs are in both CVS versions of tomcat 4.0 and 4.1.
One of the bugs can be easily fixed (fix given), the other bug
probably needs a bit more work.
An example servlet that exposes both bugs is available.
*
Bug #1 ; fix available
*
The logic to determine whether a URL needs to be encoded in
HttpServletResponse.encodeURL() is broken. In
HttpServletResponseBase.isEncodeable(String location), it
decides, that the URL needn't be encoded in the URL, if the
current ID comes from the cookie; see code-snippet from
HttpServletResponseBase:
---
if (hreq.isRequestedSessionIdFromCookie()) {
return (false);
}
--
However, this does not take into account, that the session ID we got
might have been from some previous session that already is invalidated,
i.e. is not valid. In this case isRequestedSessionIdFromCookie() will
return true, but this does not say anything if future (valid) sessions
will come through the cookie.
The fix is easy: So the only way to check this correctly is:
-
if (hreq.isRequestedSessionIdFromCookie()
hreq.isRequestedSessionIdValid()) {
return (false);
}
-
*
Bug #2 ; detailed explanation but no fix yet
*
There is a bug in the way, the session id is grabbed
from the request. If there is more than one session id in the request
-- in the URL and a Cookie, for instance -- the session id found in the
cookie _always_ wins. This is a problem, if the browsers sends an
invalidated cookie and you choose to use URL-encoding in a later session:
even if the session id from the URL (via encodeURL(), that works only
after fixing Bug #1) is valid, the application always gets the old
and invalid session from the cookie instead of the valid session from the
URL.
The expected behaviour of course is: give preference to valid session
id's if we get more than one session id.
The current session id grabbing-from-http-request algorithm is as follows
(from HttpProcessor.java)
1. get the session ID from the URL, if any.
[HttpProcessor.parseRequest()]
2. go through the cookies. If there is _any_
jsessionid - grab the _first one_ and
override the jsession-id found in the
URL unconditionally. And set
request.setRequestedSessionCookie(true);
request.setRequestedSessionURL(false);
even if the jsession id found in the
cookie is the _same_ as found in the URL,
in that case it should be
setRequestedSessionURL(true).
[HttpProcessor.parseHeaders()]
-
However, it should be something like:
-
1. get the jsessionid from the URL, if any.
if found there, setRequestedSessionURL(true)
else setRequestedSessionURL(false)
2. go through the cookies.
FOREACH jsessionid found in the cookies:
IF the sessionid found is valid in that context
IF found session id equals id already in request
setRequestedSessionCookie(true)
ELSE (* see below)
override the session id in request with the cookie-value
setRequestedSessionCookie(true)
setRequestedSessionURL(false)
ENDIF
BREAK FOREACH
ELSE IF we have not found any session id before
(either from URL or a previous cookie)
// set at least some session id
set the session id from the cookie
setRequestedSessionCookie(true)
END FOREACH
-
This makes sure, that we find the valid session id, if there is more than
one session.
discussion
I'd even suggest to give a higher priority to the
URL encoded session: if the session id found in the URL is _valid_,
then ignore any valid session id in the cookies unless it is the same.
This enables to have two independant web-application instances in the
Re: Valves, requests and getting the session
Hi, Yes, I am. I need to check to see if certain objects are in the session and if not, see if they are in another session that is pointed to by the Cookie id. It's like SingleSignOn, but slightly different. However I'm a bit confused to why I can't get a session, even when the rest of the app (the jsp pages etc) are making good use of it., The headers also show the session id, but oddly enough calling HttpServletRequest.SessionIdFromCookie() returns true, but HttpServletRequest.isRequestSessionIdvalid() returns false! Maybe this is a similar problem I had when trying to fix the bug described in my previous posting: the Context is not yet set (HttpRequestBase.setContext()) at that stage - thus HttpServletRequest.isRequestSessionIdValid() will return false (see implementation of isRequestSessionIdValid()). Henner. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
