question about session invalidation

[Toby Cabot]

Hi,

We've been using msm for a while now and it's been working great.  Thanks!

We're upgrading from tomcat6 to tomcat7 and I've been seeing strange behavior around logout and login.  Context: I've got two servers, non-sticky sessions, lockingMode "all", sessionBackupAsync "false", and I'm using the XStream serializer.

We see login failures in a very specific case: when I use an automated headless browser to log out and then immediately log in.  There don't seem to be any errors in the log, but the browser ends up back at the login form instead of inside the application.  This only happens when I'm using two servers and an automated headless browser.  If I fall back to a single server then everything works great.

One thing I noticed while debugging is that the session cookie is never invalidated.  The session is removed from memcached, but then a new session is opened in the same request and the cookie is re-used on subsequent requests.  Is this intended?  For example, here's a sample from our log:

FINE: >>>>>> Request starting: GET /portal/auth/signOut (requestedSessionId F54D406838A3614C62FE4EFFB2A4AA3F-n1) ==================
Mar 10, 2016 5:27:48 PM de.javakaffee.web.msm.SessionIdFormat createSessionId
FINE: Creating new session id with orig id 'ping' and memcached id 'n1'.
Mar 10, 2016 5:27:48 PM de.javakaffee.web.msm.NodeAvailabilityCache updateIsNodeAvailable
FINE: CacheLoader returned node availability 'true' for node 'n1'.
Mar 10, 2016 5:27:48 PM de.javakaffee.web.msm.MemcachedSessionService loadFromMemcached
FINE: Loading session from memcached: F54D406838A3614C62FE4EFFB2A4AA3F-n1
Mar 10, 2016 5:27:48 PM de.javakaffee.web.msm.LockingStrategy lock
FINE: Locking session F54D406838A3614C62FE4EFFB2A4AA3F-n1
Mar 10, 2016 5:27:48 PM de.javakaffee.web.msm.LockingStrategy acquireLock
FINE: Locked session F54D406838A3614C62FE4EFFB2A4AA3F-n1
Mar 10, 2016 5:27:48 PM de.javakaffee.web.msm.LockingStrategy lock
FINE: Locked session F54D406838A3614C62FE4EFFB2A4AA3F-n1
Mar 10, 2016 5:27:48 PM de.javakaffee.web.msm.MemcachedSessionService loadFromMemcached
FINE: Found session with id F54D406838A3614C62FE4EFFB2A4AA3F-n1
Mar 10, 2016 5:27:48 PM de.javakaffee.web.msm.MemcachedBackupSessionManager removeInternal
FINE: remove invoked, removeFromMemcached: true, id: F54D406838A3614C62FE4EFFB2A4AA3F-n1
Mar 10, 2016 5:27:48 PM de.javakaffee.web.msm.MemcachedSessionService deleteFromMemcached
FINE: Deleting session from memcached: F54D406838A3614C62FE4EFFB2A4AA3F-n1
Mar 10, 2016 5:27:48 PM de.javakaffee.web.msm.LockingStrategy releaseLock
FINE: Releasing lock for session F54D406838A3614C62FE4EFFB2A4AA3F-n1
Mar 10, 2016 5:27:48 PM de.javakaffee.web.msm.MemcachedSessionService createSession
FINE: createSession invoked: F54D406838A3614C62FE4EFFB2A4AA3F-n1
Mar 10, 2016 5:27:48 PM de.javakaffee.web.msm.MemcachedSessionService createSession
FINE: Created new session with id F54D406838A3614C62FE4EFFB2A4AA3F-n1
Mar 10, 2016 5:27:48 PM de.javakaffee.web.msm.MemcachedSessionService createSession
FINE: Remove session id  F54D406838A3614C62FE4EFFB2A4AA3F-n1  from _invalidSessionsCache, marking new session valid
Mar 10, 2016 5:27:48 PM de.javakaffee.web.msm.MemcachedBackupSessionManager removeInternal
FINE: remove invoked, removeFromMemcached: true, id: F54D406838A3614C62FE4EFFB2A4AA3F-n1
Mar 10, 2016 5:27:48 PM de.javakaffee.web.msm.MemcachedSessionService deleteFromMemcached
FINE: Deleting session from memcached: F54D406838A3614C62FE4EFFB2A4AA3F-n1
Mar 10, 2016 5:27:48 PM de.javakaffee.web.msm.MemcachedSessionService backupSession
FINE: No session found in session map for F54D406838A3614C62FE4EFFB2A4AA3F-n1
Mar 10, 2016 5:27:48 PM de.javakaffee.web.msm.RequestTrackingHostValve logDebugRequestSessionCookie
FINE: Have request session cookie: domain=null, maxAge=-1, path=null, value=F54D406838A3614C62FE4EFFB2A4AA3F-n1, version=0, secure=false
Mar 10, 2016 5:27:48 PM de.javakaffee.web.msm.RequestTrackingHostValve invoke
FINE: <<<<<< Request finished: GET /portal/auth/signOut ==================

Is there a way to get msm to invalidate the session cookie so that it makes a new one when the user logs back in?  Or is this a red herring?

Thanks!

[Martin Grotzke]

Not sure if this helps directly, but for further reading:
https://github.com/magro/memcached-session-manager/issues/185
http://markmail.org/message/7rb3h3ptyltdof3e#query:+page:1+mid:4tlg4tv4iudevyq7+state:results
http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection

Cheers,
Martin

--

---
You received this message because you are subscribed to the Google Groups "memcached-session-manager" group.
To unsubscribe from this group and stop receiving emails from it, send an email to memcached-session-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Toby Cabot]

Hi Martin,

Thanks for the links, they're very informative (esp. the first one).  I'm using a session cookie path of "/" which evidently tomcat considers special, so that might explain why the session is getting re-used.  As an experiment I explicitly deleted the cookie in my authn controller and now it appears to be working well, i.e., I can now reliably log in and out in quick succession.

Thanks for your help!

[Martin Grotzke]

Hi Toby,

great that it's working now!

Cheers,
Martin