Spring Security now filters every dispatch by default and not only
once-per-request. Security configuration has been updated in a number of
places to restore the old behavior as needed for the tests to pass.
gh-31703 has been opened to review this and to investigate if we can
now remove the error page security filter and rely on the filtering of
every dispatch instead.
In addition to switching to once-per-request filtering where needed,
this commit also restructures the configuration of the error page
security filter. The restructuring was necessary to ensure that the
privilege evaluator bean has been defined before the conditions on the
error page security filter are evaluated. Without the change, the filter
was no longer being configured as the privilege evaluator hadn't been
defined before the on bean condition was evaluated. We may want to back
port this change as the ordering doesn't appear to have been defined
before and we were just getting lucky.
See gh-31622
See spring-projects/spring-security#11466
Prior to this commit, the `ErrorPageSecurityFilter` verified if
access to the error page was allowed by invoking the
`WebInvocationPrivilegeEvaluator` with the Authentication from the
`SecurityContextHolder`.
This meant that access to the error page was denied for a `null` Authentication
or `AnonymousAuthenticationToken` in cases where the error page required
authenticated access. This prevented authorized users from accessing the
error page in case the Authentication wasn't retrievable for the error dispatch,
which is the case for `@Transient` authentication or stateless session policy.
This commit updates the `ErrorPageSecurityFilter` to check access to the error page
only if the error is an authn or authz error in cases where an authentication object
is not found in the SecurityContextHolder. This makes the error response consistent
when bad credentials or no credentials are used while also allowing access to previously
authorized users.
Fixes gh-28953
Update `build.gradle` files to ensure that `junit-platform-launcher` is
a `testRuntimeOnly` dependency. This ensures that tests can be run from
Eclipse.
Closes gh-25074
Replace `WebSecurityConfigurer` and `WebSecurityConfigurerAdapter`
configurations with `WebSecurityCustomizer` or `SecurityFilterChain`
beans.
Closes gh-23421
Previously, the base path of a servlet-based management server could be
configured using management.server.servlet.context-path but there was no
equivalent property for WebFlux.
This commit introduces a new property, management.server.base-path,
that can be used with both servlet and reactive management servers. The
existing servlet-specific property has been deprecated in favour of the
new general property. When using the servlet stack, if both the general
property and the servlet-specific property are set, the new general
property takes precedence. When using the reactive stack, only the new
general property is considered.
Closes gh-22906
Prior to this commit, there was a property server.error.include-details
that allowed configuration of the message and errors attributes in a
server error response.
This commit separates the control of the message and errors attributes
into two separate properties named server.error.include-message and
server.error.include-binding-errors. When the message attribute is
excluded from a servlet response, the value is changed from a
hard-coded text value to an empty value.
Fixes gh-20505
Prior to this commit, default error responses included the message
from a handled exception. When the exception was a BindException, the
error responses could also include an errors attribute containing the
details of the binding failure. These details could leak information
about the application.
This commit removes the exception message and binding errors detail
from error responses by default, and introduces a
`server.error.include-details` property that can be used to cause
these details to be included in the response.
Fixes gh-20505
Update all dependencies declarations to use the form `scope(reference)`
rather than `scope reference`.
Prior to this commit we declared dependencies without parentheses unless
we were forced to add them due to an `exclude`.
Replace Gradle single quote strings with the double quote form
whenever possible. The change helps to being consistency to the
dependencies section where mostly single quotes were used, but
occasionally double quotes were required due to `${}` references.