On 02/10/2013 22:26, Stefan Haberl wrote: > I've a context.xml like so: > > <Context sessionCookieDomain="acme.org" sessionCookieName="acme" > useHttpOnly="true" disableURLRewriting="true" /> > > <!-- disable persistent sessions --> <Manager pathname="" /> > > </Context> > > > I'm using Spring Security, which creates a new session after a user > has been authenticated to prevent session fixation attacks. > Everything works as expected *unless* I add a > sessionCookiePath="/" to the config above. With the cookie path set > to root the following code (inside Spring Security's > SessionFixationProtectionStrategy): > > HttpSession session = request.getSession(); String originalSessionId > = session.getId(); ... session.invalidate(); session = > request.getSession(true); // we now have a new session … > > will yield the *original* session again! I'm runnning on Tomcat > 7.0.42. > > Setting the cookie path to root is not necessary in my case (because > I'm running the webapp as ROOT anyhow), but is this expected > behaviour?
Yes, this is expected behaviour. The documentation hints at this but does not make it explicitly clear. Setting sessionCookiePath="/" is treated as a special case to support portlet implementations. Once one web application obtains a session all subsequent sessions for any web application also configured with sessionCookiePath="/" will always get the same session ID. This holds even if the session is invalidated and a new one created. I'll add some clearer text to the documentation. If a set of web application operates in this mode, changing the session ID is a lot harder. You'd have to write a custom Tomcat component to do it for you and even then I'm not sure that you can guarantee a smooth change over. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
