-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hardy,
On 9/10/15 5:08 PM, Pottinger, Hardy J. wrote: > I can see in our log files that we log the session ID as part of > the authentication process.... so it's probable that our > authentication code needs a bit more work to accommodate the > changing session ID. I'll see if I can figure it out. If you store the session id somewhere instead of always going-back to the actual session object to grab its id, you may have a problem. I believe there is a (non-spec-standard) listener you can attach that will be notified when sessions change ids. - -chris > ________________________________________ From: Christopher Schultz > [ch...@christopherschultz.net] Sent: Thursday, September 10, 2015 > 2:57 PM To: Tomcat Users List Subject: Re: seeking help with > stabilizing the persistence of a JSESSIONID > > Hardy, > > On 9/10/15 3:36 PM, Pottinger, Hardy J. wrote: >>> putting Serializable objects in the session is surely a good >>> idea in general. > >> I agree, especially, as you mention, if we intend to distribute >> sessions among various containers. > >>> Tomcat's session-fixation-prevention amounts to changing the >>> session identifier while keeping the session in-tact. So >>> unless you are using distributable sessions, this is unlikely >>> to be the problem. > >> You're absolutely right. I now have a serialized attribute, >> which is still lost upon the creation of the new session. Is >> there anything similar I can try, to ensure that the session >> attributes from the previous session are faithfully copied to the >> new session, after session-fixation-prevention does its thing? > > It's simpler than you think. Tomcat really does nothing other than > this after successful authentication: > > session.setSessionId(randomNewSessionId); > > The "new" session is in fact the same as the old session -- it > just has a new identifier. The client will get a Set-Cookie > response changing the JSESSIONID cookie value, and any URLs encoded > with HttpServletResponse.encodeURL or > HttpServletResponse.encodeRedirectURL will include the updated > session identifier (if appropriate). > > So the "loss" of your session attribute is puzzling. You could > write a noisy HttpSessionAttributeListener that logs every > session-attribute event (with a stack trace) to see if that > attribute is being removed elsewhere. > > -chris > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV8fLsAAoJEBzwKT+lPKRYWDAP/jjiOE3HurXXYMKfy02+kONx ao4Bz7ne/zQX7lXBgBuI+lF4MS78oXWx2rp5nF3H/VPXAZ2JesgfwU+U+VbagU8m 7PjCBQaY4QyceyJg7PkSdAT130xif/9sdlmml+qDBSRogBb8cO7TLxxPQZeL808I +1FL5KnAb5JK3jIwYkYY0/IH/r2zaMYeawHofyP+uDLvGQmz3fCJfTq5T0IZYAcy P2tiId0dVxmlF70mcP71SVeHNowBKkNucNCnubM1rNPxCc84zgbvc6mYw6jf2Daq 5MlRyCLrjFaTlEHkLkIjlbLHav5CXFkom7jvBlg1jv852Wzjf3RKmzCzzPOSAsvd GCxi54wU9j0LDFwxBvyro14j56eBlaPcT//7VrZDrL8/HHv37PvivYZ0Iw8dTTls kNKPzFHg0FVYj3kq8DDof3H1YJ+LV8LalRYS/qqv/LAxzq9lSe5qObovd8MoVuPz /IePfZLkNV9cLVZo/iIuvfrpKY41gdGD1hrlY9+F6BPhPHoNpCj5n1r7UK9F38gr qXP5IdrpN7uSnMGpzvbXYSwrRswBTyQVShqsdCVJQWS++GLjLDWxdv/fxbYXc9ac oMyeEoCpinzJ+MmTMIc9dAJecGUDayJP+KMQvabPUkd4Ee33R+27P9/zoQI12Sds 4uCO7ksTV7qLWpjybm3o =n+Ja -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
