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.
Previously communication errors with LDAP were only logged at debug level.
Communication errors (along with other non-authenticated related NamingExceptions)
are now logged as error messages. We created an InternalAuthetnicationServiceException
to represent errors that should be logged as errors to distinguish between internal
and external authentication failures. For example, we do not want an OpenID Provider
being able to report errors that cause our logs to fill up. However, an LDAP system is
internal and should be trusted so logging at an error level makes sense.
Previously the namespace configuration did not properly set the eraseCredentialsAfterAuthentication
property on the parent AuthenticationProvider when using http@authentication-manager-ref.
Now the ProviderManager that is created by the namespace consults the original
AuthenticationManager to determine if eraseCredentialsAfterAuthentication should
be set on the wrapped instance. If the original is not a ProviderManager the
eraseCredentialsAfterAuthentication is set to false since we should not "magically"
add behavior to the custom AuthenticationManager without knowing the desired behavior.
Due to Eclipse restrictions the classpath adding an project as a dependency picks up
the test dependencies of other projects. This caused problems when running the
config integration tests within Eclipse.
Now the tests specify a specific ldif to load. There is also one new test that ensures
that the ldif is defaulted properly, but does not rely on the ldif that is loaded.
Previously there was no way to extract the original exception or to easily
obtain details about the failure if Spring Security was not able to translate
the exception into a Spring Security AuthenticationException.
Now the caused by is an ActiveDirectoryAuthenticationException which contains
the original Active Directory error code.
Previously there was a bug introduced by SEC-546 that prevented any
AccountStatusException from being published.
Now AccountStatusExceptions are also published.
Previously subclasses of AbstractSecurityInterceptor did not restore the original
Authentication when RunAsManager was used and an Exception was thrown in the
original method.
AbstractSecurityInterceptor has added a new method finallyInvocation which
should be invoked in a finally block immediately after the original invocation
which will restore the original Authentication. All existing sub classes have
been updated to use this new method.
The javadoc did not work with JDK 1.5 due to a JDK bug fixed in JDK 1.6.
This changed the javadoc that had a tag that started with <a and was not
closed to escape the < >. This resolves the issue with the JDK 1.5 javadoc
bug.
Previously the javadoc stated that password could not be null. However,
since the introduction of CredentialsContainer introduced in SEC-1493 the
password can be null.
The changes remove the statement that passwords cannot be null. While this
is a non-passive change to the interface, the current state leaves no choice
for a non-passive change. Removing the javadoc was determined the better
option since erasing the credentials was an explicit feature request. Note
that replacing the password with an obscure String can be risky as it
introduces the risk that the value is used to authenticate.
Previously there were problems when importing with ./gradlew eclipse. For
example GRADLE-1116 and GRADLE-1422.
The changes provide workarounds that are compatible with Gradle 1.0. Note
when importing after using ./gradlew eclipse users may get errors stating
"Element not found". This is only at the time of import and can be ignored.
This is an Eclipse bug logged as
https://bugs.eclipse.org/bugs/show_bug.cgi?id=244315
Previously the documentation was referring to what ConcurrentSessionControlStrategy
performed.
Now the documentation has been moved to the ConcurrentSessionControlStrategy#onAuthentication
method.
Previously SessionFixationProtectionStrategy javadoc mentioned injecting
the SessionRegistry. However, this property is only available on
ConcurrentSessionControlStrategy (a subclass).
Now the mention has been removed. It is apparent the property is required
in ConcurrentSessionControlStrategy since it uses constructor injection.
Previously JdbcTokenRepositoryImpl would log an error with a misleading
message when the token series was missing.
Now JdbcTokenRepositoryImpl logs missing token series at info level with
a more informative message.
Previously the namespace configuration only populated ConcurrentSessionFilter
with SecurityContextLogoutHandler. This means that there was an inconsistency
with LogoutFilter.
Now the namespace will configure the same LogoutHandlers as it would for
LogoutFilter (i.e. RememberMeServices, SecurityContextLogoutHandler, and
CookieClearingLogoutHandler.
Previously the namespace configuration used deprecated API's
causing warnings to show up in Spring Tool suite when editing
Spring configuration files.
Now the namespace configuration uses the replacement API's for
those that have been deprecated. The tests have also been updated
to ensure the new constructors are used and that the updates did
not break anything.
Technically digest authentication can allow for encoded passwords, but
it needs to be in the correct format. This update adds a footnote to clarify this.
Previously the documentation stated that passwords must be in clear text.
Previously a warning would be logged to the parser when a URL was
configured with a SpEL expression. These changes prevent warnings from
being logged when using SpEL for URL configuration.
Rob Winch
mpigg
Spring Buildmaster