You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Leon Rosenberg <ro...@gmail.com> on 2011/11/16 23:06:08 UTC
tomcat session replication and domain change
Hello,
I'm researching possible solutions for a following scenario and am not
sure whether tomcat session replication can support it:
My site is normally available under www.site.com, www.site.fr,
www.site.de etc, for 22 different countries and a total of 500 domains
(partners). Usually a user stays on the site he came in to (like
www.site.com), except for one important case: all payments are handled
by secure.site.com. So my example looks like following:
User logins on http://www.site.fr, a new session is created.
User uses the site, attributes are written and read...
User clicks a special link and is redirected to https://secure.site.com
- secure.site.com (same webapp, different servers) loads the session
previously initialized on www.site.fr and associates it locally.
User uses secure.site.com, modifies attributes etc.
After user is finished he jumps (on click or by simply entering the
url) back to www.site.fr, the local session contains all the changes
from secure.site.com.
>From the documentation of tomcat 7 I read:
Note: Remember that your session state is tracked by a cookie, so your
URL must look the same from the out side otherwise, a new session will
be created.
So I understand that my scenario doesn't work outofthebox, or does it?
If not, any other scenarios how to solve this use case?
thanx in advance
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: tomcat session replication and domain change
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leon,
On 11/16/11 5:32 PM, Leon Rosenberg wrote:
> Hello Chris,
>
> thank you for the answer, more inline.
>
>>> User logins on http://www.site.fr, a new session is created.
>>> User uses the site, attributes are written and read... User
>>> clicks a special link and is redirected to
>>> https://secure.site.com - secure.site.com (same webapp,
>>> different servers) loads the session previously initialized on
>>> www.site.fr and associates it locally.
>>
>> How does this work? Or, were you asking if Tomcat can make this
>> work (easily) for you?
>
> Yes. I know/can think about other solutions where the session id
> of the original session is transmitted via additional parameter and
> is used for session copy, like: server A issues session AAA. link
> to server B contains sessionIdParameter=AAA a vavle or something on
> server B notices that there is no local session for user on server
> B yet and copies the AAA session.
>
> The question was, does tomcat support this already, or would I have
> to code something myself. URL rewriting is not an option for
> several reasons.
You'll have to roll your own, here.
If you don't mind passing-around a meta-session-id, you could use
something like memcached as a unified session that everyone can see.
>> Unfortunately, you may have a shitstorm of session chatter.
>> Presumably, you'll have a number of domain-specific servers and
>> a single secure one (or clustering all around, which actually
>> makes the chatter problem worse). That means that if you have 100
>> sessions on each of 10 CCTLD servers then you'll have 10000
>> sessions on the secure server. If that's okay, then go for it.
>
> Either you miscalculated it or I don't get the relation, 10x100 =
> 1000, not 10.000 ;-)
Too much coffee makes my fingers twitchy. 100 sessions per server is
nothin', too.
> But the point is valid, after the user leaves secure.site.com he
> will probably never come back and there is no need to keep his
> session (noone pays twice ;-)).
You obviously need to change your business model. :)
> But I assume tomcat session replication support doesn't support
> session purge, neither session pull instead of permanent
> synchronization.
I don't think you can tell another node to purge a session without
purging it from the entire cluster. Someone with more cluster
experience than I can probably comment on that, but it's a safe bet :)
With something like memcached, the "session" exists in the service and
not in the server so it's not like you're wasting memory waiting for
the session to die on the payment server.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7FccEACgkQ9CaO5/Lv0PCkFQCfdq3nr85ZoMWryYzoGt2FuTuS
6UYAn27fnaH6+jQ79N1DD3auGwnWzcNr
=iZQ4
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: tomcat session replication and domain change
Posted by Leon Rosenberg <ro...@gmail.com>.
Hello Chris,
thank you for the answer, more inline.
>> User logins on http://www.site.fr, a new session is created. User
>> uses the site, attributes are written and read... User clicks a
>> special link and is redirected to https://secure.site.com -
>> secure.site.com (same webapp, different servers) loads the session
>> previously initialized on www.site.fr and associates it locally.
>
> How does this work? Or, were you asking if Tomcat can make this work
> (easily) for you?
Yes. I know/can think about other solutions where the session id of
the original session is transmitted via additional parameter and is
used for session copy, like:
server A issues session AAA.
link to server B contains sessionIdParameter=AAA
a vavle or something on server B notices that there is no local
session for user on server B yet and copies the AAA session.
The question was, does tomcat support this already, or would I have to
code something myself.
URL rewriting is not an option for several reasons.
...
> Unfortunately, you may have a shitstorm of session chatter.
> Presumably, you'll have a number of domain-specific servers and a
> single secure one (or clustering all around, which actually makes the
> chatter problem worse). That means that if you have 100 sessions on
> each of 10 CCTLD servers then you'll have 10000 sessions on the secure
> server. If that's okay, then go for it.
Either you miscalculated it or I don't get the relation, 10x100 =
1000, not 10.000 ;-)
But the point is valid, after the user leaves secure.site.com he will
probably never come back and there is no need to keep his session
(noone pays twice ;-)).
But I assume tomcat session replication support doesn't support
session purge, neither session pull instead of permanent
synchronization.
regards
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: tomcat session replication and domain change
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leon,
On 11/16/11 5:06 PM, Leon Rosenberg wrote:
> User logins on http://www.site.fr, a new session is created. User
> uses the site, attributes are written and read... User clicks a
> special link and is redirected to https://secure.site.com -
> secure.site.com (same webapp, different servers) loads the session
> previously initialized on www.site.fr and associates it locally.
How does this work? Or, were you asking if Tomcat can make this work
(easily) for you?
> User uses secure.site.com, modifies attributes etc. After user is
> finished he jumps (on click or by simply entering the url) back to
> www.site.fr, the local session contains all the changes from
> secure.site.com.
If you are using cookies to track your session, then this will not
work because the browser isn't going to send the session id when the
domain changes. If you could always be on *.site.fr (like from
www.site.fr to secure.site.fr) then it would work if you set your
cookie domain to site.fr. But that is a per-context setting which
means you'd need a separate context for each domain you wanted to
support. Yuck.
If you use URL rewriting for session tracking, then this might work:
cluster all the sites together and make sure that the jsessionid
parameter is added to any URL you create that crosses the domain
border. All copies of the webapp should replicate session info amongst
themselves in both directions (www <-> secure).
Unfortunately, you may have a shitstorm of session chatter.
Presumably, you'll have a number of domain-specific servers and a
single secure one (or clustering all around, which actually makes the
chatter problem worse). That means that if you have 100 sessions on
each of 10 CCTLD servers then you'll have 10000 sessions on the secure
server. If that's okay, then go for it.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7ENssACgkQ9CaO5/Lv0PD6NACgsrmhV5v1yn1JKNz3Ap7tfQne
3kYAniU8iETd7qvDEjqdo38/MTEgGna3
=dvKy
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org