adamchainz / django-cors-headers Goto Github PK

I have been experimenting with different settings and don't think there's a solution a good solution for the following scenario (other than modifying headers in the view method):

I have a resource on /api that can be accessed from anywhere:

CORS_ORIGIN_ALLOW_ALL = True
CORS_URLS_REGEX = r'^/api/.*$'

All works fine w/ that. Now I want to access a resource on /priv-api. Using these settings it works:

CORS_ORIGIN_WHITELIST = (
    'sub.domain.com'
)
CORS_ALLOW_CREDENTIALS = True

My problem comes when I try to combine them. I don't want to ALLOW_ALL to /priv-api. Perhaps a CORS_URLS_WHITELIST would satisfy my requirement?

I'm trying to add Access-Control-Allow-Origin: * to the response header, and can't seem to accomplish it. I've added installed django-cors-headers with pip, and I have the following in settings.py:

INSTALLED_APPS = (
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'myapp',
    'rest_framework',
    'corsheaders',
)

MIDDLEWARE_CLASSES = (
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
    'corsheaders.middleware.CorsMiddleware',
    'django.middleware.common.CommonMiddleware',
)

CORS_ORIGIN_ALLOW_ALL = False

CORS_ORIGIN_WHITELIST = (
    'localhost',
    'myhost.com'
)

CORS_ALLOW_HEADERS = (
    'x-requested-with',
    'content-type',
    'accept',
    'accept-encoding',
    'origin',
    'authorization',
    'x-csrftoken'
)
CORS_EXPOSE_HEADERS = (
    'Access-Control-Allow-Origin: *',
)

I'm using Django 1.7.1, DRF 3.0.2, Python 3.4. It's quite possible that I just don't understand what your library is supposed to do. I appreciate any help.

Could you make new release (with Django 1.8 support)?

It works offline but when I try to use it onsite, the miserables occur:

no middleware process occur and the dispatch method always yell "no method option" for first handshaking. Please fix it soon, thank you!

I developed a server using Django Python framework which will receive a Json from a client writing using ruby rail framework. The server cannot see the Json and so i want use django-cors-headers but I have already host the app (i.e. the server) using Digital Ocean hosting. My question is Is it possible to install django-cors-headers using the pip install django-cors-headers on the server host computer at Digital Ocean using may be PUTTY or Winscp? If yes, pls how do i do it?

The cors field is used to look up whether the origin domain is white-listed. It should have db_index=True

request.META.get('HTTP_AUTHORIZATION') is empty, so can't get token from the http request headers

Using Angular.js to make class to API powered by Django Rest Framework results in an extra "options" call with each request. How to avoid that with a successful setup of Django & frontend server for Angular on same domain/machine?

Please could you provide a wheel package on PyPI alongside the standard package? http://pythonwheels.com/

Thanks :-)

The version that is installed via pip always say version 1.0.0

Hi,

I was wondering whether it works with django server (a server bundled with Djagno). I have turned on settings

CORS_ORIGIN_ALLOW_ALL = True
CORS_ALLOW_CREDENTIALS = True

But I do't see any headers related cors on response

I upgrade to Django 1.7 and this module is not working anymore.

In the first few requests to Django from my web app in another domain, it works just fine. But all of a sudden I get the "No 'Access-Control-Allow-Origin' header is present on the requested resource". And none of following requests are accepted. I could not pinpoint the exact type of request that made it stop working.

It was working fine in Django 1.6.6

Today Django 1.9 is not supported. The main problem is this line https://github.com/ottoyiu/django-cors-headers/blob/1e7bf86310e54cf2520c1b197d4e54bf80004df3/corsheaders/middleware.py#L13 beacause loading is removed.

Hello folks, not sure this is the right place to ask but, here we go:
I have a project composed of a ionic app and a django project with cors-headers configured. In my ionic app, I make a request to a special view in my django project decorated with ensure_csrf_cookie in order to get the csrftoken cookie. When I do this using my local development server, I manage to fetch the cookie. When I send the request to the remote django server (running behind nginx+uwsgi), the django project sets the cookie but it never reaches my ionic app.
I have

