Prior to this, the HttpSecurity bean was not consistent with WebSecurityConfigurerAdapter's HttpSecurity because it did not setup a default AuthenticationEventPublisher. This also fixes a problem where the AuthenticationEventPublisher bean would only be considered if there was a UserDetailsService
Closes gh-11449
Closes gh-11726
Prior to this, the HttpSecurity bean was not consistent with WebSecurityConfigurerAdapter's HttpSecurity because it did not setup a default AuthenticationEventPublisher. This also fixes a problem where the AuthenticationEventPublisher bean would only be considered if there was a UserDetailsService
Closes gh-11449
Closes gh-11726
Prior to this, the HttpSecurity bean was not consistent with WebSecurityConfigurerAdapter's HttpSecurity because it did not setup a default AuthenticationEventPublisher. This also fixes a problem where the AuthenticationEventPublisher bean would only be considered if there was a UserDetailsService
Closes gh-11449
Closes gh-11726
Prior to this, the HttpSecurity bean was not consistent with WebSecurityConfigurerAdapter's HttpSecurity because it did not setup a default AuthenticationEventPublisher. This also fixes a problem where the AuthenticationEventPublisher bean would only be considered if there was a UserDetailsService
Closes gh-11449
Closes gh-11726
SessionAuthenticationFilter requires accessing the HttpSession to do its
job. Previously, there was no way to just disable the
SessionAuthenticationFilter despite the fact that
SessionAuthenticationStrategy is invoked by the authentication filters
directly.
This commit adds an option to disable SessionManagmentFilter in favor of
requiring explicit SessionAuthenticationStrategy invocation already
performed by the authentication filters.
Closes gh-11455
SessionAuthenticationFilter requires accessing the HttpSession to do its
job. Previously, there was no way to just disable the
SessionAuthenticationFilter despite the fact that
SessionAuthenticationStrategy is invoked by the authentication filters
directly.
This commit adds an option to disable SessionManagmentFilter in favor of
requiring explicit SessionAuthenticationStrategy invocation already
performed by the authentication filters.
Closes gh-11455
There is no whitespace between error message and IP address value `IpAddressMatcher#parseAddress()`
If IP value is wrong, then error text looks like `Failed to parse addressi.am.ip`.
There should be some separator between those two text tokens.
Also wrapped the address value with single quotes.
Will this add any confusion for the caller?
Or colon and `"Failed to parse address: $value` looks better?
To avoid relying on HTML event handlers and adding unsafe-* rules to CSP, the javascript is moved to a <script> tag. This also allows a better browser compatibility
Closes gh-11676
To avoid relying on HTML event handlers and adding unsafe-* rules to CSP, the javascript is moved to a <script> tag. This also allows a better browser compatibility
Closes gh-11676
Previously the CsrfToken was set on the request attribute with the name
equal to CsrfToken.getParameterName(). This didn't really make a lot of
sense because the CsrfToken.getParameterName() is intended to be used as
the HTTP parameter that the CSRF token was provided. What's more is it
meant that the CsrfToken needed to be read for every request to place it
as an HttpServletRequestAttribute. This causes unnecessary HttpSession
access which can decrease performance for applications.
This commit allows setting CsrfFilter.csrfReqeustAttributeName to
remove the dual purposing of CsrfToken.parameterName and to allow deferal
of reading the CsrfToken to prevent unnecessary HttpSession access.
Issue gh-11699
Previously LazyCsrfTokenRepository supported lazily saving the CsrfToken
which allowed for lazily saving the CsrfToken. However, it did not
support lazily reading the CsrfToken. This meant every request required
reading the CsrfToken (often the HttpSession).
This commit allows for lazily reading the CsrfToken and thus prevents
unnecessary reads to the HttpSession.
Closes gh-11700
Previously the CsrfToken was set on the request attribute with the name
equal to CsrfToken.getParameterName(). This didn't really make a lot of
sense because the CsrfToken.getParameterName() is intended to be used as
the HTTP parameter that the CSRF token was provided. What's more is it
meant that the CsrfToken needed to be read for every request to place it
as an HttpServletRequestAttribute. This causes unnecessary HttpSession
access which can decrease performance for applications.
This commit allows setting CsrfFilter.csrfReqeustAttributeName to
remove the dual purposing of CsrfToken.parameterName and to allow deferal
of reading the CsrfToken to prevent unnecessary HttpSession access.
Issue gh-11699
Previously LazyCsrfTokenRepository supported lazily saving the CsrfToken
which allowed for lazily saving the CsrfToken. However, it did not
support lazily reading the CsrfToken. This meant every request required
reading the CsrfToken (often the HttpSession).
This commit allows for lazily reading the CsrfToken and thus prevents
unnecessary reads to the HttpSession.
Closes gh-11700
