Django+Angular CORS 不适用于 POST

Posted 2023-03-03

【中文标题】Django+Angular CORS 不适用于 POST

【英文标题】：Django+Angular CORS not working with POST

【发布时间】：2017-09-24 03:08:42

【问题描述】：

我的 Angular4 应用程序（在 http://127.0.0.1:4200 开发服务器上运行）应该访问网络上的 django REST 后端。后端在我的控制之下，只能通过 HTTPS（运行 Apache，将请求通过隧道传送到在内部端口上运行的 gunicorn 服务器）提供。假设这是https://example.com/。由于历史原因，用户登录是使用会话完成的，因为我希望用户在登录后也能够使用 Django 的管理界面。工作流程如下：

用户打开http://127.0.0.1:4200，我向https://example.com/REST/is_logged_in 执行GET 请求，当用户尚未通过会话登录时返回403，否则返回200。在前一种情况下，用户被重定向到https://example.com/login/，由Django的模板引擎渲染，允许用户登录。一旦登录，用户被重定向到http://127.0.0.1:4200 单击 Angular UI 中的某个按钮时，会执行 POST 请求。即使预检 OPTIONS 请求明确将 POST 列为允许的操作，此发布请求也会失败并返回 403。

这是我在 Django 中的 CORS 配置：

NG_APP_ABSOLUTE_URL = 'http://127.0.0.1:4200'
# adapt Django's to Angular's presumed XSRF cookie/header names
CSRF_COOKIE_NAME = "XSRF-TOKEN"
CSRF_HEADER_NAME = "HTTP_X_XSRF_TOKEN"
CORS_ORIGIN_WHITELIST = (
    urlparse(NG_APP_ABSOLUTE_URL).netloc
)
CSRF_TRUSTED_ORIGINS = (
    urlparse(NG_APP_ABSOLUTE_URL).netloc
)
CORS_ALLOW_HEADERS = default_headers + (
    'x-xsrf-token',
)
CORS_ALLOW_CREDENTIALS = True

这是 Chrome 报告（成功，200）第一个 REST GET 请求以检查用户是否在响应中登录（成功后）：

Access-Control-Allow-Credentials:true Access-Control-Allow-Origin:http://127.0.0.1:4200 Allow:GET, HEAD, OPTIONS Connection:close Content-Type:application/json Date:Wed, 26 Apr 2017 15:09:26 GMT Server:gunicorn/19.6.0 Set-Cookie:XSRF-TOKEN=...; expires=Wed, 25-Apr-2018 15:09:26 GMT; Max-Age=31449600; Path=/ Transfer-Encoding:chunked Vary:Accept,Cookie,Origin X-Frame-Options:SAMEORIGIN

相应的请求是这样的：

Cookie:sessionid=...; XSRF-TOKEN=... Host:example.com Origin:http://127.0.0.1:4200 Referer:http://127.0.0.1:4200/

现在，到实际的问题：

预检请求：

Request URL:https://example.com/REST/change_user_data/
Request Method:OPTIONS
Status Code:200 OK
Access-Control-Request-Headers:content-type
Access-Control-Request-Method:POST
Connection:keep-alive
Host:example.com
Origin:http://127.0.0.1:4200
Referer:http://127.0.0.1:4200/dashboard/account

预检响应：

Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:accept, accept-encoding, authorization, content-type, dnt, origin, user-agent, x-csrftoken, x-requested-with, x-xsrf-token
Access-Control-Allow-Methods:DELETE, GET, OPTIONS, PATCH, POST, PUT
Access-Control-Allow-Origin:http://127.0.0.1:4200
Access-Control-Max-Age:86400
Connection:close
Content-Length:0
Content-Type:text/html; charset=utf-8
Date:Wed, 26 Apr 2017 15:36:56 GMT
Server:gunicorn/19.6.0
Vary:Origin
X-Frame-Options:SAMEORIGIN

现在我失败的 (403) POST 请求：

Accept:application/json
Accept-Encoding:gzip, deflate, br
Accept-Language:de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
Connection:keep-alive
Content-Length:60
Content-Type:application/json
Cookie:sessionid=...; XSRF-TOKEN=...
Host:example.com
Origin:http://127.0.0.1:4200
Referer:http://127.0.0.1:4200/dashboard/account

响应头：

HTTP/1.1 403 Forbidden
Date: Wed, 26 Apr 2017 15:36:56 GMT
Server: gunicorn/19.6.0
Vary: Accept,Cookie,Origin
X-Frame-Options: SAMEORIGIN
Content-Type: application/json
Access-Control-Allow-Credentials: true
Allow: POST, OPTIONS
Access-Control-Allow-Origin: http://127.0.0.1:4200
Set-Cookie: XSRF-TOKEN=...; expires=Wed, 25-Apr-2018 15:36:56 GMT; Max-Age=31449600; Path=/
Connection: close
Transfer-Encoding: chunked

为什么这个请求不起作用？这对我来说毫无意义！

最好的问候！

【问题讨论】：

我想我找到了原因：当我尝试设置 Django 服务器也是本地的（在 http://127.0.0.1:8000 上）时，POST 请求有效。在上述设置中完成的 POST 请求与使用本地 Django 服务器的请求之间的唯一区别是，当 Django 服务器位于本地时，浏览器（Chrome、Firefox）确实发送 X-XSRF-TOKEN，但在它打开时不发送example.com。 Django/Django-cors-headers 似乎依赖于此标头的存在。当服务器位于不同的域时，为什么 Angular 不会发送该标头？

【参考方案1】：

我遇到了同样的问题，尝试从我的 Angular CLI（端口 4200）向 Django（端口 8000）发送 POST 请求。我认为这是 Django 的问题，所以我安装了 cors 包，但是“问题”出在浏览器上（实际上不是问题，这是一个安全问题，请参阅here）。无论如何，我解决了为我的 Angular CLI 添加代理规则的问题，如下所示：

首先，不是将我的请求发送到 http://localhost:8000/api/... 而是将它们发送到 /api/（即发送到我在端口 4200 上运行的 ng 服务器）。 然后我在我的 Angular 项目中添加了一个名为“proxy.conf.json”的文件，其内容如下：

  "/api": 
    "target": "http://localhost:8000",
    "secure": false
  

最后，使用“--proxy-config”标志运行您的 ng 服务器： ng serve --watch --proxy-config proxy.conf.json

所有 API 请求都将发送到端口 4200，Angular 会在内部将它们重定向到 Django，从而避免 CORS 问题。 请注意，这仅对开发有效，不会在您构建应用代码并将其添加为 Django 服务器的静态代码时使用。

最后，有了这个解决方案，我不再需要用于 cors 的 python 模块，因此您可以将其删除。