-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Joseph,
On 3/14/14, 9:49 AM, Joesph Bleau wrote: > I should also mention that after some very simple testing I was > able to confirm that (of course) Tomcat is notifying my application > when the session is invalidated in a valve. I'm still fairly new to > this entire stack, so forgive my ignorance. :-) No problem. Tomcat does in fact change the session id, but only *after* a successful authentication (but before the session is blessed with authentication information). I believe you said something about changing the session id when the user accesses the login page -- regardless of whether the authentication attempt is successful. Tomcat doesn't do that. Mark does a good job describing the whole situation here: http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection - -chris > On Fri, Mar 14, 2014 at 9:46 AM, Joesph Bleau > <jbl...@systemsinmotion.com>wrote: > >> It's possible (read: likely) that we're doing something >> incorrectly, but we're using Spring and it was already attempting >> to provide session fixation within the application by >> invalidating sessions upon authentication. However, it appears >> that tomcat was providing us with the same session ID for our new >> session. I've scoured the internet and I've seen that I'm not the >> first person to have this problem, but there was no definitive >> solution available. I ultimately settled on invalidating the >> session in the valve which appeared to work, tomcat didn't >> provide the same ID here. >> >> >> On Fri, Mar 14, 2014 at 8:37 AM, Christopher Schultz < >> ch...@christopherschultz.net> wrote: >> > Joseph, > > On 3/14/14, 5:59 AM, Joesph Bleau wrote: >>>>> Right now we're running our application in Tomcat and >>>>> using hazelcast to share information across our multiple >>>>> instances. In an attempt to prevent session fixation I >>>>> implemented a tomcat valve which invalidates sessions when >>>>> a user authenticates (or in this case, just visits the >>>>> authentication endpoints). This is causing an issuue where >>>>> our application proper isn't getting notified of >>>>> invalidated sessions and they're hanging around in the >>>>> hazelcast map. > > Any reason not to trust Tomcat's session-fixation prevention > (which implements session-id changing, and already works across a > cluster). > >>>>> I tried everything I could to fix the session fixation >>>>> problem within the scope of my application but no matter >>>>> what I did it seemed like tomcat would persist a users >>>>> session even after invalidating it, so this was my >>>>> solution, and of course I face an equally annoying and >>>>> difficult problem. >>>>> >>>>> We're using tomcat7, apache 2.2 / mod_jk to load balance, >>>>> spring 3.1, and hazelcast 2.2 >>>>> >>>>> Any and all advice / tips / scorn appreciated. :-) Joseph >>>>> Bleau >>>>> >>> >>> --------------------------------------------------------------------- >>> >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTIxpzAAoJEBzwKT+lPKRY+/UP/Rdkh0MNfN5TY1ZhoEbAK6Za ezTQjdGFdSOltXiPgOKzGeWE4qXpKgexBNJgrhADRxH1AFFOuxqTnm0SS1NApwh0 t95e1NidfyzyKJwUxFdmdVlGeSEKcA2zRWqDt4+vh67F2ZdQyhgxfCfd8yh/xj74 lXKXHpMcsskUCtplTyn0uUmo/ASxCW8uFT2YJUaUNINTQMBInQLc90VopgIwRDEh fRUcsBnZbS7bJjIZZDz9iP7PotMquTCjPh7PkMRd8+XbkpyxzY+ybCJDLKfgMrh5 vhYB1T//w5S9ouVdqrAtRQXY4e+te+zciAt/a5jdl9xyTUT2WVmDYzIOo9e3ygWz nrRIqVtBCFt9nJ2Ors8U+F4clK0KI4Ckgj3V/b23HU2SrcLK656K12HAD3HA7Gmk UZbwaInMjanpAa+5gHbtHlsWMzjS9u7hCBocsN2qV96ltMr5zYfp/YECuZxfdkrm Otk5sKGDdDBOi7nfku/X7Kp8PSyCrStW7OtldVMVRFNIsM4w/zISfRjzPlTiLDwo lKjiEVT6C+cyZH9xBr/hCldqwz7DWpDYS7zy+zFOYmtFp+6bRfOaymlyhEmOMzPA E67+pvQ7JobpUEcfxjVOPsZu/NstBwmEj0pb0GxeEa7pr08rJd6EbGsgt/grm3K8 pYYicJag7lu8avH9ilAw =+evb -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org