CORS_ALLOW_CREDENTIALS = True

in my django settings and also:

CORS_ORIGIN_REGEX_WHITELIST = (
    '^(https?://)?$',
    '^(https?://)?localhost:\d{4}',
    '^(https?://)?192\.168\.\d+\.\d+(:\d{4})?'
)

So, the server should be reachable to the ionic app from the emulator and also should support cookies. Am I missing something? Could there be a bug?

'But who the hell is using 1.3?'

Me 😢

I am using django-cors-headers and I have deployed my application on server, but still I am getting this issue. My current setting for CORS are

INSTALLED_APPS = ['corsheaders']

MIDDLEWARE_CLASSES = ['corsheaders.middleware.CorsMiddleware', 'corsheaders.middleware.CorsPostCsrfMiddleware']

CORS_ORIGIN_ALLOW_ALL = True

CORS_REPLACE_HTTPS_REFERER = True


CORS_ALLOW_HEADERS = (
        'x-requested-with',
        'content-type',
        'accept',
        'origin',
        'authorization',
        'x-csrftoken',
        'accept-encoding'
    )

CORS_ALLOW_METHODS = (
        'GET',
        'POST',
        'PUT',
        'PATCH',
        'DELETE',
        'OPTIONS'
    )

is there anyone who has resolved the following issue

See http://stackoverflow.com/a/27990162/345876

It looks like caching might be broken if the vary header isn't set on ALL requests, even when not concerning cores-enabled urls.

I installed django-cors-headers==1.0.0
I'm hosting just djangorestframework at localhost:8000

The webcode is hosted in localhost

My settings.py is

THIRD_PARTY_APPS = (
'corsheaders',
'bootstrap_admin',
'adminactions',
'rest_framework',
'rest_framework_swagger',
'taggit',
)

Also installed

MIDDLEWARE_CLASSES = (
'corsheaders.middleware.CorsMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'ccDjango.middleware.SetLastVisitMiddleware',
'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
)

CORS_ORIGIN_ALLOW_ALL = True

Anyone else having the same issue?

Django Rest Framework enforces CSRF with SessionAuthentication.
This check happens after django-cors-headers _http_referer_replace_reverse is called.

The result is a:
{"detail":"CSRF Failed: Referer checking failed - http://localhost:8080/ does not match https://remote:5000/."}

How can this be mitigated?

Whatever I do, request.META.get('HTTP_ORIGIN') return None

I changed it for

origin = request.get_host()

and that made it work

create a universal wheel distribution

I have 2 django web apps built with the django rest framework. I did the following in both apps

1. pip install django-cors-headers
2. added "corsheaders" to the end of my installed apps list
3. added it to my middleware just under csrf (though my endpoints are exempt for now)

MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'corsheaders.middleware.CorsMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
)

When I do an ajax http POST from localhost:9000 to localhost:8000 I can watch the terminal and see the endpoint I posted to does return a 201 (successful create on the 8000 web app) but in the chrome dev tools console (where I kicked the ajax request off from) I get the following (run from the 9000 web app).

XMLHttpRequest cannot load http://localhost:8000/object/. Origin http://localhost:9000 is not allowed by Access-Control-Allow-Origin.

When I look at both terminals to see if an OPTION verb was thrown at either web app - it's clear this isn't happening. In fact the only http request that shows up is the HTTP POST (again -returns a 201 and does actually insert the record with the data I sent in the ajax post)

Here is a sample of the ajax method I threw at it (within the chrome dev tools with the port 9000 web app open)

$.ajax({ url: "http://localhost:8000/object/", type: "POST", data: { foo: "bar" }, beforeSend: function ( xhr ) { console.log("x"); } }).done(function ( data ) { console.log("Sample of data:", data); });

I assumed this egg would technically solve this so I'm sure I missed a step :)

