If Spring MVC is present in the classpath, use MvcRequestMatcher by default. This commit also adds a new securityMatcher method in HttpSecurity
Closes gh-11347
Closes gh-9159
OWASP recommends using "X-Xss-Protection: 0". The default is currently
"X-Xss-Protection: 1; mode=block". In 6.0, the default will be "0".
This commits adds the ability to configure the xssProtection header
value in ServerHttpSecurity.
This commit deprecates the use of "enabled" and "block" booleans to
configure XSS protection, as the state "!enabled + block" is invalid.
This impacts HttpSecurity.
Issue gh-9631
In 6.0, RequestAttributeSecurityContextRepository will be the default
implementation of SecurityContextRepository. This commit adds the
ability to configure a custom SecurityContextHolderStrategy, similar
to other components.
Issue gh-11060
Closes gh-11895
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?
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
Previously loadContext(HttpServletRequest) could return a Supplier that
returned a null SecurityContext
This commit ensures that null is never returned by the Supplier by
returning SecurityContextHolder.createEmptyContext() instead.
Closes gh-11606
Previously loadContext(HttpServletRequest) could return a Supplier that
returned a null SecurityContext
This commit ensures that null is never returned by the Supplier by
returning SecurityContextHolder.createEmptyContext() instead.
Closes gh-11606
Previously loadContext(HttpServletRequest) could return a Supplier that
returned a null SecurityContext
This commit ensures that null is never returned by the Supplier by
returning SecurityContextHolder.createEmptyContext() instead.
Closes gh-11606
Currently if trace logging is enabled a StackOverflowException is thrown
when trying to resolve toString of the authentication.
java.lang.StackOverflowError: null
at java.base/java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:538) ~[na:na]
at java.base/java.lang.StringBuilder.append(StringBuilder.java:174) ~[na:na]
at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.lambda$defaultWithAnonymous$2(AnonymousAuthenticationFilter.java:125) ~[spring-security-web-5.8.0-SNAPSHOT.jar:5.8.0-SNAPSHOT]
at org.springframework.core.log.LogMessage$SupplierMessage.buildString(LogMessage.java:155) ~[spring-core-5.3.12.jar:5.3.12]
at org.springframework.core.log.LogMessage.toString(LogMessage.java:70) ~[spring-core-5.3.12.jar:5.3.12]
at java.base/java.lang.String.valueOf(String.java:2951) ~[na:na]
at org.apache.commons.logging.LogAdapter$Slf4jLocationAwareLog.trace(LogAdapter.java:482) ~[spring-jcl-5.3.12.jar:5.3.12]
at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.defaultWithAnonymous(AnonymousAuthenticationFilter.java:125) ~[spring-security-web-5.8.0-SNAPSHOT.jar:5.8.0-SNAPSHOT]
at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.lambda$defaultWithAnonymous$0(AnonymousAuthenticationFilter.java:105) ~[spring-security-web-5.8.0-SNAPSHOT.jar:5.8.0-SNAPSHOT]
at org.springframework.security.core.context.ThreadLocalSecurityContextHolderStrategy.lambda$setDeferredContext$2(ThreadLocalSecurityContextHolderStrategy.java:67) ~[spring-security-core-5.8.0-SNAPSHOT.jar:5.8.0-SNAPSHOT]
at org.springframework.security.core.context.ThreadLocalSecurityContextHolderStrategy.getContext(ThreadLocalSecurityContextHolderStrategy.java:43) ~[spring-security-core-5.8.0-SNAPSHOT.jar:5.8.0-SNAPSHOT]
at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.lambda$defaultWithAnonymous$2(AnonymousAuthenticationFilter.java:126) ~[spring-security-web-5.8.0-SNAPSHOT.jar:5.8.0-SNAPSHOT]
at org.springframework.core.log.LogMessage$SupplierMessage.buildString(LogMessage.java:155) ~[spring-core-5.3.12.jar:5.3.12]
at org.springframework.core.log.LogMessage.toString(LogMessage.java:70) ~[spring-core-5.3.12.jar:5.3.12]
at java.base/java.lang.String.valueOf(String.java:2951) ~[na:na]
at org.apache.commons.logging.LogAdapter$Slf4jLocationAwareLog.trace(LogAdapter.java:482) ~[spring-jcl-5.3.12.jar:5.3.12]
at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.defaultWithAnonymous(AnonymousAuthenticationFilter.java:125)
Issue gh-11457
Currently if trace logging is enabled a StackOverflowException is thrown
when trying to resolve toString of the authentication.
java.lang.StackOverflowError: null
at java.base/java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:538) ~[na:na]
at java.base/java.lang.StringBuilder.append(StringBuilder.java:174) ~[na:na]
at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.lambda$defaultWithAnonymous$2(AnonymousAuthenticationFilter.java:125) ~[spring-security-web-5.8.0-SNAPSHOT.jar:5.8.0-SNAPSHOT]
at org.springframework.core.log.LogMessage$SupplierMessage.buildString(LogMessage.java:155) ~[spring-core-5.3.12.jar:5.3.12]
at org.springframework.core.log.LogMessage.toString(LogMessage.java:70) ~[spring-core-5.3.12.jar:5.3.12]
at java.base/java.lang.String.valueOf(String.java:2951) ~[na:na]
at org.apache.commons.logging.LogAdapter$Slf4jLocationAwareLog.trace(LogAdapter.java:482) ~[spring-jcl-5.3.12.jar:5.3.12]
at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.defaultWithAnonymous(AnonymousAuthenticationFilter.java:125) ~[spring-security-web-5.8.0-SNAPSHOT.jar:5.8.0-SNAPSHOT]
at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.lambda$defaultWithAnonymous$0(AnonymousAuthenticationFilter.java:105) ~[spring-security-web-5.8.0-SNAPSHOT.jar:5.8.0-SNAPSHOT]
at org.springframework.security.core.context.ThreadLocalSecurityContextHolderStrategy.lambda$setDeferredContext$2(ThreadLocalSecurityContextHolderStrategy.java:67) ~[spring-security-core-5.8.0-SNAPSHOT.jar:5.8.0-SNAPSHOT]
at org.springframework.security.core.context.ThreadLocalSecurityContextHolderStrategy.getContext(ThreadLocalSecurityContextHolderStrategy.java:43) ~[spring-security-core-5.8.0-SNAPSHOT.jar:5.8.0-SNAPSHOT]
at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.lambda$defaultWithAnonymous$2(AnonymousAuthenticationFilter.java:126) ~[spring-security-web-5.8.0-SNAPSHOT.jar:5.8.0-SNAPSHOT]
at org.springframework.core.log.LogMessage$SupplierMessage.buildString(LogMessage.java:155) ~[spring-core-5.3.12.jar:5.3.12]
at org.springframework.core.log.LogMessage.toString(LogMessage.java:70) ~[spring-core-5.3.12.jar:5.3.12]
at java.base/java.lang.String.valueOf(String.java:2951) ~[na:na]
at org.apache.commons.logging.LogAdapter$Slf4jLocationAwareLog.trace(LogAdapter.java:482) ~[spring-jcl-5.3.12.jar:5.3.12]
at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.defaultWithAnonymous(AnonymousAuthenticationFilter.java:125)
Issue gh-11457
Previously AnonymousAuthenticationFilter accessed the SecurityContext to
determine if anonymous authentication needed setup eagerly. Now this is done
lazily to avoid unnecessary access to the SecurityContext which in turn avoids
unnecessary HTTP Session access.
Closes gh-11457
Previously AnonymousAuthenticationFilter accessed the SecurityContext to
determine if anonymous authentication needed setup eagerly. Now this is done
lazily to avoid unnecessary access to the SecurityContext which in turn avoids
unnecessary HTTP Session access.
Closes gh-11457
When MultipartFormData is enabled currently the CsrfWebFilter compares
the content-type header against MULTIPART_FORM_DATA MediaType which
leads to NullPointerExecption when there is no content-type header.
This commit reverse the check to compare the MULTIPART_FORM_DATA
MediaType against the content-type which contains null check and avoids
the exception.
closes gh-11204
Closes gh-11205
When MultipartFormData is enabled currently the CsrfWebFilter compares
the content-type header against MULTIPART_FORM_DATA MediaType which
leads to NullPointerExecption when there is no content-type header.
This commit reverse the check to compare the MULTIPART_FORM_DATA
MediaType against the content-type which contains null check and avoids
the exception.
closes gh-11204
Closes gh-11205
When MultipartFormData is enabled currently the CsrfWebFilter compares
the content-type header against MULTIPART_FORM_DATA MediaType which
leads to NullPointerExecption when there is no content-type header.
This commit reverse the check to compare the MULTIPART_FORM_DATA
MediaType against the content-type which contains null check and avoids
the exception.
closes gh-11204
Closes gh-11205
When MultipartFormData is enabled currently the CsrfWebFilter compares
the content-type header against MULTIPART_FORM_DATA MediaType which
leads to NullPointerExecption when there is no content-type header.
This commit reverse the check to compare the MULTIPART_FORM_DATA
MediaType against the content-type which contains null check and avoids
the exception.
closes gh-11204
- Added createEvaluationContext method that accepts Supplier<Authentication>
- Refactored classes that use EvaluationContext to use lazy initialization of Authentication
Closes gh-9667
- Added createEvaluationContext method that accepts Supplier<Authentication>
- Refactored classes that use EvaluationContext to use lazy initialization of Authentication
Closes gh-9667
Servlet Spring Security has DelegatingRequestMatcherHeaderWriter
the reactive world of Spring Security was missing a class to
conditionally write headers.
Closes gh-11073
Servlet Spring Security has DelegatingRequestMatcherHeaderWriter
the reactive world of Spring Security was missing a class to
conditionally write headers.
Closes gh-11073
- Added spring-security-config support
- Renamed classes
- Changed contracts to include the authenticated user and secured
object
- Added method security support
Issue gh-9288
- Added spring-security-config support
- Renamed classes
- Changed contracts to include the authenticated user and secured
object
- Added method security support
Issue gh-9288
This allows loading the SecurityContext lazily, without the need for the
response, and does not attempt to automatically save the request when
the response is comitted.
Closes gh-11028
This allows loading the SecurityContext lazily, without the need for the
response, and does not attempt to automatically save the request when
the response is comitted.
Closes gh-11028
- unauthenticated factory method
- authenticated factory method
- test for unauthenticated factory method
- test for authenticated factory method
- make existing constructor protected
- use newly factory methods in rest of the project
- update copyright dates
Closes gh-10790
- unauthenticated factory method
- authenticated factory method
- test for unauthenticated factory method
- test for authenticated factory method
- make existing constructor protected
- use newly factory methods in rest of the project
- update copyright dates
Closes gh-10790
Previously, the HttpSessionSecurityContextRepository unnecessarily required
the HttpServletResponse from the HttpReqeustResponseHolder passed into
loadContext. This meant code that wanted to save a SecurityContext had to
have a reference to the original HttpRequestResponseHolder. Often that
implied that the code that saves the SecurityContext must also load the
SecurityContext.
This change allows any request / response to be used to save the
SecurityContext which means any code can save the SecurityContext not just
the code that loaded it. This sets up the code to be permit requiring
explicit saves. Using the request/response from the
HttpRequestResponseHolder is only necessary for implicit saves.
Closes gh-10947
Previously, the HttpSessionSecurityContextRepository unnecessarily required
the HttpServletResponse from the HttpReqeustResponseHolder passed into
loadContext. This meant code that wanted to save a SecurityContext had to
have a reference to the original HttpRequestResponseHolder. Often that
implied that the code that saves the SecurityContext must also load the
SecurityContext.
This change allows any request / response to be used to save the
SecurityContext which means any code can save the SecurityContext not just
the code that loaded it. This sets up the code to be permit requiring
explicit saves. Using the request/response from the
HttpRequestResponseHolder is only necessary for implicit saves.
Closes gh-10947
When either `web.ignoring().mvcMatchers(...)` or
`web.ignoring().antMatchers(...)` methods are used, for all their
variations, the DefaultSecurityFilterChain class now indicates
correctly through its ouput what paths are ignored according the
`ignoring()` settings.
Closes gh-9334
When either `web.ignoring().mvcMatchers(...)` or
`web.ignoring().antMatchers(...)` methods are used, for all their
variations, the DefaultSecurityFilterChain class now indicates
correctly through its ouput what paths are ignored according the
`ignoring()` settings.
Closes gh-9334
When either `web.ignoring().mvcMatchers(...)` or
`web.ignoring().antMatchers(...)` methods are used, for all their
variations, the DefaultSecurityFilterChain class now indicates
correctly through its ouput what paths are ignored according the
`ignoring()` settings.
Closes gh-9334
When either `web.ignoring().mvcMatchers(...)` or
`web.ignoring().antMatchers(...)` methods are used, for all their
variations, the DefaultSecurityFilterChain class now indicates
correctly through its ouput what paths are ignored according the
`ignoring()` settings.
Closes gh-9334
Josh Cummings
Steve Riesenberg
Daniel Garnier-Moiroux
Marcus Da Coregio
Rob Winch
Daniel Garnier-Moiroux
shazin
Bert Vanwolleghem
shinD
cyb3r4nt
Joe Grandja
Alonso Araya Calvo
j3graham
Zhivko Delchev
Evgeniy Cheban
David Herberth
Eleftheria Stein
Parikshit Dutta
David Kirstein
Norbert Nowak
Yuriy Savchenko
Manuel Jordan
Juan Carlos
Adam Ostrožlík
heowc