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