Thank you in advance

Django CSRF falls back to not checking HTTP_HOST/HTTP_REFERER when they aren't present so our code should handle that case as well.

We discovered this bug because mac firefox does not set HTTP_REFERER

I'm not sure if this behaviour is triggered by any particular combination or lack of headers being set by django-cors-headers, or if it's a general limitation or CORS, or an implementation bug in both Firefox and Chrome (and possibly others?)

I have installed django-cors-headers and set CORS_ORIGIN_WHITELIST to actual host names (so it's not setting Access-Control-Allow-Origin: *, it's using the actual whitelisted origin.

If I submit a "safe" (non-preflighted) POST request to a URL that returns a 302 redirect, the browser will transparently follow that redirect.

If I trigger a preflighted POST request by changing the content type to something like text/css, or include an additional header like X-Requested-With: XMLHttpRequest, then the browser will not follow the redirect.

Here's my sample code. If you just change the domain names, update the CORS_ORIGIN_WHITELIST setting, and configure the target URL to return a 302 redirect on POST, you should be able to recreate this problem.

test.html:

<!DOCTYPE html>
<html>
    <head>
        <script type="text/javascript" src="http://code.jquery.com/jquery-1.10.2.js"></script>
        <script type="text/javascript">
            $(function() {
                $('#preflighted').submit(function(e) {
                    e.preventDefault();
                    $.ajax({
                        contentType: 'text/css',
                        type: 'POST',
                        url: 'http://xyz.com:8000/test/',
                        // headers: {
                        //  'X-Requested-With': 'XMLHttpRequest'
                        // },
                        success: function(data, textStatus, jqXHR) {
                            console.log('success');
                        }
                    })
                });
                $('#simple').submit(function(e) {
                    e.preventDefault();
                    $.ajax({
                        type: 'POST',
                        url: 'http://xyz.com:8000/test/',
                        success: function(data, textStatus, jqXHR) {
                            console.log('success');
                        }
                    })
                });
            });
        </script>
    </head>
    <body>
        <form id="preflighted" action="http://xyz.com:8000/test/" method="POST">
            <input type="submit" value="Submit preflighted CORS request">
        </form>
        <form id="simple" action="http://xyz.com:8000/test/" method="POST">
            <input type="submit" value="Submit simple CORS request">
        </form>
    </body>
</html>

views.py:

@csrf_exempt
def test(request):
    if request.method == 'POST':
        return HttpResponseRedirect('/test2/')
    return TemplateResponse(request, 'test.html')

Then view your site at localhost:8000, add that to CORS_ORIGIN_WHITELIST, and add a hosts entry for xyz.com to 127.0.0.1.

Firefox with Firebug does a better job than Chrome at reporting the response headers in both cases.

Simple request (browser DOES follow the redirect):

POST /test/ HTTP/1.1
Host: xyz.com:8000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://localhost:8000/test/
Origin: http://localhost:8000
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Content-Length: 0

HTTP/1.0 302 FOUND
Date: Tue, 01 Oct 2013 07:38:02 GMT
Server: WSGIServer/0.1 Python/2.7.5
Access-Control-Allow-Origin: http://localhost:8000
Etag: "d41d8cd98f00b204e9800998ecf8427e"
Content-Type: text/html; charset=utf-8
Location: http://xyz.com:8000/test2/

Preflighted request (browser does NOT follow redirect):

OPTIONS /test/ HTTP/1.1
Host: xyz.com:8000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Origin: http://localhost:8000
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

HTTP/1.0 200 OK
Date: Tue, 01 Oct 2013 07:41:39 GMT
Server: WSGIServer/0.1 Python/2.7.5
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS
Access-Control-Max-Age: 86400
Etag: "d41d8cd98f00b204e9800998ecf8427e"
Access-Control-Allow-Origin: http://localhost:8000
Access-Control-Allow-Headers: x-requested-with, content-type, accept, origin, authorization, x-csrftoken
Content-Type: text/html; charset=utf-8

POST /test/ HTTP/1.1
Host: xyz.com:8000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Content-Type: text/css
Referer: http://localhost:8000/test/
Origin: http://localhost:8000
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Content-Length: 0

HTTP/1.0 302 FOUND
Date: Tue, 01 Oct 2013 07:41:39 GMT
Server: WSGIServer/0.1 Python/2.7.5
Access-Control-Allow-Origin: http://localhost:8000
Etag: "d41d8cd98f00b204e9800998ecf8427e"
Content-Type: text/html; charset=utf-8
Location: http://xyz.com:8000/test2/

Image from origin 'https://{{name}}.amazonaws.com' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://192.168.10.171:9090' is therefore not allowed access.

Is Django-cors-headers solved cross origin issues or not?

Total noob here, but let me describe what I did...

I cloned the repo and installed. Then I opened settings.py of my website and added 'corsheaders' to the INSTALLED_APPS.

I also didn't forget adding 'corsheaders.middleware.CorsMiddleware' to MIDDLEWARE_CLASSES, before the 'django.middleware.common.CommonMiddleware'.

CORS_ORIGIN_ALLOW_ALL = True

... this i added to the end of settings.py. Is that ok?

This is the firebug output of the ajax GET request:

Accept text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Encoding gzip, deflate
Accept-Language sl,en-GB;q=0.7,en;q=0.3
DNT 1
Host example.com:8933
Origin http://example.com
Referer http://example.com/myapp/
User-Agent Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0

In middleware.py line 39, a check is being made for HTTP_ORIGIN and if found the entire CORS headers are being generated. Isnt that deprecated now? Shouldnt we be testing for 'Origin' ?

May I make a suggestion, it seems that the is_enabled function is called many times inside the middleware, running the same regex over and over and over. You could easily save it as a local variable inside your middleware 'self'

https://github.com/ottoyiu/django-cors-headers/blob/master/corsheaders/middleware.py#L151

Running on Django 1.9.x and Python 3.5, it returns the following error when trying to start server or run migrations:

Traceback (most recent call last):
File "manage.py", line 10, in
execute_from_command_line(sys.argv)
File "C:\Users\galeal\AppData\Local\Programs\Python\Python35-32\lib\site-packa
ges\django\core\management__init__.py", line 350, in execute_from_command_line
utility.execute()
File "C:\Users\galeal\AppData\Local\Programs\Python\Python35-32\lib\site-packa
ges\django\core\management__init__.py", line 342, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "C:\Users\galeal\AppData\Local\Programs\Python\Python35-32\lib\site-packa
ges\django\core\management\base.py", line 348, in run_from_argv
self.execute(_args, *_cmd_options)
File "C:\Users\galeal\AppData\Local\Programs\Python\Python35-32\lib\site-packa
ges\django\core\management\base.py", line 398, in execute
self.check()
File "C:\Users\galeal\AppData\Local\Programs\Python\Python35-32\lib\site-packa
ges\django\core\management\base.py", line 426, in check
include_deployment_checks=include_deployment_checks,
File "C:\Users\galeal\AppData\Local\Programs\Python\Python35-32\lib\site-packa
ges\django\core\checks\registry.py", line 75, in run_checks
new_errors = check(app_configs=app_configs)
File "C:\Users\galeal\AppData\Local\Programs\Python\Python35-32\lib\site-packa
ges\django\core\checks\urls.py", line 10, in check_url_config
return check_resolver(resolver)
File "C:\Users\galeal\AppData\Local\Programs\Python\Python35-32\lib\site-packa
ges\django\core\checks\urls.py", line 19, in check_resolver
for pattern in resolver.url_patterns:
File "C:\Users\galeal\AppData\Local\Programs\Python\Python35-32\lib\site-packa
ges\django\utils\functional.py", line 33, in get
res = instance.dict[self.name] = self.func(instance)
File "C:\Users\galeal\AppData\Local\Programs\Python\Python35-32\lib\site-packa
ges\django\core\urlresolvers.py", line 417, in url_patterns
patterns = getattr(self.urlconf_module, "urlpatterns", self.urlconf_module)
File "C:\Users\galeal\AppData\Local\Programs\Python\Python35-32\lib\site-packa
ges\django\utils\functional.py", line 33, in get
res = instance.dict[self.name] = self.func(instance)
File "C:\Users\galeal\AppData\Local\Programs\Python\Python35-32\lib\site-packa
ges\django\core\urlresolvers.py", line 410, in urlconf_module
return import_module(self.urlconf_name)
File "C:\Users\galeal\AppData\Local\Programs\Python\Python35-32\lib\importlib
init.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 986, in _gcd_import
File "", line 969, in _find_and_load
File "", line 958, in _find_and_load_unlocked
File "", line 673, in _load_unlocked
File "", line 662, in exec_module
File "", line 222, in _call_with_frames_removed
File "D:\Guilherme\proj\bitbucket\uengine\union_engine\urls.py", line 4, in
from union_engine.generics import urls as generics_urls
File "D:\Guilherme\proj\bitbucket\uengine\union_engine\generics\urls.py", line
30, in
route_name, mdl.get_viewset(), base_name=route_name)
AttributeError: type object 'CorsModel' has no attribute 'get_viewset'

