[Bug 44216] Don't reuse session ID even if emptySessionPath=true
https://issues.apache.org/bugzilla/show_bug.cgi?id=44216 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Mark Thomas ma...@apache.org --- Coming back to this after far too long. If this request were implemented I don't believe the problem would be solved or, at lease, a new one would be created. Reviewing the borken case assuming the requested option was avaialable and enabled: - The user navigates to the website and get the session yyy.t2from T2. - He then bookmarks a URL with session id in it like the one above. - The next day, he navigates to the website again and get the session xxx.t1 from T1. - He then selects bookmarked URL. = The request is redirected to T2. The session is invalid so a new one is created zzz.t2. This overwrites yyy.t2 created at step 1. Any information associated with session yyy.t2 is now lost. The way to fix this would be to fix the load-balancer so that the node information from the cookie session ID takes precedence over the node information in the URL session ID. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 44216] Don't reuse session ID even if emptySessionPath=true
https://issues.apache.org/bugzilla/show_bug.cgi?id=44216 Mark Thomas ma...@apache.org changed: What|Removed |Added Component|Catalina|Catalina Version|Unknown |unspecified Product|Tomcat 5|Tomcat 7 --- Comment #1 from Mark Thomas ma...@apache.org 2011-12-20 20:36:23 UTC --- This Tomcat 5 enhancement request has been moved to Tomcat 7 (the latest version) since Tomcat 5 development is limited and focussed on bugs and security issues whereas Tomcat 7 is still seeing new feature development. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47298] enabled emptysessionpath not checking if route replacement is needed
https://issues.apache.org/bugzilla/show_bug.cgi?id=47298 --- Comment #2 from James Hoare james.hoa...@ntlworld.com 2009-06-11 06:07:19 PST --- When we take a node down for maintenaince we experience problems with the exisitng sessions that were created on that node. These sessions are bouncing between the other nodes, as the worker has been removed from the mod_jk workers file. Therefore, we need the susbsequent check in ManagerBase to replace the jvm route with the local node if they are different. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47298] enabled emptysessionpath not checking if route replacement is needed
https://issues.apache.org/bugzilla/show_bug.cgi?id=47298 --- Comment #3 from Filip Hanik fha...@apache.org 2009-06-11 09:28:36 PST --- James, I see your issue. While the documentation http://tomcat.apache.org/tomcat-6.0-doc/config/http.html only has the behavior documented as setting cookie Path=/ it over 4 years ago also introduced a side effect of creating a session with the supplied ID. This behavior is too old to be changed in the way you requested, even though its not properly documented. In Tomcat 7 (Servlet 3.0) there is a standard way of configuring the session cookie paramneters (such as path) so this wont be an issue. For Tomcat 6, I will attach a simple code solution that would work to rewrite the JVM route in a Valve to solve your problem. I will therefor close the issue as WONT FIX. Please see my attached valve for how you could solve your specific use case. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47298] enabled emptysessionpath not checking if route replacement is needed
https://issues.apache.org/bugzilla/show_bug.cgi?id=47298 --- Comment #4 from Filip Hanik fha...@apache.org 2009-06-11 09:29:56 PST --- Created an attachment (id=23796) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=23796) Work around for undocumented behavior of emptySessionPath -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47298] enabled emptysessionpath not checking if route replacement is needed
https://issues.apache.org/bugzilla/show_bug.cgi?id=47298 Filip Hanik fha...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47298] enabled emptysessionpath not checking if route replacement is needed
https://issues.apache.org/bugzilla/show_bug.cgi?id=47298 --- Comment #1 from James Hoare james.hoa...@ntlworld.com 2009-06-03 02:21:13 PST --- We have uncommented the route node replacement code in ManasgerBase and built from source and this seems to be working on our QA environment. So is it possible to get this into the next point release? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47298] New: enabled emptysessionpath not checking if route replacement is needed
https://issues.apache.org/bugzilla/show_bug.cgi?id=47298
Summary: enabled emptysessionpath not checking if route
replacement is needed
Product: Tomcat 6
Version: 6.0.18
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: james.hoa...@ntlworld.com
Hi, our app currently relies on using the attribute emptysessionpath=true on
the ajp connector due to having most of our
urls not containing the context path of our web app.
We are having trouble with the jvmroute switching as the Tomcat code doesn't
appear to
check if the jvmroute is valid for that node? I noticed in the
org.apache.catalina.session.ManagerBase there is some code that is
commented out, which would fix the route replacement.
Is it possible to uncomment the route replacement check below in ManagerBase?
code from ManagerBase:
if (sessionId == null) {
sessionId = generateSessionId();
// FIXME WHy we need no duplication check?
/*
synchronized (sessions) {
while (sessions.get(sessionId) != null) { // Guarantee
// uniqueness
duplicates++;
sessionId = generateSessionId();
}
}
*/
// FIXME: Code to be used in case route replacement is needed
/*
} else {
String jvmRoute = getJvmRoute();
if (getJvmRoute() != null) {
String requestJvmRoute = null;
int index = sessionId.indexOf(.);
if (index 0) {
requestJvmRoute = sessionId
.substring(index + 1, sessionId.length());
}
if (requestJvmRoute != null
!requestJvmRoute.equals(jvmRoute)) {
sessionId = sessionId.substring(0, index) + . +
jvmRoute;
}
}
*/
}
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 44216] New: - Don't reuse session ID even if emptySessionPath=true
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=44216. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=44216 Summary: Don't reuse session ID even if emptySessionPath=true Product: Tomcat 5 Version: Unknown Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Context: - I want my webapp to use nice URL for a user's homepage (e.g. http://server/user;) which is then redirected server side to the real URL (e.g. http://server/servlet/home?user=user;). This requires to use emptySessionPath. - I'm using a load-balancer with two Tomcat servers (say T1 and T2) with sticky sessions (xxx.t1, yyy.t2, ...). - Because some http client don't support cookies or are started by another http client (e.g. progressive video download in Media Player started by clicking in link in Firefox), some links have the session id in the URL (e.g. http://server/servlet/stream/yyy.t2/music.mp3). Broken case: - The user navigates to the website and get the session yyy.t2from T2. - He then bookmarks a URL with session id in it like the one above. - The next day, he navigates to the website again and get the session xxx.t1 from T1. - He then selects bookmarked URL. = The request is redirected to T2. The session is invalid so a new one is created. But because of the cookie, the session id is xxx.t1. So now we have a session created on T2 with a jvmRoute t1. So the following requests will be send to T1 instead of T2 with an inconsistent (or even expired) session. There should be two independent options: - emptySessionPath which only change the path of the session cookie but nothing else - reuseSessionID which will reuse the session id from the cookie if available -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
emptySessionPath=
Hi, I have a portal application and introduced recently emptySessionPath=true to have access to the same objects in the session in my servlets and my portlets, both sitting in the same webapp. First observation I made is the repeated use of the same session id despite invalidating the corresponding session. I found out that this is by intention [1], but it leaves a strange gut feeling. Why is a session id an arbitrary string, which is under normal circumstances really hard to guess - if I do not need to predict it at all since I know it when having access to the PC (without any XSS issue)? I only have to wait until the user logs in the next time to hijack his session, don't I? But ignoring that one for the moment and blaming the portlet spec [2] I found another issue ... From what I observed not all sessions assigned to this session id are invalidated. This seems to be true for different portals, I found at least uPortal [3], JetSpeed [4] and Liferay [5] (using it myself). Of course it's possible that the portals are to blame but I wonder if they manage the sessions themselves or if they don't only forward it to the application container. At least in Liferay the HttpSession for the portal is invalidated, but I can access objects in the session of my webapp (portlets + servlets). Here the reused session id gets also very critical. So I agree with Aaron Evans who reported this issue for JetSpeed [6]: I don't think this is a jetspeed problem but rather a tomcat/tomcat SSO issue, but I was just wondering if others have seen this behaviour. And like his idea how it should work [7]. So actually there are two issues, (1) always using the same session id, (2) not invalidating all sessions associated with one session id. I wonder if there has changed anything for the former since that thread [1] since I'm using the most recent 5.5 release 23. Or if it is solvable at all. But the latter seems to be a real issue for me. Can you please comment on it? Regards, Joerg [1] http://marc.info/?t=11077928475r=1w=4 [2] http://marc.info/?l=tomcat-devm=112092302521008w=4 [3] http://www.ja-sig.org/issues/browse/UP-1590 [4] http://issues.apache.org/jira/browse/JS2-582 [5] http://support.liferay.com/browse/LEP-1852 [6] http://www.mail-archive.com/[EMAIL PROTECTED]/msg03195.html [7] http://www.mail-archive.com/[EMAIL PROTECTED]/msg03203.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: emptySessionPath=
Joerg Heinicke wrote: First observation I made is the repeated use of the same session id despite invalidating the corresponding session. I found out that this is by intention [1], but it leaves a strange gut feeling. Why is a session id an arbitrary string, which is under normal circumstances really hard to guess - if I do not need to predict it at all since I know it when having access to the PC (without any XSS issue)? I only have to wait until the user logs in the next time to hijack his session, don't I? It's not easier or harder, since it is possible to maintain a session for a user if you know the id. The session id, which is set using a session cookie, will change when the user closes the browser. It should be easy to use a valve (or a filter) to perform additional checks if you feel you need them in your particular use case. But ignoring that one for the moment and blaming the portlet spec [2] I found another issue ... From what I observed not all sessions assigned to this session id are invalidated. This seems to be true for different portals, I found at least uPortal [3], JetSpeed [4] and Liferay [5] (using it myself). Of course it's possible that the portals are to blame but I wonder if they manage the sessions themselves or if they don't only forward it to the application container. At least in Liferay the HttpSession for the portal is invalidated, but I can access objects in the session of my webapp (portlets + servlets). Here the reused session id gets also very critical. It's your problem: this is not SSO, and the sessions remain fully independent. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: emptySessionPath=
On Jun 4, 2007, at 8:43 AM, Joerg Heinicke wrote: Hi, I have a portal application and introduced recently emptySessionPath=true to have access to the same objects in the session in my servlets and my portlets, both sitting in the same webapp. First observation I made is the repeated use of the same session id despite invalidating the corresponding session. I found out that this is by intention [1], but it leaves a strange gut feeling. Why is a session id an arbitrary string, which is under normal circumstances really hard to guess - if I do not need to predict it at all since I know it when having access to the PC (without any XSS issue)? I only have to wait until the user logs in the next time to hijack his session, don't I? But ignoring that one for the moment and blaming the portlet spec [2] I found another issue ... From what I observed not all sessions assigned to this session id are invalidated. This seems to be true for different portals, I found at least uPortal [3], JetSpeed [4] and Liferay [5] (using it myself). Of course it's possible that the portals are to blame but I wonder if they manage the sessions themselves or if they don't only forward it to the application container. At least in Liferay the HttpSession for the portal is invalidated, but I can access objects in the session of my webapp (portlets + servlets). Here the reused session id gets also very critical. So I agree with Aaron Evans who reported this issue for JetSpeed [6]: I don't think this is a jetspeed problem but rather a tomcat/ tomcat SSO issue, but I was just wondering if others have seen this behaviour. And like his idea how it should work [7]. So actually there are two issues, (1) always using the same session id, (2) not invalidating all sessions associated with one session id. I wonder if there has changed anything for the former since that thread [1] since I'm using the most recent 5.5 release 23. Or if it is solvable at all. But the latter seems to be a real issue for me. Can you please comment on it? IMO the area of cross-context session management is basically not specified in the servlet and portlet specs. It certainly relies on a lot of extrapolation to make a usable product. My conclusions are that to make a usable portal possible, while deploying portlet applications as web apps, the servlet container has to create a cross context session id, and manage individual sessions for each web app context that uses this sessionId, and when one session is invalidated in this collection, invalidate all sessions for that sessionId. AFAICT this is consistent with the servlet spec, although it is certainly not specified behavior according to the servlet spec. In a little more detail: - sessions are indexed by sessionId and context-root (or other web app identifier) - invalidating one session (for a sessionId + context-root) invalidates all other sessions with that sessionId After a lot of discussion with the jetty devs I got them to implement this, but I've never been able to understand the discussions about the subject on the tomcat lists so I'm really not sure what the expected behavior of tomcat is. thanks david jencks Regards, Joerg [1] http://marc.info/?t=11077928475r=1w=4 [2] http://marc.info/?l=tomcat-devm=112092302521008w=4 [3] http://www.ja-sig.org/issues/browse/UP-1590 [4] http://issues.apache.org/jira/browse/JS2-582 [5] http://support.liferay.com/browse/LEP-1852 [6] http://www.mail-archive.com/[EMAIL PROTECTED]/ msg03195.html [7] http://www.mail-archive.com/[EMAIL PROTECTED]/ msg03203.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
