Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is it possible to get Allowed methods from Flask? #228

Open
Chris2048 opened this issue Jun 22, 2018 · 6 comments · May be fixed by #303
Open

Is it possible to get Allowed methods from Flask? #228

Chris2048 opened this issue Jun 22, 2018 · 6 comments · May be fixed by #303

Comments

@Chris2048
Copy link

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
Copy link
Owner

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
Copy link
Author

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
Copy link

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
Copy link

amCap1712 commented Sep 9, 2021

@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
Copy link
Owner

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 amCap1712 linked a pull request Jan 1, 2022 that will close this issue
@amCap1712
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants