[13.x] Add per-route CORS configuration support#59305
Conversation
|
Hmm, one change I might make to this is to potentially make a new middleware in the |
|
Just pushed some changes with a different approach @taylorotwell |
|
I like the idea of this, but in my experience CORS has always been far more complicated than, “allow requests for this one hostname only”. This approach even falls down when you have multiple environments for a single application with their own unique hostnames, so hard-coded hostname (or array of hostnames) in an attribute is not going to cut it. |
Allow CORS options to be defined at the route level via a fluent cors() method, route group option, or #[Cors] attribute, giving fine-grained control over cross-origin policies without modifying the global CORS configuration.
- Narrow preflight lookup catch to routing exceptions - Run preflight option resolution only on preflight requests - Unify preflight detection via CorsService::isPreflightRequest - Drop dead OPTIONS branch and synthetic cors_routes action - Add throttle preflight tests and tighten Allow header assertion
b3fbf09 to
9ce5e1b
Compare
Overview
This PR adds route-specific CORS handling while moving that behavior into dedicated route middleware, so per-route policies can use the already-resolved route instead of matching requests twice.
Approach
webandapigroups so route metadata and controller attributes are resolved from the active route.OPTIONSrequests use the same route-specific policy as the underlying endpoint.Examples
Route-level configuration:
Class-level attribute:
Class method-level attribute: