django-cors-headers是一个用于处理跨源资源共享（CORS）所需的服务器头的Django应用程序。
项目描述
一个Django应用程序，它向响应添加跨源资源共享（CORS）头。这允许从其他源在浏览器中向您的Django应用程序发出请求。
通过我的书籍提高您的Django和Git技能 （请访问我的书籍）.
关于CORS
添加CORS头允许您的资源在其他域上被访问。在添加头之前理解其含义很重要，因为您可能无意中将站点的私有数据向他人开放。
以下是一些关于此主题的好资源
要求
支持 Python 3.8 到 3.12。
支持 Django 3.2 到 5.1。
设置
使用 pip 安装
python -m pip install django-cors-headers然后将其添加到已安装的应用中
INSTALLED_APPS = [
...,
"corsheaders",
...,
]请确保添加尾随逗号，否则可能会出现 ModuleNotFoundError 错误（请参阅 这篇博客文章）。
您还需要添加一个中间件类来监听响应
MIDDLEWARE = [
...,
"corsheaders.middleware.CorsMiddleware",
"django.middleware.common.CommonMiddleware",
...,
]CorsMiddleware 应尽可能放在高位，特别是在任何可能生成响应的中间件之前，例如 Django 的 CommonMiddleware 或 Whitenoise 的 WhiteNoiseMiddleware。如果它不在前面，它将无法将这些响应的 CORS 头部添加到其中。
关于
django-cors-headers 由 Otto Yiu 在 2013 年 1 月创建。从 2015 年 8 月开始不再维护，并在 2016 年 1 月被 Zeste de Savoir 的 Laville Augustin 以 django-cors-middleware 包的形式分叉。2016 年 9 月，Adam Johnson、Ed Morley 等人从 Otto Yiu 那里获得了 django-cors-headers 的维护责任（请参阅 问题 110）。基本上，分叉的 django-cors-middleware 中的所有更改都已合并，或者以不同的方式重新实现，因此应该可以切换回来。如果有尚未合并的功能，请为此功能打开一个问题。
django-cors-headers 在其历史中拥有 40+ 贡献者；感谢每一位。
配置
在 Django 设置中配置中间件的行为。您必须设置以下三个设置之一
CORS_ALLOWED_ORIGINS
CORS_ALLOWED_ORIGIN_REGEXES
CORS_ALLOW_ALL_ORIGINS
CORS_ALLOWED_ORIGINS: Sequence[str]
允许进行跨站 HTTP 请求的来源列表。此设置中的来源将被允许，并且请求的来源将在 access-control-allow-origin 标头中回显给客户端。默认为 []。
来源由 CORS RFC 第 3.2 节 定义为 URI 方案 + 主机名 + 端口，或以下特殊值之一 'null' 或 'file://'。默认端口（HTTPS = 443，HTTP = 80）是可选的。
特殊值 null 由浏览器在 “隐私敏感环境” 中发送，例如当客户端从 file:// 域运行时。特殊值 file:// 是 Chrome 在 Android 上的一些版本意外发送的，如 此错误 所示。
示例
CORS_ALLOWED_ORIGINS = [
"https://example.com",
"https://sub.example.com",
"http://localhost:8080",
"http://127.0.0.1:9000",
]以前这个设置被称为 CORS_ORIGIN_WHITELIST，它仍然作为一个别名工作，新名称具有优先级。
CORS_ALLOWED_ORIGIN_REGEXES: Sequence[str | Pattern[str]]
表示匹配允许进行跨站 HTTP 请求的来源的正则表达式的字符串列表。默认为 []。当 CORS_ALLOWED_ORIGINS 不切实际时很有用，例如当您有大量子域时。
示例
CORS_ALLOWED_ORIGIN_REGEXES = [
r"^https://\w+\.example\.com$",
]以前这个设置被称为 CORS_ORIGIN_REGEX_WHITELIST，它仍然作为一个别名工作，新名称具有优先级。
CORS_ALLOW_ALL_ORIGINS: bool
如果为 True，则允许所有来源。将忽略限制允许来源的其他设置。默认为 False。
将此设置为 True 可能是 危险的，因为它允许任何网站向您的网站发送跨源请求。通常，您会希望使用 CORS_ALLOWED_ORIGINS 或 CORS_ALLOWED_ORIGIN_REGEXES 限制允许的源列表。
之前这个设置被称为 CORS_ORIGIN_ALLOW_ALL，它仍然作为别名使用，但新名称具有优先级。
以下是一些可选设置，默认值可能就足够了。
CORS_URLS_REGEX: str | Pattern[str]
一个正则表达式，用于限制将发送 CORS 标头的 URL。默认为 r'^.*$'，即匹配所有 URL。当您只需要在网站的某个部分使用 CORS 时很有用，例如在 /api/ 的 API 上。
示例
CORS_URLS_REGEX = r"^/api/.*$"CORS_ALLOW_METHODS: Sequence[str]
允许实际请求的 HTTP 动词列表。默认值
CORS_ALLOW_METHODS = (
"DELETE",
"GET",
"OPTIONS",
"PATCH",
"POST",
"PUT",
)默认值可以导入为 corsheaders.defaults.default_methods，这样您就可以扩展它以包含您自己的方法。这使您能够跟上任何未来的更改。例如
from corsheaders.defaults import default_methods
CORS_ALLOW_METHODS = (
*default_methods,
"POKE",
)CORS_ALLOW_HEADERS: Sequence[str]
您允许浏览器请求的非标准 HTTP 标头列表。在响应中设置 Access-Control-Allow-Headers 标头，以针对 预检请求。默认值
CORS_ALLOW_HEADERS = (
"accept",
"authorization",
"content-type",
"user-agent",
"x-csrftoken",
"x-requested-with",
)默认值可以导入为 corsheaders.defaults.default_headers，这样您就可以扩展它以包含您自己的标头。这使您能够跟上任何未来的更改。例如
from corsheaders.defaults import default_headers
CORS_ALLOW_HEADERS = (
*default_headers,
"my-custom-header",
)CORS_EXPOSE_HEADERS: Sequence[str]
要暴露给浏览器的额外 HTTP 标头列表，除了默认的 CORS 安全列表响应标头 之外。如果非空，则这些在 Access-Control-Expose-Headers 标头 中声明。默认为 []。
CORS_PREFLIGHT_MAX_AGE: int
浏览器可以缓存预检响应的秒数。在预检响应中设置 Access-Control-Max-Age 标头。如果此值为 0（或任何假值），则不会发送最大年龄标头。默认为 86400（一天）。
注意： 浏览器在发送某些“非简单”请求之前会发送 预检请求，以检查它们是否被允许。有关更多信息，请参阅 CORS MDN 文章。
CORS_ALLOW_CREDENTIALS: bool
如果设置为 True，则允许将 cookies 包含在跨站 HTTP 请求中。在预检和正常响应中设置 Access-Control-Allow-Credentials 标头。默认为 False。
注意：在 Django 2.1 中添加了 SESSION_COOKIE_SAMESITE 设置，默认设置为 'Lax'，这将阻止 Django 的会话 cookie 跨域发送。如果您需要绕过此安全限制，请将设置更改为 'None'。
CORS_ALLOW_PRIVATE_NETWORK: bool
如果设置为 True，则允许从“公共”IP 网站向“私有”IP 上的此服务器发送请求。在这种情况下，浏览器会发送一个额外的 CORS 标头 access-control-request-private-network，对于 OPTIONS 响应，必须包含 access-control-allow-private-network: true。
请参阅
本地网络访问，W3C 社区草案规范。
私有网络访问：介绍预航，来自 Google Chrome 团队的博客文章。
CSRF 集成
大多数网站都需要利用 Django 提供的跨站请求伪造保护（Cross-Site Request Forgery protection）。CORS 和 CSRF 是独立的，Django 无法使用您的 CORS 配置来免除其在对安全请求执行 Referer 检查的站点。要这样做，请使用其 CSRF_TRUSTED_ORIGINS 设置。例如
CORS_ALLOWED_ORIGINS = [
"https://read-only.example.com",
"https://read-and-write.example.com",
]
CSRF_TRUSTED_ORIGINS = [
"https://read-and-write.example.com",
]信号
如果您有一个需要上述配置之外的功能的使用场景，您可以附加代码来检查是否允许给定的请求。例如，这可以用于从模型中读取允许的来源列表。将任意数量的处理器附加到 check_request_enabled Django 信号，它提供 request 参数（在您的处理器中使用 **kwargs 来防止未来添加任何参数）。如果任何附加到信号的处理器返回一个真值，则请求将被允许。
例如，您可以定义一个处理器如下
# 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.headers["origin"]).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_ALLOWED_ORIGINS 设置为允许访问每个 URL 的受信任来源列表，然后向 check_request_enabled 添加一个处理器，以允许无限制 URL 的 CORS，无论来源如何。例如
# 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-4.4.0.tar.gz 的哈希值
| 算法 | 哈希摘要 | |
|---|---|---|
| SHA256 | 92cf4633e22af67a230a1456cb1b7a02bb213d6536d2dcb2a4a24092ea9cebc2 |
|
| MD5 | 37023fac6e689639b232b2f3d8256d76 |
|
| BLAKE2b-256 | d334f0c7a7241f885cbfc99b1edef0acc7915dd7a3fb749fe27de5e8a9fb2ccb |
django_cors_headers-4.4.0-py3-none-any.whl 的哈希值
| 算法 | 哈希摘要 | |
|---|---|---|
| SHA256 | 5c6e3b7fe870876a1efdfeb4f433782c3524078fa0dc9e0195f6706ce7a242f6 |
|
| MD5 | f03ca227ff36e8ce83d831dcfa3f63e8 |
|
| BLAKE2b-256 | 9d0c4201d5650199b3a36ef3f2ab91f44c4527a70685f3003ce9f3ed8c30780c |
