Previously there was unecessary complexity in CsrfRequestDataValueProcessor
due to the non-passive changes in RequestDataValueProcessor. Now it simply
implements the interface with the methods for both versions of the interface.
This works since linking happens at runtime.
Previously session fixation protection could output an incorrect warning
that session fixation protection did not work.
The code now synchronizes on WebUtils.getSessionMutex(..).
Previously a ClassCastException was thrown if the type was invalid. Now
a flag exists on AuthenticationPrincipal which indicates if a
ClassCastException should be thrown or not with the default being no error.
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.
Previously AbstractSecurityWebApplicationInitializer delegated to a
WebApplicationInitializer, but it caused issues in some instances where
a container would pass the annonymous inner class to
SpringServletContainerInitializer which caused errors on startup.
Now AbstractSecurityWebApplicationInitializer registers the
ContextLoaderListener on its own instead of delegating.
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.
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