HI Guys,

How I ADD Access-Control-Max-Age ?

Although the doc states that setting CORS_ORIGIN_WHITELIST to None will allow anyone access to the service, this causes the following error:

Internal Server Error: /
Traceback (most recent call last):
  File "/home/vagrant/.virtualenvs/WebsiteBackend/local/lib/python2.7/site-packages/django/core/handlers/base.py", line 201, in get_response
    response = middleware_method(request, response)
  File "/home/vagrant/.virtualenvs/WebsiteBackend/local/lib/python2.7/site-packages/corsheaders/middleware.py", line 44, in process_response
    if not settings.CORS_ORIGIN_ALLOW_ALL and self.origin_not_found_in_white_lists(origin, url):
  File "/home/vagrant/.virtualenvs/WebsiteBackend/local/lib/python2.7/site-packages/corsheaders/middleware.py", line 64, in origin_not_found_in_white_lists
    return url.netloc not in settings.CORS_ORIGIN_WHITELIST and not self.regex_domain_match(origin)
TypeError: argument of type 'NoneType' is not iterable

If this behaviour is indeed unexpected, I'l be happy to send a PR.

Thanks,

If the view returns a non-200 status code (eg if it typically requires authentication, which a CORS OPTIONS request will not provide, then it might return a 403 or 401 response), then then response sent back from the middleware will also be non-200.

