Skip to content

Add Access Control, CORS (Cross Origin Request Sharing) header methods#1699

Merged
davidism merged 2 commits into
pallets:masterfrom
pgjones:access_control
Jan 14, 2020
Merged

Add Access Control, CORS (Cross Origin Request Sharing) header methods#1699
davidism merged 2 commits into
pallets:masterfrom
pgjones:access_control

Conversation

@pgjones
Copy link
Copy Markdown
Member

@pgjones pgjones commented Jan 11, 2020

This should make it a little easier to get and set access control headers as it ensures the types and naming is correct. It is also intentionally very minimal like the other header accessors.

closes #131

@pgjones pgjones mentioned this pull request Jan 11, 2020
Comment thread src/werkzeug/wrappers/cors.py Outdated
Comment thread src/werkzeug/wrappers/cors.py Outdated
Comment thread src/werkzeug/wrappers/request.py Outdated
Comment thread tests/test_wrappers.py Outdated
@davidism davidism added this to the 1.0.0 milestone Jan 12, 2020
Comment thread src/werkzeug/wrappers/cors.py Outdated
@davidism
Copy link
Copy Markdown
Member

Similar to the CSP implementation, I'm wondering if we should have a single access_control property that returns an AccessControl object instead. Or maybe we need some sort of equivalent to EtagMixin.make_conditional that adjusts the response based on the request, since that's where the complexity lies.

I checked out Flask-CORS, somewhat discouraging to see that they're using str.split instead of the Werkzeug header parsing utilities already. While I'm fine with adding the header properties, I'm not sure how useful on its own that will be.

@pgjones
Copy link
Copy Markdown
Member Author

pgjones commented Jan 14, 2020

I went for a single access_control property and object in Quart, however I don't think it is the right decision as it isn't consistent with how I think Werkzeug works (headers are only combined within a wrapper object, including CSP which is a single header) and the AccessControl instance itself isn't very useful on its own (Quart usage is always [wrapper].access_control.[header]).

The correct header parsing and setting is in itself useful (in my view). Whilst I like something like make_cors, I don't think it fits with Werkzeug. I think make_conditional is possible using the information in the wrappers alone whereas cors needs some application decisions/inputs.

This should make it a little easier to get and set access control
headers as it ensures the types and naming is correct. It is also
intentionally very minimal like the other header accessors.
@davidism davidism merged commit 2b2663b into pallets:master Jan 14, 2020
@pgjones pgjones deleted the access_control branch January 19, 2020 17:28
@github-actions github-actions Bot locked as resolved and limited conversation to collaborators Nov 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support CORS

2 participants