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
