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 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
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
