Is it possible to get Allowed methods from Flask?

[Chris2048]

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:

if options.get('automatic_options') and request.method == 'OPTIONS':
            resp = current_app.make_default_options_response()

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:

def get_methods():
    if methods is not None:
        return methods

    options_resp = current_app.make_default_options_response()
    return options_resp.headers['allow']

...

h['Access-Control-Allow-Methods'] = get_methods()

which uses the information of supported methods from 'make_default_options_response' even for non-OPTION calls.

[corydolphin]

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

[Chris2048]

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.

[blaise-io]

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.

[amCap1712]

@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.

[corydolphin]

Ahh, I understand now. Agreed, this would be an enhancement!

I agree, I think I would expect:

1. decorator
2. View/route definition
3. App level config.

I’d happily accept a PR to improve this. Thank you all for taking the time to provide the detailed issue and suggestion!

[amCap1712]

@corydolphin Hi! Apologies I was busy elsewhere earlier and only remembered about this recently. I have opened a PR for this issue now.