Allowed methods are used in the following hierarchy:
1) methods parameter of cross_origin decorator
2) methods parameter of view function route
3) resource or app level configuration
This change is not backward compatible, see PR comments for details.
I am not sure this change is always desirable. With this patch, the view level methods always override resource level configuration. If we have a bunch of views supporting POST and GET methods; and have used resource level configuration to restrict the access control method to GET. With this PR, the view methods will expose those views to POST as well.
Allowed methods are used in the following hierarchy: 1) methods parameter of cross_origin decorator 2) methods parameter of view function route 3) resource or app level configuration
I tried to implement this in
set_cors_headersbut couldn't because it is called from both decorator and extension. In the case of the decorator, we do not want to use the methods from view function if the decorator had those specified but in case of extension we want to use it always. https://github.com/corydolphin/flask-cors/blob/24c45cef84a160207057c7c0735fc5fb08143420/flask_cors/core.py#L224This change is not backward compatible, see PR comments for details.
I am not sure this change is always desirable. With this patch, the view level methods always override resource level configuration. If we have a bunch of views supporting POST and GET methods; and have used resource level configuration to restrict the access control method to GET. With this PR, the view methods will expose those views to POST as well.
Input on how to improve this is appreciated.
Fixes #228