Table of contents
question
On the premise that the Spring Security whitelist path is configured, the access is still 401 (unauthorized) or 403 (forbidden). If there is no accident, the whitelist configuration is not effective or the path configuration is wrong.
But most people don't know how to deal with this kind of problem. They only know that they are blocked by the filter. As for which blocking filter, they don't know!
So this article posts the key source code of Spring Security's whitelist path loading and interception verification, and you can debug it yourself if you encounter such problems again.
Because the AbstractSecurityInterceptor used by SpringBoot2 performs path interception verification, but it is replaced by AuthorizationFilter in SpringBoot3, so two versions are distinguished here, just check the number.
SpringBoot 2 + Spring Security Web 5.x
Debug entry : AbstractSecurityInterceptor#beforeInvocation
- AbstractSecurityInterceptor#beforeInvocation Get whitelist configuration before verification
SpringBoot 3 + Spring Security Web 6.x
Debug entry: AuthorizationFilter#doFilter
Full call stack:
PatternsRequestCondition#getMatchingCondition Match whitelist rules according to the request path
AntPathMatcher#doMatch Request path matching whitelist rule specific details logic, including how request path parameters match mapping
