RE: Tabbed browsers sharing session - work around.
We have a similar issue. Our users cannot login to our app using two separate user accounts concurrently. (Unless you use IE6 or login as a separate user in Chrome, Firefox and IE.) Nick -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: 05 October 2010 14:40 To: Tomcat Users List Subject: RE: Tabbed browsers sharing session - work around. From: Rob Gregory [mailto:rob.greg...@ibsolutions.com] Subject: RE: Tabbed browsers sharing session - work around. I am surprised this hasn't been a problem for a lot more people. It's not a problem for most because most don't try to run live, test, and training inside a single Context on a single Host. Attempting to do so is extremely scary. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. __ The information contained in or attached to this email is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege (or other rules or laws with similar effect in jurisdictions outside England and Wales). The views expressed in this email are not necessarily the views of Centrica plc, and the company, its directors, officers or employees make no representation or accept any liability for its accuracy or completeness unless expressly stated to the contrary. __ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tabbed browsers sharing session - work around.
Hi Chris, Is there any way to dynamically create these contexts or do they require a live.xml, test.xml, etc within conf/Catalina/localhost. The multiple contexts would be my preferred approach although I would like to achieve this with a single code base if this is possible. The multiple environments are driven purely by the backend database connection, i.e. the code is the same with the only difference being where the data is being saved to. Hence the requirement to stop the browser sharing the same session when in different database connections. I'm surprised that other people are not having the same issues since the browser manufacturers decided to make this crazy change to session management between tabs/instances and suddenly share the same session. In I.E.6 two browser instances would be two separate sessions. I.E.7 they are the same session! Thanks for your input. Kind Regards, Rob. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ronald, On 10/4/2010 6:11 AM, Ronald Klop wrote: You can run your test environment on another hostname. live.example.com test.example.com train.example.com Or under another context: http://www.example.com/live http://www.example.com/test http://www.example.com/train The real question is why there's any confusion: your hostnames and/or URLs ought to be unique enough already. Otherwise, this sort of foolishness can affect your real users and you'll leak data all over the place. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyqDDQACgkQ9CaO5/Lv0PDWRACgrlgU+jY+n8nMCZ2WTO63UHDh 10UAoJdyNWqu0nlRGcWbJ6Mcc7zbsGy+ =JP4k -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tabbed browsers sharing session - work around.
Chris, See comments below:- Rob, On 10/4/2010 7:27 AM, Rob Gregory wrote: Using the hostname doesn't really guarantee a unique session for example if I click new tab and paste the URL into the new window I suspect the browser will see the same session from the first tab. Note that you haven't changed the hostname in this case: you've just cloned a browser window (or tab if you prefer to call it that). In our application the user can then change the environment with disastrous consequences when updating the database. Sounds like you need to be pretty careful. Is it possible you've built a fragile application? Some legacy parts of the application became fragile when the browsers started sharing sessions and this fix has been implemented to work around that fact. Did you implement anything to stop the session sharing at this level. What I did was to use the window.name attribute to allow tracking of browser instances and compare this when doing the session timeout checking and this way I am able to redirect any further browser opens into new sessions. That's pretty fragile: relying on client-side javascript for anything security-related is very foolish. I do not rely on javascript for security, it is used to provide a means of tracking open browser sessions. The worst a client could do would be to remove the window.name which would result in a new session being generated. With the exception of WEB-INF (which was due to tomcat no longer seeing that as a WEB-INF call because I have my unique-id in the path) do you see any security faults in what I am doing? Many: disabling javascript on the client side will break your security. An attacker overriding the javascript will break your security. The application has been security audited and after fixing a few issues is now very much secure. Disabling javascript wouldn't break the security model but we do require javascript to be enabled for correct functionality. To clarify I do not rely on javascript for anything security related and purely use this as a means of detecting the user has an existing browser window open. The window.name property is the only way to determine unique browser instances at the moment and even this is flawed if the browser is opened by a hyperlink containing a named target! I think browser manufacturers need to address this issue and provide some unique identification between browser requests. Until then I have no choice but to work-around this session sharing. Thanks again for your input, Rob - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyqDOQACgkQ9CaO5/Lv0PBbSACfVhscYMSd4q13ivnaz4k6LdeQ ZmgAoKSUg6VkjFxyFr47j1260++fjhre =ct/x -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tabbed browsers sharing session - work around.
Rob, IE 6 is even more confusing. If you open a new window with ctrl-N you have the same session sharing as with tabs. Only if you click the IE6-icon to start a new instance of the process it will not share them. Opening a new tab in IE7 is like using ctrl-n to open a new window in IE6. Ronald. Op dinsdag, 5 oktober 2010 10:26 schreef Rob Gregory rob.greg...@ibsolutions.com: Hi Chris, Is there any way to dynamically create these contexts or do they require a live.xml, test.xml, etc within conf/Catalina/localhost. The multiple contexts would be my preferred approach although I would like to achieve this with a single code base if this is possible. The multiple environments are driven purely by the backend database connection, i.e. the code is the same with the only difference being where the data is being saved to. Hence the requirement to stop the browser sharing the same session when in different database connections. I'm surprised that other people are not having the same issues since the browser manufacturers decided to make this crazy change to session management between tabs/instances and suddenly share the same session. In I.E.6 two browser instances would be two separate sessions. I.E.7 they are the same session! Thanks for your input. Kind Regards, Rob. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ronald, On 10/4/2010 6:11 AM, Ronald Klop wrote: You can run your test environment on another hostname. live.example.com test.example.com train.example.com Or under another context: http://www.example.com/live http://www.example.com/test http://www.example.com/train The real question is why there's any confusion: your hostnames and/or URLs ought to be unique enough already. Otherwise, this sort of foolishness can affect your real users and you'll leak data all over the place. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyqDDQACgkQ9CaO5/Lv0PDWRACgrlgU+jY+n8nMCZ2WTO63UHDh 10UAoJdyNWqu0nlRGcWbJ6Mcc7zbsGy+ =JP4k -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tabbed browsers sharing session - work around.
Hi Ronald, Yes I was aware of that behaviour... Just for reference Firefox and Google Chrome also share session logic so I am surprised this hasn't been a problem for a lot more people. I am happy that my work around solves the session sharing problem but would still prefer to go down the dynamic context approach if this is at all possible? I am a bit tied up with some other development at the moment but will check the tomcat source code (unless someone can advise and save me the effort) when I get a chance. Thanks very much for your assistance Ronald. Kind Regards, Rob Rob, IE 6 is even more confusing. If you open a new window with ctrl-N you have the same session sharing as with tabs. Only if you click the IE6-icon to start a new instance of the process it will not share them. Opening a new tab in IE7 is like using ctrl-n to open a new window in IE6. Ronald. Op dinsdag, 5 oktober 2010 10:26 schreef Rob Gregory rob.greg...@ibsolutions.com: Hi Chris, Is there any way to dynamically create these contexts or do they require a live.xml, test.xml, etc within conf/Catalina/localhost. The multiple contexts would be my preferred approach although I would like to achieve this with a single code base if this is possible. The multiple environments are driven purely by the backend database connection, i.e. the code is the same with the only difference being where the data is being saved to. Hence the requirement to stop the browser sharing the same session when in different database connections. I'm surprised that other people are not having the same issues since the browser manufacturers decided to make this crazy change to session management between tabs/instances and suddenly share the same session. In I.E.6 two browser instances would be two separate sessions. I.E.7 they are the same session! Thanks for your input. Kind Regards, Rob. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ronald, On 10/4/2010 6:11 AM, Ronald Klop wrote: You can run your test environment on another hostname. live.example.com test.example.com train.example.com Or under another context: http://www.example.com/live http://www.example.com/test http://www.example.com/train The real question is why there's any confusion: your hostnames and/or URLs ought to be unique enough already. Otherwise, this sort of foolishness can affect your real users and you'll leak data all over the place. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyqDDQACgkQ9CaO5/Lv0PDWRACgrlgU+jY+n8nMCZ2WTO63UHDh 10UAoJdyNWqu0nlRGcWbJ6Mcc7zbsGy+ =JP4k -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tabbed browsers sharing session - work around.
Rob, The way you describe session sharing is indeed a problem. The way we deal with this is to use a separate database table to keep track of window ids. A unique value is assigned when a window is opened and maintained until the window is closed. Although the session may be the same for all open windows (tabs), the window id is unique. Significant values are posted to the window table and retrieved based on the window id. If there is another method using a Tomcat centric approach, I would love to hear about it. Stephen On Oct 5, 2010, at 9:01 AM, Ronald Klop wrote: Rob, IE 6 is even more confusing. If you open a new window with ctrl-N you have the same session sharing as with tabs. Only if you click the IE6-icon to start a new instance of the process it will not share them. Opening a new tab in IE7 is like using ctrl-n to open a new window in IE6. Ronald. Op dinsdag, 5 oktober 2010 10:26 schreef Rob Gregory rob.greg...@ibsolutions.com: Hi Chris, Is there any way to dynamically create these contexts or do they require a live.xml, test.xml, etc within conf/Catalina/localhost. The multiple contexts would be my preferred approach although I would like to achieve this with a single code base if this is possible. The multiple environments are driven purely by the backend database connection, i.e. the code is the same with the only difference being where the data is being saved to. Hence the requirement to stop the browser sharing the same session when in different database connections. I'm surprised that other people are not having the same issues since the browser manufacturers decided to make this crazy change to session management between tabs/instances and suddenly share the same session. In I.E.6 two browser instances would be two separate sessions. I.E.7 they are the same session! Thanks for your input. Kind Regards, Rob. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ronald, On 10/4/2010 6:11 AM, Ronald Klop wrote: You can run your test environment on another hostname. live.example.com test.example.com train.example.com Or under another context: http://www.example.com/live http://www.example.com/test http://www.example.com/train The real question is why there's any confusion: your hostnames and/or URLs ought to be unique enough already. Otherwise, this sort of foolishness can affect your real users and you'll leak data all over the place. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyqDDQACgkQ9CaO5/Lv0PDWRACgrlgU+jY+n8nMCZ2WTO63UHDh 10UAoJdyNWqu0nlRGcWbJ6Mcc7zbsGy+ =JP4k -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tabbed browsers sharing session - work around.
Hi Stephen, The approach we use was described in my original post. If you need more information then I can explain further if it helps. Note, our approach does require a bespoke tomcat request class (to change the session cookie path) and this has not been without teething problems. Are you also using the window.name to store this unique id? I worry that this may not persist across browser requests in the future but see no other way to identify a browser instance? Ideally the browser vendors should identify somehow on the request a unique id but then again we would still need to support older browser so would have to fall back to the window.name attribute anyway. What fun it is being a web developer and having to deal with the quirks of different browsers and the stateless request/response cycle ;o) Regards, Rob Rob, The way you describe session sharing is indeed a problem. The way we deal with this is to use a separate database table to keep track of window ids. A unique value is assigned when a window is opened and maintained until the window is closed. Although the session may be the same for all open windows (tabs), the window id is unique. Significant values are posted to the window table and retrieved based on the window id. If there is another method using a Tomcat centric approach, I would love to hear about it. Stephen On Oct 5, 2010, at 9:01 AM, Ronald Klop wrote: Rob, IE 6 is even more confusing. If you open a new window with ctrl-N you have the same session sharing as with tabs. Only if you click the IE6-icon to start a new instance of the process it will not share them. Opening a new tab in IE7 is like using ctrl-n to open a new window in IE6. Ronald. Op dinsdag, 5 oktober 2010 10:26 schreef Rob Gregory rob.greg...@ibsolutions.com: Hi Chris, Is there any way to dynamically create these contexts or do they require a live.xml, test.xml, etc within conf/Catalina/localhost. The multiple contexts would be my preferred approach although I would like to achieve this with a single code base if this is possible. The multiple environments are driven purely by the backend database connection, i.e. the code is the same with the only difference being where the data is being saved to. Hence the requirement to stop the browser sharing the same session when in different database connections. I'm surprised that other people are not having the same issues since the browser manufacturers decided to make this crazy change to session management between tabs/instances and suddenly share the same session. In I.E.6 two browser instances would be two separate sessions. I.E.7 they are the same session! Thanks for your input. Kind Regards, Rob. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ronald, On 10/4/2010 6:11 AM, Ronald Klop wrote: You can run your test environment on another hostname. live.example.com test.example.com train.example.com Or under another context: http://www.example.com/live http://www.example.com/test http://www.example.com/train The real question is why there's any confusion: your hostnames and/or URLs ought to be unique enough already. Otherwise, this sort of foolishness can affect your real users and you'll leak data all over the place. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyqDDQACgkQ9CaO5/Lv0PDWRACgrlgU+jY+n8nMCZ2WTO63UHDh 10UAoJdyNWqu0nlRGcWbJ6Mcc7zbsGy+ =JP4k -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tabbed browsers sharing session - work around.
From: Rob Gregory [mailto:rob.greg...@ibsolutions.com] Subject: RE: Tabbed browsers sharing session - work around. I am surprised this hasn't been a problem for a lot more people. It's not a problem for most because most don't try to run live, test, and training inside a single Context on a single Host. Attempting to do so is extremely scary. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tabbed browsers sharing session - work around.
Hi Chuck, It wouldn't be live test and train, normally it's test train together with live being a separate install altogether. Unfortunately, this is a requirement I cannot avoid and was fine until the browsers changed to share sessions. I presume they have changed to support navigating the same site using multiple tabs etc. but it certainly is a pain especially as you have no idea the requests are coming from multiple sources. Regards, Rob -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: 05 October 2010 14:40 To: Tomcat Users List Subject: RE: Tabbed browsers sharing session - work around. From: Rob Gregory [mailto:rob.greg...@ibsolutions.com] Subject: RE: Tabbed browsers sharing session - work around. I am surprised this hasn't been a problem for a lot more people. It's not a problem for most because most don't try to run live, test, and training inside a single Context on a single Host. Attempting to do so is extremely scary. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tabbed browsers sharing session - work around.
Our app running on Tomcat 5.0.28 has some kind of kluge involving a flown-in vhosts.xml file in .../conf that uses aliases such that people can have separate sessions of the same app on separate tabs. I have no idea if this is how this should have been done back in the olden days but more importantly I'd like to understand the industrially correct way to obtain this behavior under 6.0.* Tomcat...if it's not already the default. - Jeff On 10/5/10 9:16 AM, Stephen Caine wrote: Rob, The way you describe session sharing is indeed a problem. The way we deal with this is to use a separate database table to keep track of window ids. A unique value is assigned when a window is opened and maintained until the window is closed. Although the session may be the same for all open windows (tabs), the window id is unique. Significant values are posted to the window table and retrieved based on the window id. If there is another method using a Tomcat centric approach, I would love to hear about it. Stephen On Oct 5, 2010, at 9:01 AM, Ronald Klop wrote: Rob, IE 6 is even more confusing. If you open a new window with ctrl-N you have the same session sharing as with tabs. Only if you click the IE6-icon to start a new instance of the process it will not share them. Opening a new tab in IE7 is like using ctrl-n to open a new window in IE6. Ronald. Op dinsdag, 5 oktober 2010 10:26 schreef Rob Gregoryrob.greg...@ibsolutions.com: Hi Chris, Is there any way to dynamically create these contexts or do they require a live.xml, test.xml, etc within conf/Catalina/localhost. The multiple contexts would be my preferred approach although I would like to achieve this with a single code base if this is possible. The multiple environments are driven purely by the backend database connection, i.e. the code is the same with the only difference being where the data is being saved to. Hence the requirement to stop the browser sharing the same session when in different database connections. I'm surprised that other people are not having the same issues since the browser manufacturers decided to make this crazy change to session management between tabs/instances and suddenly share the same session. In I.E.6 two browser instances would be two separate sessions. I.E.7 they are the same session! Thanks for your input. Kind Regards, Rob. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ronald, On 10/4/2010 6:11 AM, Ronald Klop wrote: You can run your test environment on another hostname. live.example.com test.example.com train.example.com Or under another context: http://www.example.com/live http://www.example.com/test http://www.example.com/train The real question is why there's any confusion: your hostnames and/or URLs ought to be unique enough already. Otherwise, this sort of foolishness can affect your real users and you'll leak data all over the place. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyqDDQACgkQ9CaO5/Lv0PDWRACgrlgU+jY+n8nMCZ2WTO63UHDh 10UAoJdyNWqu0nlRGcWbJ6Mcc7zbsGy+ =JP4k -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tabbed browsers sharing session - work around.
I agree, this is a very scary app to support. At a minimum, multiple contexts, each with its own database resource definition would avoid a lot of the OP's problems, wouldn't it? I'm not a developer, but from an SA standpoint, this gives me the willys. Q: Can the cookie be tied to hostname/context? -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Tuesday, October 05, 2010 8:40 AM To: Tomcat Users List Subject: RE: Tabbed browsers sharing session - work around. From: Rob Gregory [mailto:rob.greg...@ibsolutions.com] Subject: RE: Tabbed browsers sharing session - work around. I am surprised this hasn't been a problem for a lot more people. It's not a problem for most because most don't try to run live, test, and training inside a single Context on a single Host. Attempting to do so is extremely scary. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org __ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tabbed browsers sharing session - work around.
Hi Jeffrey, Yes, the cookie can and is tied to the context. I just take this another level and tied it against a virtual context so as far as the browser is concerned they are different sites and as such, different sessions. Regards, Rob. -Original Message- From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] Sent: 05 October 2010 15:26 To: Tomcat Users List Subject: RE: Tabbed browsers sharing session - work around. I agree, this is a very scary app to support. At a minimum, multiple contexts, each with its own database resource definition would avoid a lot of the OP's problems, wouldn't it? I'm not a developer, but from an SA standpoint, this gives me the willys. Q: Can the cookie be tied to hostname/context? -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Tuesday, October 05, 2010 8:40 AM To: Tomcat Users List Subject: RE: Tabbed browsers sharing session - work around. From: Rob Gregory [mailto:rob.greg...@ibsolutions.com] Subject: RE: Tabbed browsers sharing session - work around. I am surprised this hasn't been a problem for a lot more people. It's not a problem for most because most don't try to run live, test, and training inside a single Context on a single Host. Attempting to do so is extremely scary. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org __ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tabbed browsers sharing session - work around.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rob, On 10/5/2010 5:03 AM, Rob Gregory wrote: Sounds like you need to be pretty careful. Is it possible you've built a fragile application? Some legacy parts of the application became fragile when the browsers started sharing sessions and this fix has been implemented to work around that fact. I'm not sure anything changed recently with web browsers: cookies have always worked this way, tabs or not. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyrOnIACgkQ9CaO5/Lv0PAjZACfVpeZ5GcmtKXgt/UmmO34Xw4R 1OwAoIRt03dpZFoBbuRnyzvzGgsxS5jB =JiSB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tabbed browsers sharing session - work around.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rob, On 10/5/2010 4:26 AM, Rob Gregory wrote: Is there any way to dynamically create these contexts or do they require a live.xml, test.xml, etc within conf/Catalina/localhost. You can use JMX or the manager to deploy an application under any context name. I haven't tried myself, but I would imagine that you can also provide a context.xml to ensure that you get the database configuration that you need. I'm surprised that other people are not having the same issues since the browser manufacturers decided to make this crazy change to session management between tabs/instances and suddenly share the same session. I'm still puzzled as to what you think changed in the web browser world. In I.E.6 two browser instances would be two separate sessions. I.E.7 they are the same session! Hm. Are you talking about multi-process MSIE versus single-process MSIE? It's dangerous to rely on the user launching separate browser processes to use your application(s) if the possibility exists that significant confusion can arise. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyrO2YACgkQ9CaO5/Lv0PBROwCbBbdHwit1FxnShkXNLZ3wDVQA sZgAn3+yal50iSIIVeMZ9bY8EKRejLT2 =5SOW -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tabbed browsers sharing session - work around.
Hi Chris, In Internet Explorer 5.5,6.0 if you opened up two separate browser instances they would have two 'un-connected' sessions. As stated by Ronald they would share the session if the 2nd was opened using ctrl-n but otherwise the sessions would be unique. Cookies may have always worked as they do now but the browser would store them within each instance. They seem to have changed to now share the sessions/cookies and this was introduced at the same time as tabbed browsers IE7+. Regards, Rob -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rob, On 10/5/2010 5:03 AM, Rob Gregory wrote: Sounds like you need to be pretty careful. Is it possible you've built a fragile application? Some legacy parts of the application became fragile when the browsers started sharing sessions and this fix has been implemented to work around that fact. I'm not sure anything changed recently with web browsers: cookies have always worked this way, tabs or not. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyrOnIACgkQ9CaO5/Lv0PAjZACfVpeZ5GcmtKXgt/UmmO34Xw4R 1OwAoIRt03dpZFoBbuRnyzvzGgsxS5jB =JiSB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tabbed browsers sharing session - work around.
This application (or mess of applications munged together) is a big mistake, the source of all your problems and should be the only thing that you address. That's why nobody else has this problem. This problem is a sign of serious misconceptions in design and development. And if you really must not fix the real problem why in the world did you hack away at tomcat? Why not filters? You can do a lot with filters that would be much preferable to what you have done including the fact that it would just run without having to modify the servlet container. -Original Message- From: Rob Gregory [mailto:rob.greg...@ibsolutions.com] Sent: Tuesday, October 05, 2010 10:51 AM To: Tomcat Users List Subject: RE: Tabbed browsers sharing session - work around. Hi Chris, In Internet Explorer 5.5,6.0 if you opened up two separate browser instances they would have two 'un-connected' sessions. As stated by Ronald they would share the session if the 2nd was opened using ctrl-n but otherwise the sessions would be unique. Cookies may have always worked as they do now but the browser would store them within each instance. They seem to have changed to now share the sessions/cookies and this was introduced at the same time as tabbed browsers IE7+. Regards, Rob -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rob, On 10/5/2010 5:03 AM, Rob Gregory wrote: Sounds like you need to be pretty careful. Is it possible you've built a fragile application? Some legacy parts of the application became fragile when the browsers started sharing sessions and this fix has been implemented to work around that fact. I'm not sure anything changed recently with web browsers: cookies have always worked this way, tabs or not. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyrOnIACgkQ9CaO5/Lv0PAjZACfVpeZ5GcmtKXgt/UmmO34Xw4R 1OwAoIRt03dpZFoBbuRnyzvzGgsxS5jB =JiSB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tabbed browsers sharing session - work around.
Hi Maximilian, Basically we are stuck with some legacy application parts that while these are scheduled to be replaced we have to support them until they have been. Using filters would not solve the issue as the 'Hack' as you put it is done at a cookie path level. We do use filters to implement security, ntlmv2 authentication, caching anti-caching, etc so I am fully aware of the power of filters. I agree hacking away at a part of Tomcat is not the best solution but it was the only one currently available to resolve the issue. And was my original reasoning behind posting to this group to see if anyone could suggest a better solution. Thanks for your input. Rob -Original Message- From: Maximilian Stocker [mailto:m...@talentoyster.com] Sent: 05 October 2010 16:03 To: 'Tomcat Users List' Subject: RE: Tabbed browsers sharing session - work around. This application (or mess of applications munged together) is a big mistake, the source of all your problems and should be the only thing that you address. That's why nobody else has this problem. This problem is a sign of serious misconceptions in design and development. And if you really must not fix the real problem why in the world did you hack away at tomcat? Why not filters? You can do a lot with filters that would be much preferable to what you have done including the fact that it would just run without having to modify the servlet container. -Original Message- From: Rob Gregory [mailto:rob.greg...@ibsolutions.com] Sent: Tuesday, October 05, 2010 10:51 AM To: Tomcat Users List Subject: RE: Tabbed browsers sharing session - work around. Hi Chris, In Internet Explorer 5.5,6.0 if you opened up two separate browser instances they would have two 'un-connected' sessions. As stated by Ronald they would share the session if the 2nd was opened using ctrl-n but otherwise the sessions would be unique. Cookies may have always worked as they do now but the browser would store them within each instance. They seem to have changed to now share the sessions/cookies and this was introduced at the same time as tabbed browsers IE7+. Regards, Rob -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rob, On 10/5/2010 5:03 AM, Rob Gregory wrote: Sounds like you need to be pretty careful. Is it possible you've built a fragile application? Some legacy parts of the application became fragile when the browsers started sharing sessions and this fix has been implemented to work around that fact. I'm not sure anything changed recently with web browsers: cookies have always worked this way, tabs or not. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyrOnIACgkQ9CaO5/Lv0PAjZACfVpeZ5GcmtKXgt/UmmO34Xw4R 1OwAoIRt03dpZFoBbuRnyzvzGgsxS5jB =JiSB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tabbed browsers sharing session - work around.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rob, On 10/5/2010 11:28 AM, Rob Gregory wrote: Basically we are stuck with some legacy application parts that while these are scheduled to be replaced we have to support them until they have been. Using filters would not solve the issue as the 'Hack' as you put it is done at a cookie path level. We do use filters to implement security, ntlmv2 authentication, caching anti-caching, etc so I am fully aware of the power of filters. I agree hacking away at a part of Tomcat is not the best solution but it was the only one currently available to resolve the issue. And was my original reasoning behind posting to this group to see if anyone could suggest a better solution. My suggestion would be to deploy your different environments into separate contexts. That way, the cookie paths are distinguishable and there shouldn't be any confusion no matter what the situation is on the client. One other possibility would be to disable the use of cookies altogether on the server and force the use or URL rewriting: that would essentially force each browser window or tab into it's own isolated session. This requires that you have coded your pages correctly to support URL rewriting, of course. Good luck, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyrbSgACgkQ9CaO5/Lv0PDI9ACgm2WTdL6vIRqBSvX78Z9XMDEw EpcAnA6sQFf1kmBlj07/Xk4bL+4BpeHN =MR4n -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tabbed browsers sharing session - work around.
Hi Ronald, Thanks for the prompt response but I am not sure I fully understand your suggestion. Would that approach require knowing the available environments before hand and registering these somehow so that the names get resolved to the machine. If so this is not really an option as our application dynamically creates these environments. The application is not internet facing if that makes a difference. Regards Rob -Original Message- From: Ronald Klop [mailto:ronald-mailingl...@base.nl] Sent: 04 October 2010 11:12 To: Tomcat Users List Subject: Re: Tabbed browsers sharing session - work around. You can run your test environment on another hostname. live.example.com test.example.com train.example.com Maybe use a login.example.com to redirect you to the right url after login. Ronald. Op maandag, 4 oktober 2010 11:03 schreef Rob Gregory rob.greg...@ibsolutions.com: Hi Tomcat community, I'm after advice on some session frigging I have recently bespoke'd into Tomcat (version 6.0.29) to resolve an issue with the recent changes in tabbed browsers where they now share the same session across multiple browser tabs/instances. I have googled the issue and the following post seems to be asking the same question, and suggestions come very close to what I have implemented:- http://old.nabble.com/Want-to-customise-the-tomcat's-session-logic-td261 61430.html The problem:- I have a web application that supports multiple environments (database) such as live, test, train, etc. from a single code base/web application. Example scenario is as follows:- * User Bob logs into the application and selects the TEST environment and starts entering some data. * Bob then opens up another browser or tab and logs into the LIVE environment. * Behind the scenes the browser has shared the session and has in fact switched the first browser from TEST into the LIVE environment without Bob being aware. * Bob hits save within what he thinks is the TEST environment and the LIVE environment is actually updated. The solution:- I have introduced what is basically a sub context into our url's and changed the path of the jsession cookie to limit each generated session to the 'virtual' context it was issued within. E.g. cookie.setPath(contextPath + / + unique-id); where unique-id is just a unique generated number. The Implementation:- I have bespoked the org.apache.catalina.connector.Request class to include a unique id as the context to the cookie path and prior to creating the session I redirect the user to this context e.g. http://localhost/webapp/unique-id/page.jsp. The unique-id is then removed by the Request class before returning the path from getServletPath() and getRequestURI() so the actual web application is unaware of this context switching. The Question:- While this seems to be working well and the multiple browser tabs/instances do indeed have unique sessions I would like to ask if anyone can see any potential issues with what I have done or how I have implemented it. I did have one serious issue where I could type in http://localhost/webapp/unique-id/WEB-INF/lib/application.jar and it bypassed Tomcat built in security and actually downloaded the .jar but this was quickly resolved. Any input or criticisms would be greatly appreciated if you can see a flaw in this design or know of a better approach to bypass this shared session behaviour of recent browsers. Many thanks for your time. Rob Gregory - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tabbed browsers sharing session - work around.
Hi Ronald, Using the hostname doesn't really guarantee a unique session for example if I click new tab and paste the URL into the new window I suspect the browser will see the same session from the first tab. In our application the user can then change the environment with disastrous consequences when updating the database. Did you implement anything to stop the session sharing at this level. What I did was to use the window.name attribute to allow tracking of browser instances and compare this when doing the session timeout checking and this way I am able to redirect any further browser opens into new sessions. With the exception of WEB-INF (which was due to tomcat no longer seeing that as a WEB-INF call because I have my unique-id in the path) do you see any security faults in what I am doing? Again thanks for the suggestion and I will look into maybe using the host over a virtual context as part of the final solution. Kind Regards, Rob -Original Message- From: Ronald Klop [mailto:ronald-mailingl...@base.nl] Sent: 04 October 2010 12:15 To: Tomcat Users List Subject: RE: Tabbed browsers sharing session - work around. Hi, Ok. I didn't understand that somebody chooses an environment dynamicly. The JSESSION cookie is tight to a hostname. So if you make unique hostnames for every login you have unique sessions. For our helpdesk I made a wildcard DNS entry *.example.com IN CNAME tomcat.example.com and a button which redirects you to timestamp.example.com, so a login goes to something like 1286190607.example.com and the next user will go to 1286190608.example.com and has its own session. It is about the same as you do with your virtual context, but you don't have to do tricks to org.apache.catalina.connector.Request and it keeps all the safety of WEB-INF, etc. Ronald. Op maandag, 4 oktober 2010 12:58 schreef Rob Gregory rob.greg...@ibsolutions.com: Hi Ronald, Thanks for the prompt response but I am not sure I fully understand your suggestion. Would that approach require knowing the available environments before hand and registering these somehow so that the names get resolved to the machine. If so this is not really an option as our application dynamically creates these environments. The application is not internet facing if that makes a difference. Regards Rob -Original Message- From: Ronald Klop [mailto:ronald-mailingl...@base.nl] Sent: 04 October 2010 11:12 To: Tomcat Users List Subject: Re: Tabbed browsers sharing session - work around. You can run your test environment on another hostname. live.example.com test.example.com train.example.com Maybe use a login.example.com to redirect you to the right url after login. Ronald. Op maandag, 4 oktober 2010 11:03 schreef Rob Gregory rob.greg...@ibsolutions.com: Hi Tomcat community, I'm after advice on some session frigging I have recently bespoke'd into Tomcat (version 6.0.29) to resolve an issue with the recent changes in tabbed browsers where they now share the same session across multiple browser tabs/instances. I have googled the issue and the following post seems to be asking the same question, and suggestions come very close to what I have implemented:- http://old.nabble.com/Want-to-customise-the-tomcat's-session-logic-td261 61430.html The problem:- I have a web application that supports multiple environments (database) such as live, test, train, etc. from a single code base/web application. Example scenario is as follows:- * User Bob logs into the application and selects the TEST environment and starts entering some data. * Bob then opens up another browser or tab and logs into the LIVE environment. * Behind the scenes the browser has shared the session and has in fact switched the first browser from TEST into the LIVE environment without Bob being aware. * Bob hits save within what he thinks is the TEST environment and the LIVE environment is actually updated. The solution:- I have introduced what is basically a sub context into our url's and changed the path of the jsession cookie to limit each generated session to the 'virtual' context it was issued within. E.g. cookie.setPath(contextPath + / + unique-id); where unique-id is just a unique generated number. The Implementation:- I have bespoked the org.apache.catalina.connector.Request class to include a unique id as the context to the cookie path and prior to creating the session I redirect the user to this context e.g. http://localhost/webapp/unique-id/page.jsp. The unique-id is then removed by the Request class before returning the path from getServletPath() and getRequestURI() so the actual web application is unaware of this context switching. The Question:- While this seems
Tabbed browsers sharing session - work around.
Hi Tomcat community, I'm after advice on some session frigging I have recently bespoke'd into Tomcat (version 6.0.29) to resolve an issue with the recent changes in tabbed browsers where they now share the same session across multiple browser tabs/instances. I have googled the issue and the following post seems to be asking the same question, and suggestions come very close to what I have implemented:- http://old.nabble.com/Want-to-customise-the-tomcat's-session-logic-td261 61430.html The problem:- I have a web application that supports multiple environments (database) such as live, test, train, etc. from a single code base/web application. Example scenario is as follows:- * User Bob logs into the application and selects the TEST environment and starts entering some data. * Bob then opens up another browser or tab and logs into the LIVE environment. * Behind the scenes the browser has shared the session and has in fact switched the first browser from TEST into the LIVE environment without Bob being aware. * Bob hits save within what he thinks is the TEST environment and the LIVE environment is actually updated. The solution:- I have introduced what is basically a sub context into our url's and changed the path of the jsession cookie to limit each generated session to the 'virtual' context it was issued within. E.g. cookie.setPath(contextPath + / + unique-id); where unique-id is just a unique generated number. The Implementation:- I have bespoked the org.apache.catalina.connector.Request class to include a unique id as the context to the cookie path and prior to creating the session I redirect the user to this context e.g. http://localhost/webapp/unique-id/page.jsp. The unique-id is then removed by the Request class before returning the path from getServletPath() and getRequestURI() so the actual web application is unaware of this context switching. The Question:- While this seems to be working well and the multiple browser tabs/instances do indeed have unique sessions I would like to ask if anyone can see any potential issues with what I have done or how I have implemented it. I did have one serious issue where I could type in http://localhost/webapp/unique-id/WEB-INF/lib/application.jar and it bypassed Tomcat built in security and actually downloaded the .jar but this was quickly resolved. Any input or criticisms would be greatly appreciated if you can see a flaw in this design or know of a better approach to bypass this shared session behaviour of recent browsers. Many thanks for your time. Rob Gregory
RE: Tabbed browsers sharing session - work around.
Hi, Ok. I didn't understand that somebody chooses an environment dynamicly. The JSESSION cookie is tight to a hostname. So if you make unique hostnames for every login you have unique sessions. For our helpdesk I made a wildcard DNS entry *.example.com IN CNAME tomcat.example.com and a button which redirects you to timestamp.example.com, so a login goes to something like 1286190607.example.com and the next user will go to 1286190608.example.com and has its own session. It is about the same as you do with your virtual context, but you don't have to do tricks to org.apache.catalina.connector.Request and it keeps all the safety of WEB-INF, etc. Ronald. Op maandag, 4 oktober 2010 12:58 schreef Rob Gregory rob.greg...@ibsolutions.com: Hi Ronald, Thanks for the prompt response but I am not sure I fully understand your suggestion. Would that approach require knowing the available environments before hand and registering these somehow so that the names get resolved to the machine. If so this is not really an option as our application dynamically creates these environments. The application is not internet facing if that makes a difference. Regards Rob -Original Message- From: Ronald Klop [mailto:ronald-mailingl...@base.nl] Sent: 04 October 2010 11:12 To: Tomcat Users List Subject: Re: Tabbed browsers sharing session - work around. You can run your test environment on another hostname. live.example.com test.example.com train.example.com Maybe use a login.example.com to redirect you to the right url after login. Ronald. Op maandag, 4 oktober 2010 11:03 schreef Rob Gregory rob.greg...@ibsolutions.com: Hi Tomcat community, I'm after advice on some session frigging I have recently bespoke'd into Tomcat (version 6.0.29) to resolve an issue with the recent changes in tabbed browsers where they now share the same session across multiple browser tabs/instances. I have googled the issue and the following post seems to be asking the same question, and suggestions come very close to what I have implemented:- http://old.nabble.com/Want-to-customise-the-tomcat's-session-logic-td261 61430.html The problem:- I have a web application that supports multiple environments (database) such as live, test, train, etc. from a single code base/web application. Example scenario is as follows:- * User Bob logs into the application and selects the TEST environment and starts entering some data. * Bob then opens up another browser or tab and logs into the LIVE environment. * Behind the scenes the browser has shared the session and has in fact switched the first browser from TEST into the LIVE environment without Bob being aware. * Bob hits save within what he thinks is the TEST environment and the LIVE environment is actually updated. The solution:- I have introduced what is basically a sub context into our url's and changed the path of the jsession cookie to limit each generated session to the 'virtual' context it was issued within. E.g. cookie.setPath(contextPath + / + unique-id); where unique-id is just a unique generated number. The Implementation:- I have bespoked the org.apache.catalina.connector.Request class to include a unique id as the context to the cookie path and prior to creating the session I redirect the user to this context e.g. http://localhost/webapp/unique-id/page.jsp. The unique-id is then removed by the Request class before returning the path from getServletPath() and getRequestURI() so the actual web application is unaware of this context switching. The Question:- While this seems to be working well and the multiple browser tabs/instances do indeed have unique sessions I would like to ask if anyone can see any potential issues with what I have done or how I have implemented it. I did have one serious issue where I could type in http://localhost/webapp/unique-id/WEB-INF/lib/application.jar and it bypassed Tomcat built in security and actually downloaded the .jar but this was quickly resolved. Any input or criticisms would be greatly appreciated if you can see a flaw in this design or know of a better approach to bypass this shared session behaviour of recent browsers. Many thanks for your time. Rob Gregory - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tabbed browsers sharing session - work around.
You can run your test environment on another hostname. live.example.com test.example.com train.example.com Maybe use a login.example.com to redirect you to the right url after login. Ronald. Op maandag, 4 oktober 2010 11:03 schreef Rob Gregory rob.greg...@ibsolutions.com: Hi Tomcat community, I'm after advice on some session frigging I have recently bespoke'd into Tomcat (version 6.0.29) to resolve an issue with the recent changes in tabbed browsers where they now share the same session across multiple browser tabs/instances. I have googled the issue and the following post seems to be asking the same question, and suggestions come very close to what I have implemented:- http://old.nabble.com/Want-to-customise-the-tomcat's-session-logic-td261 61430.html The problem:- I have a web application that supports multiple environments (database) such as live, test, train, etc. from a single code base/web application. Example scenario is as follows:- * User Bob logs into the application and selects the TEST environment and starts entering some data. * Bob then opens up another browser or tab and logs into the LIVE environment. * Behind the scenes the browser has shared the session and has in fact switched the first browser from TEST into the LIVE environment without Bob being aware. * Bob hits save within what he thinks is the TEST environment and the LIVE environment is actually updated. The solution:- I have introduced what is basically a sub context into our url's and changed the path of the jsession cookie to limit each generated session to the 'virtual' context it was issued within. E.g. cookie.setPath(contextPath + / + unique-id); where unique-id is just a unique generated number. The Implementation:- I have bespoked the org.apache.catalina.connector.Request class to include a unique id as the context to the cookie path and prior to creating the session I redirect the user to this context e.g. http://localhost/webapp/unique-id/page.jsp. The unique-id is then removed by the Request class before returning the path from getServletPath() and getRequestURI() so the actual web application is unaware of this context switching. The Question:- While this seems to be working well and the multiple browser tabs/instances do indeed have unique sessions I would like to ask if anyone can see any potential issues with what I have done or how I have implemented it. I did have one serious issue where I could type in http://localhost/webapp/unique-id/WEB-INF/lib/application.jar and it bypassed Tomcat built in security and actually downloaded the .jar but this was quickly resolved. Any input or criticisms would be greatly appreciated if you can see a flaw in this design or know of a better approach to bypass this shared session behaviour of recent browsers. Many thanks for your time. Rob Gregory
RE: Tabbed browsers sharing session - work around.
if (session.environment != newEnvironment) {
logoutUser(You cannot change a running environment.);
}
Something like that.
Ronald.
Op maandag, 4 oktober 2010 13:27 schreef Rob Gregory
rob.greg...@ibsolutions.com:
Hi Ronald,
Using the hostname doesn't really guarantee a unique session for example
if I click new tab and paste the URL into the new window I suspect the
browser will see the same session from the first tab. In our application
the user can then change the environment with disastrous consequences
when updating the database. Did you implement anything to stop the
session sharing at this level. What I did was to use the window.name
attribute to allow tracking of browser instances and compare this when
doing the session timeout checking and this way I am able to redirect
any further browser opens into new sessions.
With the exception of WEB-INF (which was due to tomcat no longer seeing
that as a WEB-INF call because I have my unique-id in the path) do you
see any security faults in what I am doing?
Again thanks for the suggestion and I will look into maybe using the
host over a virtual context as part of the final solution.
Kind Regards,
Rob
-Original Message-
From: Ronald Klop [mailto:ronald-mailingl...@base.nl]
Sent: 04 October 2010 12:15
To: Tomcat Users List
Subject: RE: Tabbed browsers sharing session - work around.
Hi,
Ok. I didn't understand that somebody chooses an environment dynamicly.
The JSESSION cookie is tight to a hostname. So if you make unique
hostnames for every login you have unique sessions.
For our helpdesk I made a wildcard DNS entry *.example.com IN CNAME
tomcat.example.com and a button which redirects you to
timestamp.example.com, so a login goes to something like
1286190607.example.com and the next user will go to
1286190608.example.com and has its own session.
It is about the same as you do with your virtual context, but you don't
have to do tricks to org.apache.catalina.connector.Request and it keeps
all the safety of WEB-INF, etc.
Ronald.
Op maandag, 4 oktober 2010 12:58 schreef Rob Gregory
rob.greg...@ibsolutions.com:
Hi Ronald,
Thanks for the prompt response but I am not sure I fully understand
your
suggestion. Would that approach require knowing the available
environments before hand and registering these somehow so that the
names
get resolved to the machine. If so this is not really an option as our
application dynamically creates these environments. The application is
not internet facing if that makes a difference.
Regards
Rob
-Original Message-
From: Ronald Klop [mailto:ronald-mailingl...@base.nl]
Sent: 04 October 2010 11:12
To: Tomcat Users List
Subject: Re: Tabbed browsers sharing session - work around.
You can run your test environment on another hostname.
live.example.com
test.example.com
train.example.com
Maybe use a login.example.com to redirect you to the right url after
login.
Ronald.
Op maandag, 4 oktober 2010 11:03 schreef Rob Gregory
rob.greg...@ibsolutions.com:
Hi Tomcat community,
I'm after advice on some session frigging I have recently bespoke'd
into
Tomcat (version 6.0.29) to resolve an issue with the recent changes
in
tabbed browsers where they now share the same session across
multiple
browser tabs/instances.
I have googled the issue and the following post seems to be asking
the
same question, and suggestions come very close to what I have
implemented:-
http://old.nabble.com/Want-to-customise-the-tomcat's-session-logic-td261
61430.html
The problem:-
I have a web application that supports multiple environments
(database)
such as live, test, train, etc. from a single code base/web
application.
Example scenario is as follows:-
* User Bob logs into the application and selects the
TEST
environment and starts entering some data.
* Bob then opens up another browser or tab and logs into
the
LIVE environment.
* Behind the scenes the browser has shared the session
and
has in fact switched the first browser from TEST into the LIVE
environment without Bob being aware.
* Bob hits save within what he thinks is the TEST
environment and the LIVE environment is actually updated.
The solution:-
I have introduced what is basically a sub context into our url's and
changed the path of the jsession cookie to limit each generated
session
to the 'virtual' context it was issued within. E.g.
cookie.setPath(contextPath + / + unique-id); where unique-id
is
just a unique generated number.
The Implementation:-
I have bespoked the org.apache.catalina.connector.Request class to
include a unique id as the context to the cookie path and prior to
creating the session I redirect the user to this context e.g.
http://localhost/webapp/unique-id/page.jsp
Re: Tabbed browsers sharing session - work around.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ronald, On 10/4/2010 6:11 AM, Ronald Klop wrote: You can run your test environment on another hostname. live.example.com test.example.com train.example.com Or under another context: http://www.example.com/live http://www.example.com/test http://www.example.com/train The real question is why there's any confusion: your hostnames and/or URLs ought to be unique enough already. Otherwise, this sort of foolishness can affect your real users and you'll leak data all over the place. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyqDDQACgkQ9CaO5/Lv0PDWRACgrlgU+jY+n8nMCZ2WTO63UHDh 10UAoJdyNWqu0nlRGcWbJ6Mcc7zbsGy+ =JP4k -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tabbed browsers sharing session - work around.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rob, On 10/4/2010 7:27 AM, Rob Gregory wrote: Using the hostname doesn't really guarantee a unique session for example if I click new tab and paste the URL into the new window I suspect the browser will see the same session from the first tab. Note that you haven't changed the hostname in this case: you've just cloned a browser window (or tab if you prefer to call it that). In our application the user can then change the environment with disastrous consequences when updating the database. Sounds like you need to be pretty careful. Is it possible you've built a fragile application? Did you implement anything to stop the session sharing at this level. What I did was to use the window.name attribute to allow tracking of browser instances and compare this when doing the session timeout checking and this way I am able to redirect any further browser opens into new sessions. That's pretty fragile: relying on client-side javascript for anything security-related is very foolish. With the exception of WEB-INF (which was due to tomcat no longer seeing that as a WEB-INF call because I have my unique-id in the path) do you see any security faults in what I am doing? Many: disabling javascript on the client side will break your security. An attacker overriding the javascript will break your security. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyqDOQACgkQ9CaO5/Lv0PBbSACfVhscYMSd4q13ivnaz4k6LdeQ ZmgAoKSUg6VkjFxyFr47j1260++fjhre =ct/x -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
