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