The CORS spec is explicit that 200 is the required response, so although the correct headers will have been sent, the response will be disregarded by the client.

As an example, I don't believe this middleware would work out of the box with REST framework views that require authentication.

An alternative would be to instead use process_request, and if the request is an OPTIONS request, and includes an Access-Control-Request-Method indicating that this is a CORS preflight request, then immediately return a 200 response with an empty body and the correct headers set as is currently the case.

It might also make sense to also continue to handle the response case as you currently do, for better consistency of response headers. (Eg. This gist https://gist.github.com/1369619 uses a similar implementation to what I've described here.)

It'd be nice to link to this middleware from the REST framework docs as a definitive solution to CORS, so be great if we could get it working together with authentication-protected APIs one way or another.

My CORS knowledge is a little sketchy so it's entirely possible that I'm being stupid here feel free to talk any of this through if that doesn't seem sensible to you.

Note related discussions:

• encode/django-rest-framework#605
• https://groups.google.com/forum/?fromgroups=#!topic/django-rest-framework/W1vaVtlsii8

importing cors-headers in Django 1.7+ results in

.../lib/python3.4/importlib/_bootstrap.py:321: RemovedInDjango19Warning: The utilities in django.db.models.loading are deprecated in favor of the new application loading system.
  return f(*args, **kwds)

It can be fixed by replacing "from django.db.models.loading import get_model"
in corsheaders/middleware.py with

try:
    from django.apps import apps
    get_model = apps.get_model
except:
    from django.db.models.loading import get_model

Hi,

I have ran pip install django-cors-headers and it reported that CorsPostCsrfMiddleware doesn't exist.

I opened files that pip installed and in deed CorsPostCsrfMiddleware class is missing. I have checked github repo, and normally there you have CorsPostCsrfMiddleware.

Then I went to
https://pypi.python.org/pypi/django-cors-headers
and saw that on last two versions available up there there is some missing code.

But when I do pip install git+git://github.com/ottoyiu/django-cors-headers.git all goes good

Can you help what is going on?

I have added the following line to my Django settings using the plugin:

CORS_ALLOW_HEADERS = ('MY-auth-origin')

which causes my response header to be

Access-Control-Allow-Headers:M,Y, -, a, u, t, h, -, o, r, i, g, i, n

Solution
I tried adding two headers (as per example in docs)

CORS_ALLOW_HEADERS = ('MY-auth-origin','Dean-Is-Awesome')

which returns the proper first header as

Access-Control-Allow-Headers: MY-auth-origin, Dean-Is-Awesome

Using Django version 1.8.4 and Google Chrome Version 48.0.2564.97 m (64-bit)

corsheaders.middleware.CorsPostCsrfMiddleware doesn't find.
1.0.0 doesn't have it. Did you forget to push it?

Please upload the newest version of django-cors-headers (0.11) to PyPi

I was wondering if you have any tips for getting this to work in an environment that has a potentially changing IP address or DNS name? Specifically operating behind a Load Balancer.

In our tests, Chromium was unable to communicate to a Django app using
this plugin unless we overrode CORS_ALLOW_HEADERS in settings.py to
include the access-control-allow-origin header itself.

Thus, if you can replicate, I think the default headers in the plugin
should include that, and be like:

CORS_ALLOW_HEADERS = (
    'x-requested-with',
    'content-type',
    'accept',
    'origin',
    'authorization',
    'x-csrftoken',
    'access-control-allow-origin',
)

It works when I run my website with runserver, but sometimes cors POST request failed when I run it with uwsgi + Nginx. Here's the output from chrome console when it failed:

Should I config uwsgi or Nginx as well?

Hello,

I tried to install via pip, then added the necessary code, and deploy it to Heroku. However, the page shows internal server error. How can I debug this?

I'm using CORS_ORIGIN_ALLOW_ALL = True. In Chrome I'm getting this error message.

XMLHttpRequest cannot load XXXXXX. The 'Access-Control-Allow-Origin' header contains multiple values '*, *', but only one is allowed. Origin 'XXXXX' is therefore not allowed access.

FireFox says:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at XXXXX. This can be fixed by moving the resource to the same domain or enabling CORS.

Am I doing something wrong, or is it a bug?

I am investigating the Cross-Domains problems, I have with some REST service call. Chrome said this: Request header field x-requested-with is not allowed by Access-Control-Allow-Headers.

The solution that I have read, is to exactly echo back value of "Access-Control-Request-Headers" to "Access-Control-Allow-Headers".

Need a way (config) to get this done.

Not sure if this should be added to the defaults or simply mentioned in the relevant section of the README, but communicating in JSON on Safari causes the following error:

Failed to load resource: Request header field Accept-Encoding is not allowed by Access-Control-Allow-Headers.

[Error] XMLHttpRequest cannot load http://mydomain.com/mypath. Request header field Accept-Encoding is not allowed by Access-Control-Allow-Headers. (localhost, line 0)

The fix is to add 'accept-encoding' to CORS_ALLOW_HEADERS

Wondering if Django's X-CSRFToken should be included in the defaults for CORS_ALLOW_HEADERS. As it stands CORS POST/PUT/DELETE requests that include a CSRF token in the form itself will be allowed, but AJAX style CORS requests that include the CSRF token as a header will not be allowed.

I don't really know enough about CORS to know if X-CSRFToken should be in by default, but if not it's probably worth documenting it either as something that users might need to add.

Not seen anyone else report this issue, so may be a misunderstanding on my part. Any thoughts?

This ticket is a result of the follow conv on IRC...

[09:52:06] <Noeble>          hi tomchristie
[09:52:27] <Noeble>          I solved the problem last nite with the csrfcookie
[09:52:51] <tomchristie>     ah good
[09:53:14] <Noeble>          2 simple things
[09:53:27] <Noeble>          @method_decorator(ensure_csrf_cookie)  on the post def in the class based view
[09:53:34] <Noeble>          to force the cookie creation
[09:54:03] <Noeble>          and to allow X-CSRFToken in the CORS settings for incoming headers
[10:10:34] <tomchristie>     Noeble: "and to allow X-CSRFToken in the CORS settings for incoming headers" <--- Is this mentioned in the Django docs someplace?
[10:15:04] <Noeble>          tomchristie: No, its specific for the django-cors-headers, even tho its following the cors standard so its probably similiar in other implementations of cors.
[10:16:22] <tomchristie>     Noeble: Confused - CSRF not mentioned in django-cosrs-headers, tho?
[10:16:40] <Noeble>          nope, its not but CORS_ALLOW_HEADERS is
[10:16:51] <Noeble>          and it tells you the headers that is allowed by default
[10:17:18] <Noeble>          if you wanna use other headers towards the cors api you need to add it to the tuple
[10:18:04] <tomchristie>     Noeble: So what have you got in your django-cors-headers settings then?
[10:18:28] <Noeble>          http://pastebin.com/tv5pTmYV
[10:18:39] <Noeble>          I added the 5 default ones + the custom header for django csrf
[10:19:33] <tomchristie>     Ahhhhhhhh
[10:20:09] <Noeble>          :)
[10:21:31] <tomchristie>     Looks to me that that ought to be in there by default
[10:21:47] <tomchristie>     `CORS_ALLOW_METHODS` includes POST etc by default, so….
[10:22:16] <Noeble>          yea if you put the csrftoken inside the form it will work
[10:23:40] <Noeble>          but I do a post using angularjs, and I dont do any template rendering
[10:24:03] <Noeble>          $http.defaults.headers.post['X-CSRFToken'] = $cookies.csrftoken;
[10:28:29] <Noeble>          Same thing applies if you do a normal ajax post with jquery, not rendering th csrf token inside the form
[10:28:52] <Noeble>          cross domain that it
[10:28:55] <Noeble>          is-

