Open willnewton opened 2 years ago
Hi @willnewton! And thanks for this interesting proposal.
I've added the needs-decision
label since in general I think we want to keep the CORS functionality pretty simple and basic; maybe this would make more sense as part of a specialized add-on such as falcon-cors?
As a workaround, you can also set the Access-Control-Allow-Origin
header to a custom value where it needs to deviate from the default list of domains. If you set the header in your responder, hook or middleware that runs before CORSMiddleware
's process_response()
method, CORSMiddleware
won't interfere with it.
A suggestion for this was posted in https://github.com/falconry/falcon/pull/2052#issuecomment-1224129740 :
Maybe a better course of action could be breaking out that validation part to a public method of CORSMiddleware, and document an example how to subclass and override that? This is how some other parts of Falcon like media handlers are implemented too.
The async flavour could by default call the synchronous version directly, but it should be possible to do perform origin validation asynchronously too. Passing in a callable makes this somewhat trickier, or should we detect a coroutine function and act accordingly? Or just document it must be a sync function like in field converters?
In some cases it is useful to allow a dynamic list of CORS origin domains, for example a wild carded list of subdomains. A feature that is available in some other CORS middleware is to allow a function to be passed in to do this. For example:
https://expressjs.com/en/resources/middleware/cors.html#configuring-cors-w-dynamic-origin
One way to implement this might be to pass a function for allow_origin to the middleware which can be called in process_response.