Spring Security

Luke Taylor added a comment - 14/May/08 7:20 PM Option 1 above will actually be much simpler than the previous approach - if the user is currently authenticated, but no security context is stored in the session then the user has been authenticated during the current request and a new session should be created. However, this won't work for situations where a redirect is performed after authentication, such as AuthenticationProcessingFilter because the session fixation filter won't be called during that request. When next request comes in, the context will already be stored in the session. Classes which extend AbstractProcessingFilter already have support for session fixation protection following the changes for SEC-399, so a combined approach will cover both options. HttpSecurityBeanDefinitionParser can set the appropriate properties on these classes and insert the new filter. This should also remove the problem dealt with in SEC-767, as the new session will be created before the request has passed through the security filter chain.

Luke Taylor added a comment - 14/May/08 8:37 PM I've basically gone with the option suggested in the previous comment. The namespace now also sets the necessary properties on AbstractProcessingFilter (openid or form login, basically). Other authentication mechanisms which don't involved a redirect will be handled by the filter which is now placed before FilterSecurityInterceptor in the stack. Needs some testing, but should be resolved.

David Erickson added a comment - 28/Jun/08 9:47 PM As of 2.0.2 I am still seeing this issue when using session-fixation-protection="migrateSession". If I set it to "none" the problem disappears.