As far as I can tell there is no way to control allowed methods on per resource basis for OPTIONS requests.

I'm having an issue with the CSRF failing inconsistently.

Here are the modules that I have installed:

• Django == 1.7.4
• Cors Headers == 1.0.0
• Rest Framework == 3.0.2

I have this in my settings.py

INSTALLED_APPS = (
   ...,
   'corsheaders',
   ...
)

MIDDLEWARE_CLASSES = (
   ...,
   'corsheaders.middleware.CorsMiddleware',
   'django.middleware.common.CommonMiddleware',
   ...
)

CORS_ORIGIN_ALLOW_ALL = True
CORS_URLS_REGEX = r'^/api/.*$'

The issue that I'm getting is CSRF Failed: CSRF token missing or incorrect from the server, however; this is happening inconsistently. Sometimes, the CSRF will not file but after an hour or less, it starts to fail again.

Could this be because of Rest Framework 3 or Django 1.7?

Will v0.6 get uploaded to PyPI soon? Are there more changes that need to be added before the new release?

Hey guys!

Im using django-cors-headers with django-rest-framework and an angularjs client. All my server side is using a subdomain like api.myapp.com and my client app is www.myapp.com. All works fine except for IE8 and 9. Any ideas how to set that up? All I see on the IE8 debug window is the cross domain error.
Thank you for any clue!