-
Notifications
You must be signed in to change notification settings - Fork 5.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make it easier to determine where a filter chain has been defined #15874
Comments
Thanks for reporting this Andy. I'll bring this to the team's attention. |
Thanks for the feedback @wilkinsona. Other than specifying the origin (e.g. Bean name) is there anything else you can think of that could help improve/expedite the troubleshooting of multiple "any request" filter chain issue? |
If you created a specific exception type for it, Boot could provide a The only other thing that I can think of is to perhaps reconsider including all of the fully-qualified filter class names in the exception message. They're quite far removed from the DSL that was likely used to configure them which makes me wonder how helpful they are. Perhaps a short description of each could be provided instead? For example, |
Thanks @wilkinsona. Great information. We'll look at these different options and provide an improvement. |
Expected Behavior
When there a multiple filter chains configured for any request, Spring Security should make it as easy as possible for the user to correct their configuration mistake by clearly identifying the filter chains that are involved.
Current Behavior
An app fails to start with an exception like this:
For me, describing a filter chain purely in terms of the filters that it contains isn't as helpful as it could be. Thanks to the DSL, the specific filters and their class names are an implementation detail. I find it difficult to map the list of 10+ filters back to a particular piece of configuration where the problematic filter chain was defined and I'd like Spring Security to do that for me. Perhaps it could provide some origin information (the name of the bean?) where each filter chain that's involved in the problem was defined?
Context
I found this while trying to adapt to the deprecation of
OAuth2AuthorizationServerConfiguration.applyDefaultSecurity(http)
in the AOT smoke test for authorization server:The above was my first attempt at following the advice in the deprecation notice. After looking at the code that was deprecated and what it does, it would appear that the following is what was needed in this case:
The text was updated successfully, but these errors were encountered: