Open Chris2048 opened 6 years ago
Hey Chris,
Thanks for opening an issue!
I don't totally understand your question, or what you are trying to solve.
By default, Flask-Cors allows all methods, intending to leave it up to the user to remove methods they don't want. Is there a use case you have that isn't handled?
Thanks, Cory
Hi Corey, no prob :-)
Well, In my flask route map the supported method are explicitly defined - often b/c they are derived from a resource object that defines these methods.
I'd like to reuse this information (found in the route map) to determine what methods are allowed.
Regards.
We're running into the same issue with the same use case.
It would be really nice if flask-cors uses the information which methods a view actually allows instead of using ALL_METHODS because listing all methods may confuse API consumers which methods can actually be used. This information is available in Flask from url_adapter.allowed_methods()
.
Limiting the list manually on a global level is not accurate because the values can be different per endpoint.
There is the option to configure flask-cors per view, but this is not ideal because it would define the same thing twice.
@corydolphin We want to use Flask-CORS in our app and this feature is useful to us as well. I am interested in submitting a PR for this enhancement. What should be the semantics for this feature w.r.t to the existing mechanisms ? For example: if the cross_origin
decorator is used with methods
, should the cross_origin decorator's methods
take precedence over the ones specified in flask route. There's also the case of CORS_HEADERS
config variable.
IMO, the flask route should take precedence always (well, I am biased because this is how we want to use this :p). But this is probably a breaking change and may not be what others want. Please let me know your thoughts.
Ahh, I understand now. Agreed, this would be an enhancement!
I agree, I think I would expect:
I’d happily accept a PR to improve this. Thank you all for taking the time to provide the detailed issue and suggestion!
@corydolphin Hi! Apologies I was busy elsewhere earlier and only remembered about this recently. I have opened a PR for this issue now.
When a OPTIONS call is made, flask is able to (presumably by looking in the route map) return a list of supported methods, as such:
However, is it possible to use this same function to return the '' header for other method-responces (e.g the response of a GET call) rather than explicitly supply them.
Looking at the decorator in here: https://github.com/flask-restful/flask-restful/blob/master/flask_restful/utils/cors.py
There is a function that is used when allowed methods aren't supplied:
which uses the information of supported methods from 'make_default_options_response' even for non-OPTION calls.