tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Gregory" <Rob.Greg...@ibsolutions.com>
Subject RE: Tabbed browsers sharing session - work around.
Date Tue, 05 Oct 2010 13:25:34 GMT
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.Gregory@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-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message