Hey,
I also came across this "issue" which I believe will become very common as
architectures as the one described above are starting to be more common.
Moreover, IMHO the overall way that Django handles CORS issues is
sub-optimal... another issue that I keep bumping against is having multiple
"Access-Control-Allow-Origin".
For the case described in this thread, I ended up adding the following code
bellow to the "dispatch" of my custom API View that all API Handlers
extend, before and after CSRF validation to ensure that, when CRSF checking
is happening, things are as Django expects so that it doesn't break as you
described.
@staticmethod
def _https_referer_replace(request):
"""
When https is enabled, django CSRF checking includes referer checking
which breaks when using CORS. This function updates the HTTP_REFERER
header to make sure it matches HTTP_HOST, provided that our cors logic
succeeds.
Based on snippet taken from:
https://github.com/ottoyiu/django-cors-headers/blob/master/corsheaders/middleware.py
"""
if settings.YAPI.get('XS_SHARING_REPLACE_HTTPS_REFERER') is True:
origin = request.META.get('HTTP_ORIGIN')
allowed_origins = settings.YAPI['XS_SHARING_ALLOWED_ORIGINS']
if request.is_secure() and origin and 'ORIGINAL_HTTP_REFERER' not in
request.META:
if allowed_origins != '*' and origin not in allowed_origins:
return
try:
http_referer = request.META['HTTP_REFERER']
http_host = "https://%s/"; % request.META['HTTP_HOST']
request.META = request.META.copy()
request.META['ORIGINAL_HTTP_REFERER'] = http_referer
request.META['HTTP_REFERER'] = http_host
except KeyError:
pass
@staticmethod
def _https_referer_replace_reverse(request):
"""
Put the HTTP_REFERER back to its original value and delete the temporary
storage.
Based on snippet taken from:
https://github.com/ottoyiu/django-cors-headers/blob/master/corsheaders/middleware.py
"""
if settings.YAPI.get('XS_SHARING_REPLACE_HTTPS_REFERER') is True and
'ORIGINAL_HTTP_REFERER' in request.META:
http_referer = request.META['ORIGINAL_HTTP_REFERER']
request.META['HTTP_REFERER'] = http_referer
del request.META['ORIGINAL_HTTP_REFERER']
On Friday, 29 May 2015 06:33:12 UTC+1, Troy Grosfield wrote:
>
> Don't want to do csrf_exempt because I need csrf protection since I'm
> posting data to the api. This works in cases where the site isn't secure
> (https), but once the code is moved to prod (secure site) it fails.
>
>
> On Thursday, May 28, 2015 at 11:09:04 PM UTC-6, Josh Smeaton wrote:
>>
>> Forgive me, but wouldn't you just declare those views as csrf_exempt? A
>> csrf token at one site isn't going to be valid at another, right?
>>
>> On Friday, 29 May 2015 13:44:42 UTC+10, Troy Grosfield wrote:
>>>
>>> I have the following domain and subdomains both are trusted and both are
>>> secure (https):
>>>
>>> - https://example.com
>>> - https://api.example.com
>>>
>>> When making POST ajax request from *https://example.com
>>> <https://example.com>* to *https://api.example.com
>>> <https://api.example.com>* I see the following error message:
>>>
>>>
>>> 1. detail: "CSRF Failed: Referer checking failed -
>>> https://example.com/path/to/some/url does not match
>>> https://api.example.com/.";
>>>
>>>
>>> Which takes me to the *CsrfViewMiddleware* where I see *same_origin*
>>> checking:
>>>
>>> # Note that request.get_host() includes the port.
>>> good_referer = 'https://%s/' % request.get_host()
>>> if not same_origin(referer, good_referer):
>>> reason = REASON_BAD_REFERER % (referer, good_referer)
>>> return self._reject(request, reason)
>>>
>>> I trust my subdomain, but there's no way for this code to actually pass
>>> this validation. Am I just missing something? Why would trusted
>>> subdomains fail validation here? Can't this at least be a setting
>>> something like *TRUSTED_SUBDOMAINS* that's also checked?
>>>
>>> The other option I see here it to override the *CsrfViewMiddleware's*
>>> *process_view* method as others have done
>>> <http://bash-shell.net/blog/2014/aug/16/django-cors-and-csrf-validation/>.
>>> However, it ends up being a rather extensive rewrite for only the few
>>> lines, that are mentioned above, that need to change. Can we rewrite the
>>> *CsrfViewMiddleware
>>> *to be more modular so it's easy to subclass and overwrite pieces of
>>> the csrf vallidation? Something along the lines of:
>>>
>>> class CsrfViewMiddleware(object):
>>>
>>> def process_view(self, request, callback, callback_args,
>>> callback_kwargs):
>>>
>>> [...]
>>>
>>> # Assume that anything not defined as 'safe' by RFC2616 needs
>>> protection
>>> if request.method not in ('GET', 'HEAD', 'OPTIONS', 'TRACE'):
>>> [...]
>>> if request.is_secure():
>>> [...]
>>>
>>> # Note that request.get_host() includes the port.
>>> good_referer = 'https://%s/' % request.get_host()
>>> if not self.is_same_origin(referer, good_referer):
>>> reason = REASON_BAD_REFERER % (referer, good_referer)
>>> return self._reject(request, reason)
>>>
>>> [...]
>>> return self._accept(request)
>>>
>>> def is_same_origin(self, referer, good_referer):
>>> return same_origin(referer, good_referer):
>>>
>>>
>>> This at least gives the ability to override the *is_same_origin*
>>> method which would allow us to also check for legit subdomains (in this
>>> case https://api.example.com).
>>>
>>> Thoughts?
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/2eb6f8a1-841e-4360-b124-81a5a6bcf21f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
