django-cors-headers

Posted liuweida

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了django-cors-headers相关的知识,希望对你有一定的参考价值。

django-cors-headers介绍

一个Django应用程序,向响应头中添加跨域资源共享(CORS)头。这允许从其他来源向Django应用程序发出浏览器内请求,当然也可以自定义中间件然后添加响应头信息。

关于cors问题可点击此处

安装

pip install django-cors-headers

注册到settings.py中的应用中

INSTALLED_APPS  =  [ 
    ... 
    'corsheaders' ,
    ... 
]

添加一个中间件类来监听响应

MIDDLEWARE  =  [   # 或Django <1.10上的MIDDLEWARE_CLASSES 
    ... 
    'corsheaders.middleware.CorsMiddleware' ,
    'django.middleware.common.CommonMiddleware' ,
    ... 
]

应将Corsmidlware放置在尽可能高的位置,尤其是要放在能够生成响应的中间件之前,比如Django的CommonMiddleware或Whitenoise middleware。如果不是放在这些响应中间件之前,它可能无法将CORS头添加到这些响应中。

另外,如果您使用CORS_REPLACE_HTTPS_REFERER,它应该放在Django的CsrfViewMiddleware之前。

配置

在Django设置中配置中间件的行为。您必须将允许进行跨站点请求的主机添加到 CORS_ORIGIN_WHITELIST,或将CORS_ORIGIN_ALLOW_ALL设置为True 以允许所有主机。

CORS_ORIGIN_ALLOW_ALL

如果为True,将不使用白名单,并且将接受所有来源。默认为False

CORS_ORIGIN_WHITELIST

授权进行跨站点HTTP请求的来源列表。默认为[]

CORS_ORIGIN_WHITELIST  =  [ 
    'https://example.com' ,
    'https://sub.example.com' ,
    'http:// localhost:8080' ,
    'http://127.0.0.1:9000'
]

CORS_ORIGIN_REGEX_WHITELIST

代表正则表达式的字符串列表,这些正则表达式与被授权发出跨站点HTTP请求的Origins相匹配。默认为[]。当 CORS_ORIGIN_WHITELIST不切实际时(例如您拥有大量子域时)很有用。

CORS_ORIGIN_REGEX_WHITELIST  =  [ 
    r “ ^ https://  w +  .example  .com $” ,
]

以下参数是可选的。

CORS_URLS_REGEX

一个正则表达式,用于限制将发送CORS标头的URL。默认为r‘^。* $‘,即匹配所有URL。当您仅在网站的一部分上需要CORS时很有用,例如/ api /处的API

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

CORS_ALLOW_METHODS

实际请求所允许的请求方式列表。默认为:

CORS_ALLOW_METHODS  =  [ 
    'DELETE' ,
    'GET' ,
    'OPTIONS' ,
    'PATCH' ,
    'POST' ,
    'PUT' ,
]

可以将默认值导入为corsheaders.defaults.default_methods,因此您可以使用自定义方法对其进行扩展。这使您可以随时了解最新更改。例如:

from corsheaders.defaults import default_methods

CORS_ALLOW_METHODS = list(default_methods) + [
    'POKE',
]

CORS_ALLOW_HEADERS

发出实际请求时可以使用的非标准HTTP标头的列表。默认为:

CORS_ALLOW_HEADERS = [
    'accept',
    'accept-encoding',
    'authorization',
    'content-type',
    'dnt',
    'origin',
    'user-agent',
    'x-csrftoken',
    'x-requested-with',
]

可以将默认值导入为corsheaders.defaults.default_headers,以便您可以使用自定义标头对其进行扩展。这使您可以随时了解最新更改。例如:

from corsheaders.defaults import default_headers

CORS_ALLOW_HEADERS = list(default_headers) + [
    'my-custom-header',
]

CORS_EXPOSE_HEADERS

The list of HTTP headers that are to be exposed to the browser. Defaults to [].

CORS_PREFLIGHT_MAX_AGE

客户端/浏览器可以缓存预检响应的秒数。 如果该值为0(或任何错误值),则不会发送最大期限标头。 默认为86400(一天)。

