Description
Spring Security requires authorization for every request and every dispatch type by default. This is by design, but it complicates developer's lives. Authorization for error handling does not behave correctly in all scenarios.
With Spring Boot 3.4.2, a request of http '/foo;bar/' will cause the firewall to reject the request. After the request is rejected, it is handled by error dispatcher. Unless explicitly allowed, Spring Security will deny access to the error dispatch and the original error will not be displayed. This is all expected, but it makes it difficult for developers to figure out. We should ensure that we perform logging to help the developer figure out what is happening.
Another issue is that even if the request is authenticated http ':8080/foo;bar/' -a user:password and that users should be authorized, it does not grant access to the error page. The problem here is likely two fold. The first is that the SecurityContextHolderFilter has a new attribute that disables it for additional dispatch types. This means that if it was invoked on the request, in the error dispatch it won't be invoked again. The other issue is that basic authentication will never be invoked on error dispatch even if basic authentication was not invoked in the request dispatch. Since the firewall rejects the request before basic authentication happens, it cannot authenticate the request in the request dispatch. Likely for this scenario, basic authentication should happen on the error dispatch (we do not want to process any of the request dispatch since the firewall rejected it and doing anything with that request could lead to security bypasses).