CORS Options request forbidden with Webflux [SPR-15704]

[spring-projects-issues]

Guillaume DROUET opened SPR-15704 and commented

This issue has been reproduced with a spring boot application 2.0.0.M2
This is not reproduced with M1.
Please find an example in attachment. A RouterFunction handles an options request to allow CORS. In the unit test, you can see that when a request is sent, a 403 is returned. It seems that the response is inspected by cors processor before the handler has been invoked.

---

Affects: 5.0 RC2

Attachments:

• cors.zip (49.75 kB)

Issue Links:

• Add CORS support for functional style routes for WebFlux [SPR-15567] #20126 Add CORS support for functional style routes for WebFlux
• Revisit DispatcherHandler integration for RouterFunctions [SPR-15536] #20095 Revisit DispatcherHandler integration for RouterFunctions

[spring-projects-issues]

Sébastien Deleuze commented

This behavior is expected since as of this commit the functional router leverages @EnableWebFlux infrastructure which provides built-in CORS support with no CORS mapping enabled by default. CORS support is complex to implement, so we clearly recommend leveraging Spring CORS support to handle this kind of requests.

Spring Framework 5 RC2 already provides a way to configure such CORS support via @EnableWebFlux + overriding WebFluxConfigurer#addCorsMappings.

As part of the upcoming Spring Framework 5 RC3, I initially added via #20126 a CorsWebFilter which allows to configure such support via a filter more flexible with security frameworks for example.

After a deeper look, I think that would also makes sense to add a cors(CorsConfigurationSource source) to HandlerStrategies.Builder in order to allow to configure AbstractHandlerMapping CORS support without application context + annotations. That's why I have reopened #20126 to add such support.

For super advanced use cases you could also disable CORS support by providing a no-op CorsProcessor by this is in practice almost never needed.

Does that make sense to you?

[spring-projects-issues]

Guillaume DROUET commented

+1, I was expecting such answer, there is no reason to ignore dedicated features that help to manage CORS and it's fine if those features disallow user to declare a route that matches a preflight CORS request. However do you confirm that it's still possible to achieve this with a custom, no-op, CorsProcessor?

[spring-projects-issues]

Sébastien Deleuze commented

Yes, as discussed in #18266 and #18621 providing a no-op CorsProcessor will allow you to set your custom headers even if I don't recommand that at all (CORS headers need also to be set on the actual request that come after the pre-flight request).

[spring-projects-issues]

Guillaume DROUET commented

Yes perfect, I agree this is not recommended but at least people can do it if they really want.