Closed jzheaux closed 1 week ago
Hi @jzheaux. This will only work with DefaultSecurityFilterChain
, so I added the necessary check. But one question worries me - how many people used this, thinking that it was not a bug but a feature? And won't they get an unpleasant surprise?
Good question, @CrazyParanoid. Yes, it may be a surprise, though it's an important one since their configuration is broken. When an any-request filter chain comes before another filter chain, that second filter chain is never consulted, perhaps unbeknownst to the developer. Updating to the next minor release will help them fix this configuration bug.
By default, a filter chain's
securityMatcher
defaults to any request:This means that configurations that use multiple default filter chains can get unexpected results. Since technically both chains match any request, the first chain is always picked and the second one is never picked.
Spring Security should help by failing during startup when an application has any filter chain that is defined after an "any request" filter chain. For example, a configuration like this is problematic:
since the first filter chain will always consume any request and the second filter chain will never get exercised.
For clarity, an example fix in the above case could be:
so that neither of them captures every request.
Or a more preferred one would be:
as this one still has an "any request" filter chain that acts as a catch-all and is correctly placed as the last filter chain.
I think this check could be done in
WebSecurity#performBuild
after all theSecurityFilterChain
instances are fully built. Something like this might do the trick: