zestedesavoir / django-cors-middleware Goto Github PK

subject.

Installed version 1.4.0.

Added to INSTALLED_APPS

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'corsheaders',
]

Added to middlewares:

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'corsheaders.middleware.CorsMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

And, in settings.py

CORS_ORIGIN_ALLOW_ALL = True

Yet, if I visit my app, I was expecting to find this in the headers...

Access-Control-Allow-Origin: *

but there's no difference at all... it is as if I installed nothing.

What am I doing wrong?

Server is ran using manage.py runserver at 127.0.0.1:8000.

As per issue in adamchainz#78 , it seems the DNT header is common (and safe) enough so that it should not invalidate CORS in the preflight request.

$ python manage.py dumpdata
CommandError: Unable to serialize database: relation "corsheaders_corsmodel" does not exist
LINE 1: ...smodel"."id", "corsheaders_corsmodel"."cors" FROM "corsheade...

Manually running makemigrations also doesn’t help, because there is no migrations module exists under corsheaders. I know from the sources that it is optional (and undocumented!) to use a model for whitelisting, but bricking management commands is not a Good Way To Go™

Adding corsheaders/migrations/__init__.py solves the problem, though.

When I set CORS_ORIGIN_ALLOW_ALL = True, I can see Access-Control-Allow-Origin: * in the response header. However, when I set it to false, and use white list, I cannot see Access-Control-Allow-Origin in the response header.

CORS_ORIGIN_ALLOW_ALL = False

CORS_ORIGIN_WHITELIST = (
    '127.0.0.1',
)

I did supply Origin in the header.

I'm having an issue getting my headers to show up in my response. I have added :

CORS_ORIGIN_ALLOW_ALL = True in my settings.py file as well as the proper import and middleware. However, when I get a reponse back, I still get the error "No Access-Control-Allow-Origin' on each response. I'm running Django 1.9.7 with python 2.7. I've done all the steps that I've read on all of these threads to try and fix it, but it still won't pass the header through. Any help?

Hi,

Thanks for forking this and maintaining it given the lack of updates on django-cors-headers. I'm finding that when I follow the installation instructions in the README.md, I get an error that seems to indicate that django-cors-middleware by itself is missing some sort of dependency. When I install both django-cors-headers==2.4.0 and django-cors-middleware=1.3.1, CORS issues are resolved without a problem. Any idea why this might be?

Including error that I got here, using Django==1.11.6.

======================================================================
ERROR: setUpClass (functional_tests.test_my_app.TestMyApp)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/rowan/workspace/beacon/beacon/functional_tests/base.py", line 19, in setUpClass
    super().setUpClass()
  File "/Users/rowan/virtualenvs/beacon/lib/python3.6/site-packages/django/test/testcases.py", line 1352, in setUpClass
    raise cls.server_thread.error
  File "/Users/rowan/virtualenvs/beacon/lib/python3.6/site-packages/django/test/testcases.py", line 1281, in run
    handler = self.static_handler(_MediaFilesHandler(WSGIHandler()))
  File "/Users/rowan/virtualenvs/beacon/lib/python3.6/site-packages/django/core/handlers/wsgi.py", line 151, in __init__
    self.load_middleware()
  File "/Users/rowan/virtualenvs/beacon/lib/python3.6/site-packages/django/core/handlers/base.py", line 80, in load_middleware
    middleware = import_string(middleware_path)
  File "/Users/rowan/virtualenvs/beacon/lib/python3.6/site-packages/django/utils/module_loading.py", line 20, in import_string
    module = import_module(module_path)
  File "/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/lib/python3.6/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 994, in _gcd_import
  File "<frozen importlib._bootstrap>", line 971, in _find_and_load
  File "<frozen importlib._bootstrap>", line 953, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'corsheaders.middleware'

Django 1.9 and 1.10 didn't work for me with this package. I switched to 1.8 and everything works great.
Using:

• python 2.7
• django-rest-framework
• rest-framework-json-api

Once #18 is merged, Travis will test django-cors-middleware under Django 1.10a1, with the middleware specified via the new MIDDLEWARE setting rather than the deprecated MIDDLEWARE_CLASSES.

This currently fails, so a later PR will need to:

