Changed the bean definition method for the DelegatingApplicationListener
to be static to avoid the need to instantiate the configuration class which
caused further premature initializations to satisfy the dependencies
expressed in setFilterChainProxySecurityConfigurer(…).
In 3.1 the accesscontrollist tag began performing an and on the
permissions. This may have been accidental, but I think that it is more
intuitive & secure for it to behave this way. When compared to hasAnyRole
and hasRoles the hasPermission tag implies it is an and. If users end up
needing OR support, then the authorize tag can be used along with the
hasPermission expression. For example:
<sec:authorize access="hasPermission(#domain, 'read') or hasPermission(#domain, 'write') ">
In general, the authorize tag should be preferred as it is the more
powerful way of performing authorization checks.
Previously SavedRequestAwareWrapper overrode the getCookies() method. This
meant that the cookies from the original request were used instead of the
new request. In general, this does not make sense since cookies are
automatically submitted in every request by a client. Additionally, this
caused problems with using a locale cookie that was specified after the
secured page was requested.
Now SavedRequestAwareWrapper uses the new incoming request for determining
the cookies.
Prior to this change, ApacheDSContainer created a LdifFileLoader
without a ClassLoader. This limited its ability to load LDIF files
and causes a problem with an executable war in Spring Boot. See [1]
for details.
ApacheDSContainer now initialises LdifFileLoader with a ClassLoader.
This allows it to locate LDIF files packaged in WEB-INF/classes in
the case of an executable war file. The executable jar case was not
affected by this problem as, in that case, the LDIF file is pacakaged
in the root of the jar and is accessible via getSystemResourceAsStream
[1] https://github.com/spring-projects/spring-boot/issues/1550
Rob Winch
Oliver Gierke
Mikhail Stryzhonok
Rob Winch
Andy Wilkinson