注意:预检请求是在发出“复杂请求”(例如Content-Type不是application / x-www-form-urlencoded)时提出的额外请求,用于确定服务器实际接受的请求。

CORS_ALLOW_CREDENTIALS

如果为True,则将允许将cookie包含在跨站点HTTP请求中。默认为False

注意:在Django 2.1中,添加了SESSION_COOKIE_SAMESITE设置,默认情况下设置为 Lax,这将防止Django的会话Cookie跨域发送。将其更改为‘ None ’可绕过此安全限制。

CSRF集成

大多数站点将需要利用Django提供的跨站点请求伪造保护。CORS和CSRF是分开的,并且Django无法使用您的CORS配置免除“ Referer ”中的网站,以检查它是否处理了安全请求。做到这一点的方法是使用其CSRF_TRUSTED_ORIGINS设置。例如:

CORS_ORIGIN_WHITELIST = [
    'http://read.only.com',
    'http://change.allowed.com',
]

CSRF_TRUSTED_ORIGINS = [
    'change.allowed.com',
]

CORS_REPLACE_HTTPS_REFERER

CSRF_TRUSTED_ORIGINS是Django 1.9中引入的,因此早期版本的用户将需要替代解决方案。如果CORS_REPLACE_HTTPS_REFERERTrue,则只要CORS检查通过,CorsMiddleware就会将Referer标头更改为将通过Django的CSRF检查的内容。默认为 False

请注意,与CSRF_TRUSTED_ORIGINS不同,此设置不允许您区分CORS 信任读取资源的域和避免CSRF保护而信任更改资源的域。

启用此功能后,您还应该在MIDDLEWARE_CLASSES中的django.middleware.csrf.CsrfViewMiddleware之后添加corsheaders.middleware.CorsPostCsrfMiddleware来撤消Referer

MIDDLEWARE_CLASSES  =  [ 
    ... 
    'corsheaders.middleware.CorsMiddleware' ,
    ... 
    'django.middleware.csrf.CsrfViewMiddleware' ,
    'corsheaders.middleware.CorsPostCsrfMiddleware' ,
    ... 
]

Signals

如果您的用例需要的不仅仅是上述配置,那么您可以附加代码来检查是否应该允许给定的请求。例如,这可用于读取模型允许的来源列表。将任意数量的处理程序附加到启用check_request_enabled的Django信号上,该信号提供request参数(在处理程序中使用** kwargs防止将来添加任何参数)。如果附加到信号的任何处理程序返回truthy值,则将允许该请求。

例如,您可以定义如下处理程序:

# myapp/handlers.py
from corsheaders.signals import check_request_enabled

from myapp.models import MySite

def cors_allow_mysites(sender, request, **kwargs):
    return MySite.objects.filter(host=request.host).exists()

check_request_enabled.connect(cors_allow_mysites)

然后在应用就绪时使用Django AppConfig连接它:

# myapp/__init__.py

default_app_config = 'myapp.apps.MyAppConfig'
# myapp/apps.py

from django.apps import AppConfig

class MyAppConfig(AppConfig):
    name = 'myapp'

    def ready(self):
        # Makes sure all signal handlers are connected
        from myapp import handlers  # noqa

信号的常见用例是允许所有来源访问URL的子集,同时允许一组正常的来源访问所有 URL。仅使用常规配置是不可能的,但是可以使用信号处理程序来实现。

首先将CORS_ORIGIN_WHITELIST设置为允许访问每个URL的受信任来源列表,然后将处理程序添加到 check_request_enabled以允许CORS不受限制URL的来源。例如:

# myapp/handlers.py
from corsheaders.signals import check_request_enabled

def cors_allow_api_to_everyone(sender, request, **kwargs):
    return request.path.startswith('/api/')

check_request_enabled.connect(cors_allow_api_to_everyone)

以上是关于django-cors-headers的主要内容,如果未能解决你的问题,请参考以下文章

即使使用 django-cors-headers 也得到 304 响应

跨域设置django-cors-headers

使用 Postman 时 django-cors-header 无法按预期工作

django-cors-header 出现问题 - ModuleNotFoundError: No module named 'corsheaders'

Django-cors-headers 不工作

django-cors-headers 不适用于 DRF(Django Rest 框架)