-----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

Reply via email to