There is a similar problem here: CorsInterceptor should add to the first interceptor in InterceptorChain? · Issue #22459. In this commit: CorsInterceptor at the front of the chain, the order of CorsInterceptor was adjusted to before all interceptors, but the processing logic of PreFlight was not adjusted.
When a PreFlight request is sent to the server, if one of the interceptors in the chain returns false in the preHandle method, then the related CORS headers will not be added, causing the browser to judge cross-domain, even if we explicitly configure allowedOrigins, but in fact there is no cross-domain, but the interceptor abort the chain in advance and the PreFlight logic is not executed.
Expected behavior: CORS related headers are added in the response of the PreFlight request regardless of whether the interceptor abort the chain.
Actual behavior: Browser block CORS request because PreFlight request not responding to 'Access-Control-Allow-Origin' header. Browser console print: Access to XMLHttpRequest at 'https://server.com/users' from origin 'https://www.another.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Added unit test: org.springframework.web.servlet.handler.HandlerMethodMappingTests#abortInterceptorInPreFlightRequestWithCorsConfig
Comment From: tianshuang
@rstoyanchev
Comment From: rstoyanchev
@tianshuang thank you for the pull request. I've adjusted the implementation slightly and also opted to skip the rest of the interceptor chain. Arguably if CORS checks fail, we shouldn't proceed with further processing of any kind. That also aligns better with how actual requests are handled.