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
Origin should include scheme according to RFC #379
Comments
Sorry for slow reply Yes you're right, the whole origin should be checked including scheme. #259 basically reported this too, but at that time I wasn't aware it's in the spec. We should fix this, if you have plans for a PR that sounds great. Deprecating origins without scheme or port sounds like a fine idea to me. I'd just like to do as browsers do and not need ports if they're the defaults for the scheme (e.g. If you have time for a PR please get started. Don't forget to update the documentation and HISTORY. |
I'll look into it. |
#388 was merged and #397 improved it. Fix released in version 3.0.0: https://pypi.org/project/django-cors-headers/3.0.0/ Thanks for doing the PR @wgonczaronek ! |
The
CORS_ORIGIN_WHITELIST
should include scheme according to RFC 6454:Current implementation only checks
netloc
part, whereas it should check against scheme, host and port. This RFC is used as reference in W3 recommendations so I think it would be useful to comply to it. I would like to limit access to origins usinghttps
protocol.EDIT I was thinking about implementing such a feature in a way that would allow user define origin with or without scheme, optionally with deprecation warning if it's defined without scheme. Tell me what you think.
The text was updated successfully, but these errors were encountered: