Previously SaveContextOnUpdateOrErrorResponseWrapper would save the SecurityContext on a different
Threads than the one it was created on. This causes issues with Async Web requests which may write
to the response on a new Thread.
Now SaveContextOnUpdateOrErrorResponseWrapper will not save the SecurityContext when a different
Thread invokes any of the methods that commit the response. This prevents issues with Async
processing. However, explicit calls to SecurityContextRepository.save will still save the
SecurityContext since it invokes the saveRequest method rather than private doSave method within
the SaveContextOnUpdateOrErrorResponseWrapper which contains the logic to prevent saving from
another Thread.
Previously a ConcurrentModificationException could occur when
PointcutExpression.matchesMethodExecution was performed in multiple threads. Another
issue was that beans may get processed multiple times.
Now a lock is performed to ensure that only a single thread has access to
PointcutExpression.matchesMethodExecution and that each bean only gets processed once.
Provide abstractions for transferring a SecurityContext across threads.
The main concepts are the DelegatingSecurityContextCallable and the
DelegatingSecurityContextRunnable which contain a SecurityContext to establish before
delegating to a Callable or Runnable.
There are also wrapper implementations for each of the key java.util.concurrent and
spring task interfaces to make using the DelegatingSecurityContextCallable and
DelegatingSecurityContextRunnable transparent to users. For example a
DelegatingSecurityContextTaskExecutor which can be injected with a specific
SecurityContext or use the SecurityContext from the SecurityContextHolder at the time the
task is submitted. There are similar implementations for each of the key
java.util.concurrent and spring task interfaces.
Note that in order to get DelegatingSecurityContextExecutorService to compile with
JDK 5 or JDK 6 we could not use type safe methods. See
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6267833 for details.
This can be used to generate the pom.xml for adding the Spring Security
snapshot jars as a Maven Dependency to another project. For example,
if mywebapp requires the Spring Security 3.1.4.CI-SNAPSHOT jars one
could generate the pom.xml files and then use that to convert the project
into a valid Maven project within the IDE. Then the SNAPSHOT dependendies
could be added to mywebapp. This prevents the need to install the SNAPSHOT
dependencies in the local Maven repository.
Previously the build would look up a server port dynamically, but since
it closed the port immediately it may not be reserved by the time jetty
started up.
We now reserve the port and do not close it till just before Jetty starts.
While there is still a race condition, it is much smaller window of time
than it was previously.
Previously authenticating a user could take significantly longer than
determining that a user does not exist. This was due to the fact that only
users that were found would use the password encoder and comparing a
password can take a significant amount of time. The difference in the
time required could allow a side channel attack that reveals if a user
exists.
The code has been updated to do comparison against a dummy password
even when the the user was not found.
Previously the SwitchUserFilter was logging as an error and then
throwing an Exception immediately after. This is not correct, since
whomever is catching the Exception should choose to log an error or not.
Now the log statement is at a debug level.
Previously there was a race condition could occur when the user attempts to access
a slow resource and then logs out which would result in the user not being logged
out.
SecurityContextLogoutHandler will now remove the Authentication from the
SecurityContext to protect against this scenario.
Previously, ConcurrentSessionFilter was placed after SecurityContextPersistenceFilter
which meant that the SecurityContextHolder was empty when ConcurrentSessionFilter was
invoked. This caused the Authentication to be null when performing a logout. It also
caused complications with LogoutHandler implementations that would be accessing the
SecurityContextHolder and potentially clear it out expecting that
SecurityContextPersistenceFilter would then clear the SecurityContextRepository.
The ConcurrentSessionFilter is now positioned after the
SecurityContextPersistenceFilter to ensure that the SecurityContextHolder is populated
and cleared out appropriately.
Ensure projects have the following so that Maven Central publishing works
- Project name
- Project description
- Project URL
- SCM information
- Javadoc jar
Previously anonymous authentication was submitted as credentials over the wire which
caused the applications to attempt to authenticate the anonymous user.
Now if the user is anonymous (determined by the AuthenticationTrustResolver), the
AuthenticationSimpleHttpInvokerRequestExecutor does not populate any credentials.
Previously Spring Security did not save the Security Context immediately prior
to the following methods being invoked:
- HttpServletResonse.flushBuffer()
- HttpServletResonse.getWriter().close()
- HttpServletResonse.getWriter().flush()
- HttpServletRespose.getOutputStream().close()
- HttpServletRespose.getOutputStream().flush()
This meant that the client could get a response prior to the SecurityContext
being stored. After the client got the response, it would make another request
and this would not yet be authenticated. The reason this can occur is because
all of the above methods commit the response, which means that the server can
signal to the client the response is completed. A similar issue happened in
SEC-398.
Now the previously listed methods are wrapped in order to ensure the SecurityContext
is persisted prior to the response being committed.
When SEC-1950 was introduced it caused problems when a <filter-mapping> was mapped
to multiple dispatchers (i.e. REQUEST and FORWARD) since when the second dispatcher
completed execution it cleared the SecurityContext and the original FilterChain
would then save the cleared out SecurityContext.
We now use a pattern similar to the OncePerRequestFilter to only invoke
SecurityContextHolder.clearContext() on the first invocation of the Filter. We do not simply extend
OncePerRequestFilter because we want to invoke the delegate filters for every request.
Spring Security 3.1 has a regression i the AccessControlListTag
which should support using the bitmask in hasPermission.
Now hasPermission supports bit masks again.
Spring Security 3.0.x allowed developers to pass in a , separated list of permissions.
However, this functionality was accidentally removed in SEC-1560.
The AcessControlListTag now splits the permissions using , as a delimiter
which fixes this passivity issue.
Rob Winch
Spring Buildmaster
mpigg