Support multiple contexts sharing the same session id

[GoogleCodeExporter]

If multiple contexts share the same session id they're working on the same 
object in memcached. This leads to issues because context A might now know 
context B's classes so that deserialization fails.

Original issue reported on code.google.com by martin.grotzke on 31 Jul 2013 at 3:20

• Blocking: #156

[GoogleCodeExporter]

Original comment by martin.grotzke on 31 Jul 2013 at 3:32

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by martin.grotzke on 29 Sep 2013 at 7:42

• Now blocking: #156

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

on 156 you wrote:
"This is on the top of my todo list - sessions/objects must be saved in 
memcached with the context path as prefix."
thats not the whole part, the hostname has to be encoded too.

on which use case context's will share the same session id? this is only the 
case if they are working on the same memcached storage.
i created a memcached factory that is accessing the whole stuff with a prefix 
for another use case, maybe the factory can get part of the spy memcached 
project and the user can choose a prefix (instead of using a combination of 
context+host).

Original comment by hajo.kli...@gmail.com on 3 Oct 2013 at 9:25

[GoogleCodeExporter]

> the hostname has to be encoded too.

I don't think so, because cookies are tied to the hostname: a JSESSIONID cookie 
on host1.org does not conflict with a JSESSIONID cookie for host2.org. Maybe 
it's a difference for subdomains - but does tomcat allow to share a session 
over multiple hosts? Needs investigation.

> maybe [..] the user can choose a prefix (instead of using a combination of 
context+host)

Sounds reasonable. So msm would use the context (and perhaps + hostname) as 
default, and the user is able to override this.

Original comment by martin.grotzke on 4 Oct 2013 at 4:40

[GoogleCodeExporter]

Tomcat allows to configure the cookie domain per context. I'd say this is 
sufficient to control cookie/session handling for different subdomains.

From the tomcat docs 
(http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Common_Attributes):

  sessionCookieDomain
    The domain to be used for all session cookies created for this context. If set, this overrides any domain set by the web application. If not set, the value specified by the web application, if any, will be used.

What do you think?

Original comment by martin.grotzke on 4 Oct 2013 at 7:18

[GoogleCodeExporter]

Obviously the host *has* to be included, because in memcached sessions from 
different hosts with the same tomcat would have the same key. As suggested by 
Peter Rossbach it would also be good to be able to activate this feature 
(extended keys) optionally, so that by default just the sessionId is used and 
no additional space is wasted in memcached / the storage.

Original comment by martin.grotzke on 22 Nov 2013 at 1:07

[GoogleCodeExporter]

Original comment by martin.grotzke on 23 Jan 2014 at 7:17

• Changed state: Started

[GoogleCodeExporter]

Related thread that's "interested" in this: 
https://groups.google.com/forum/m/#!topic/memcached-session-manager/Hv4SKFXuQV8

Original comment by martin.grotzke on 23 Jan 2014 at 7:25

[GoogleCodeExporter]

Here's a build of msm that allows to configure a prefix for sessions stored in 
memcached via the attribute "storageKeyPrefix".

The configuration has the form $token,$token. Some examples which config would 
create which output for the key / session id "foo" with context path "ctxt" and 
host "hst":

static:x -> x_foo
host -> hst_foo
host.hash -> e93c085e_foo
context -> ctxt_foo
context.hash -> 45e6345f_foo
host,context -> hst:ctxt_foo
webappVersion -> 001_foo
host.hash,context.hash,webappVersion -> e93c085e:45e6345f:001_foo

Original comment by martin.grotzke on 24 Jan 2014 at 1:08

Attachments:

• memcached-session-manager-1.7.1-SNAPSHOT.jar
• memcached-session-manager-tc6-1.7.1-SNAPSHOT.jar
• memcached-session-manager-tc7-1.7.1-SNAPSHOT.jar

[GoogleCodeExporter]

Fixed in master

Original comment by martin.grotzke on 24 Jan 2014 at 9:32

• Changed state: Fixed
• Added labels: Milestone-1.8.0