1. Use django.utils.deprecation.MiddlewareMixin
2. Decide how to handle non-HTTP200 responses, since the behaviour has now changed (ie unless special handling is added to django-cors-middleware, it will stop adding CORS headers to the responses of non-preflight requests - see the comment for the test_middleware_integration_get_auth_view test added in #18 for details). This may require subclassing ExceptionMiddleware.

For more info, see:
https://docs.djangoproject.com/en/1.10/topics/http/middleware/#upgrading-pre-django-1-10-style-middleware

We now have CORS that is global to our Django project. But for Django projects running multiple sites, one may want to configure CORS per site. I have faced this at my current employer. While working for a multi tenant e-commerce platform, we had to modify django-cors-headers to support dynamic CORS management per site(customer). What about a configuration where, alongside the current settings for django-cors-middlewere, we detect if settings.py has the configuration for the current http request's site and apply those above the global ones?

Something like

'SITE_CORS': {
'example.com': {
'CORS_ALLOW_METHODS': (
'GET',
'POST',
)
}

apart from CORS_ALLOW_METHODS, all other configurations for example.com will be same the global ones.

Or something cleaner and easier to configure can be used for the settings. In the middleware

It sounds like Origin should be included in Vary in most cases. See:
https://github.com/cyu/rack-cors/blob/master/lib/rack/cors.rb#L93
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Access-Control-Allow-Origin

It seems like this plugin is not compatible with django channels (daphne webserver), any plans to include this?

Please, it will be more comfortable to use

Since the base repo is now getting substantially more frequent updates, would it be worthwhile to deprecate this library and point to the original?

We should make a pypi package.

Note : edit email address.

I have a API with django-rest-framework and django-cors-headers configured in stage env

CORS_ORIGIN_ALLOW_ALL = False
CORS_ORIGIN_WHITELIST = (
'myotherdmain.com',
)
CSRF_TRUSTED_ORIGINS = (
'myotherdomain.com',
)

When I do GET requests from my localhost to the published API is blocked and ok. But if I try POST requests I don't recieve any error message and the request is allowed. What am I doing wrong ? What I get is: with CORS, API will not allowed to recieve any request from other domain wich isn't in CORS_ORIGIN_WHITELIST.

Ideas?
Django version: 1.10.5

Thanks !

Hi,

I am trying to run CORS requests on a mod_wsgi Django server but I keep getting CORS issues.
On my regular Django server (not https, not apache2) it works properly:

HTTPS Django:
python manage.py runmodwsgi --host 0.0.0.0 --port 8001 --https-port 8000 --ssl-certificate-file ../utils/ssl_cert/local.crt --ssl-certificate-key-file ../utils/ssl_cert/local.key --processes 8 --server-name localhost --https-only --reload-on-changes

Should django-cors-middleware work properly with it or do you know if apache requires some extra configuration somehow? (tried many things already).

I also updated my Django configuration with:

CORS_ALLOW_CREDENTIALS = True

and

    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    ***'corsheaders.middleware.CorsMiddleware',***
    '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.CorsPostCsrfMiddleware',***

If you import corsheaders.defaults.default_headers in your setting file to add a custom header to the list of default allowed headers, it'll fail due to circular dependency.

We can probably have a file just for constants and basic types like this and then reference them when needed. That way, we wouldn't have circular dependency.

We now have CORS that is global to our Django project. But for Django projects running multiple sites, one may want to configure CORS per site. I have faced this at my current employer. While working for a multi tenant e-commerce platform, we had to modify django-cors-headers to support dynamic CORS management per site(customer). What about a configuration where, alongside the current settings for django-cors-middlewere, we detect if settings.py has the configuration for the current http request's site and apply those above the global ones?

Something like

'SITE_CORS': {
'example.com': {
'CORS_ALLOW_METHODS': (
'GET',
'POST',
)
}

apart from CORS_ALLOW_METHODS, all other configurations for example.com will be same the global ones.

Or something cleaner and easier to configure can be used for the settings. In the middleware

Dependabot allerted us to a new release, 1.4.0. I viewed the GitHub releases page to see what the changes were in this release, but was initially confused because I couldn't find a v1.4.0 release tag. It looks like the most recent release is incorrectly tagged v3.4.0, because it links to v1.4.0 on pypi.

If this was indeed done in error it may be a good idea to create a new v1.4.0 release tag as a clone of the v3.4.0 one and update the latter's description saying it was a mistake.