Session fixation protection, whether by clean new session or
migrated session, now publishes an event when a session is
migrated or its ID is changed. This enables application developers
to keep track of the session ID of a particular authentication
from the time the authentication is successful until the time
of logout. Previously this was not possible since session
migration changed the session ID and there was no way to
reliably detect that.
Revised changes per Rob Winch's suggestions.
Modified BCryptPasswordEncoder to no longer throw an
IllegalArgumentException when the encoded password is empty or
the incorrect format for bcrypt. Instead it now logs a warning
that non bcrypt data was found.
The Dms integration tests were failing after being changed to
use bcrypt and this fixes the issue.
Changed the namespace doc to use an explicit form-login
and logout element and avoid mention of auto-config or its
effects. This makes the intro shorter and simpler.
This change extends pull request https://github.com/SpringSource/spring-security/pull/26
and its subsequent changes by renaming the attribute name 'rememberme-parameter' to
'remember-me-parameter'.
The spelling including the additional hyphen in 'remember-me-parameter' is more consistent
with the default spelling of the 'remember-me' functionality.
This change extends the namespace configuration of <remember-me>
with a 'form-parameter' attribute. The introduced attribute sets
the 'parameter' property of AbstractRememberMeServices.
This enables overriding the default value of
'_spring_security_remember_me' using the namespace configuration.
Previously wiring dependencies created with a FactoryBean into
MethodSecurityExpressionHandler &
MethodSecurityExpressionHandler.expressionParser and would cause
NoSuchBeanDefinitionException's to occur. These changes make it easier
(but not impossible) to avoid such errors.
The following changes were made:
- ExpressionBasedAnnotationAttributeFactory delays the invocation of
MethodSecurityExpressionHandler.getExpressionParser()
- MethodSecurityExpressionHandler is automatically wrapped in a
LazyInitTargetSource and marked as lazyInit=true
Previously Spring Security would disable automatically saving the
SecurityContext when the Thread was different than the Thread that
created the SaveContextOnUpdateOrErrorResponseWrapper. This worked for
many cases, but could cause issues when a timeout occurred. The problem
is that a Thread can be reused to process the timeout since the Threads
are pooled. This means that a timeout of a request trigger an apparent
logout as described in the following workflow:
- The SecurityContext was established on the SecurityContextHolder
- An Async request was made
- The SecurityContextHolder would be cleared out
- The Async request times out
- The Async request would be dispatched back to the container upon
timing out. If the container reused the same Thread to process the
timeout as the original request, Spring Security would attempt to
save the SecurityContext when the response was committed. Since the
SecurityContextHolder was still cleared out it removes the
SecurityContext from the HttpSession
Spring Security will now prevent the SecurityContext from automatically
being saved when the response is committed as soon as
HttpServletRequest#startAsync() or
ServletRequest#startAsync(ServletRequest,ServletResponse) is called.
Both overloads of
AbstractAuthenticationProcessingFilter.successfulAuthentication()
claimed to invoke SessionAuthenticationStrategy, which is not true, as
the invokation happens earlier in doFilter(). The Javadoc on these
methods are updated to reflect the actual code.
Previously DummyRequest implemented HttpServletRequest which caused complications
since Servlet 2.5 and Servlet 3 had non passive changes. While we were "safe" if the
Servlet 3 methods were never invoked reflective access of the methods would also
problems. We could prevent users from accessing the methods of DummyRequest by
returning new HttpServletRequestWrapper(DummyRequest), but a debugger could
potentially try to iterate over the methods triggering a NoClassDefFoundError.
DummyRequest now extends HttpServletRequestWrapper which will be dynamically
linked to the proper version of HttpServletRequest. We use a Dynamic Proxy that
throws UnsupportedOperationException to implement any methods we are not
interested in.
Rob Winch
Luke Taylor
Nicholas Williams
Oliver Becker
Mike Noordermeer
Raghuram Devarakonda
@fbiville
Rob Winch
Jean-Pierre Bergamin
Georges-Etienne Legendre
Marten Deinum
Balazs Zagyvai