Java Configuration now allows optional @Autowire of
AuthenticationTrustResolver. In the WebSecurityConfigurerAdapter this is
done by populating AuthenticationTrustResolver as a sharedObject.
Previously GlobalMethodSecurityConfiguration did not include the correct
voters. This updates the code and the tests to ensure that the proper
voters are added. Note this got past testing previously due to all the
voters abstaining, so tests were added for ensuring that methods could also
be invoked sucessfully using the configured annotation.
This also removed the CsrfToken from the response headers to prevent the
token from being saved. If user's wish to return the CsrfToken in the
response headers, they should use the CsrfToken found on the request.
Added JavaConfig for Headers. In the process, more HeaderWriter instances
were added so that we can reuse logic between the XML and JavaConfig. This
also prompted repackaging the writers.
Previously an error occurred when no child elements were specified with
<headers/>.
Now all the explicitly supported header elements are added with their
default settings.
This is a distinct filter as apposed to reusing StaticHeaderWriter
since the specification specifies that the "Strict-Transport-Security"
header should only be set on secure requests. It would not make sense to
require DelegatingRequestMatcherHeaderWriter since this requirement is
in the specification.
- hf.doFilter is missing FilterChain argument
- response.headers does not contain the exact values for the headers so
should not be used for comparison (note it is a private member so this
is acceptable)
- hf does not need non-null check when hf.doFilter is invoked
- some of the configurations are no longer valid (i.e. ALLOW-FROM
requires strategy)
- Some error messages needed updated (some could still use improvement)
- No validation for missing header name or value
- rebased off master / merged
- nsa=frame-options-strategy id should use - not =
- FramewOptionsHeaderFactory did not produce "ALLOW-FROM " prefix of origin
- remove @Override on interface overrides to work with JDK5
- Implemented different ALLOW-FROM strategies as specified in the proposal.
Conflicts:
config/src/main/java/org/springframework/security/config/http/HeadersBeanDefinitionParser.java
config/src/test/groovy/org/springframework/security/config/http/HttpHeadersConfigTests.groovy
Created HeadersFilter for setting security headers added including a
bean definition parser for easy configuration of the headers. Enables
easy configuration for the X-Frame-Options, X-XSS-Protection and
X-Content-Type-Options headers. Also allows for additional headers to
be added.
Previously invoking methods like HttpSecurity#authorizeUrls() multiple
times would override one another. This has now changed to be more
intuitive. Initially this was required for the way that defaults were
provided so that they could be overriden, but this is no longer the case.
This ensures that users must choose what ObjectPostProcessor is being used
with AuthenticationManagerBuilder. To make things easier for users, we now
automatically add an AuthenticationManagerBuilder object that can be used
for creating an AuthenticationManager with @Autowired.
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.
