In Spring Security 5 with multiple HttpSecurity instances the first instance to match the request handles the request, in Spring Security 6 the last HttpSecurity instance to match the request handles it (or more precisely, overrides decision on how to handle it). This, among other things, prevents creation of a default case for handling - a fallback for undeclared endpoints.
To Reproduce Run example configuration from https://docs.spring.io/spring-security/reference/5.8/servlet/configuration/java.html#_multiple_httpsecurity Compare with analogous configuration from (current version, 6.1.2): https://docs.spring.io/spring-security/reference/servlet/configuration/java.html#_multiple_httpsecurity_instances Request from browser on /api for the first will produce basic auth request, same request for second will produce form login.
Expected behavior As per example, a request on /api will always be handled only by apiFilterChain and produce basic auth request.
Sample https://github.com/zhostasa/MultiHttpSecurityConfigDemo
Sample configurations are lifted directly from examples mentioned in reproduction steps.
Comment From: rwinch
The link to the sample is broken. Can you please fix that?
Comment From: zhostasa
The repo was private, mea culpa. I did not even know github allowed that.
Comment From: zhostasa
For any unfortunate soul that got here while trying to figure it out: My solution was to create default HttpSecurity instance, expose a list of matchers from all the other configurations and use NegatingRequestMatcher and OrRequestMatcher to match anything that is not caught by the other instances. This solution is not intended behavior, I think, but I actually like it, since the default behavior is specified and separate.
Comment From: sjohnr
I'm reviewing a few older issues @zhostasa. There are no tests in your sample that assert the expected behavior, and so I'm not sure what is expected to happen in the sample but I'm unable to reproduce the described issue on the latest version. I'm going to close this issue.