Django REST Framework 分页链接不使用 HTTPS

Question

我正在为某个运行良好的 DRF 端点设置分页 - 但是，当部署在使用 HTTPS 的服务器上时，指向下一页和上一页的链接由 http:// 而不是 https:// 形成。这会导致浏览器阻止对下一页/上一页的请求。

我已经仔细检查了初始请求是使用 HTTPS 发出的，而对 this question 的第二个回答指出它应该在形成的 URL 中使用 HTTPS，因为请求是通过 HTTPS 来的。

同一个问题的第一个答案也没有帮助 - 我将 X-Forwarded-Proto 行添加到我的 nginx 配置并重新加载，但无济于事。

The DRF docs 提到 reverse() 应该表现得像基本的 Django 反向，但似乎很清楚初始请求是 HTTPS 而返回的 URL 是 HTTP。

这里有几个显示初始请求的屏幕截图 (https://<domain>.com/api/leaderboard/)：

回复包含next: http://<domain>.com/api/leaderboard/?page=2)：

我认为这将是一个简单的设置，但在搜索了这个站点和 DRF 站点后都找不到任何东西。

这是我的 nginx 配置：

 location / {
    # proxy_pass http://127.0.0.1:9900;
    proxy_set_header X-Forwarded-Host $server_name;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    add_header P3P 'CP="ALL DSP COR PSAa PSDa OUR NOR ONL UNI COM NAV"';

    root /opt/app/client/dist;
    index index.html index.htm;

}

This question 包含一个非常详细的答案，但最终表示 url 是使用与请求相同的协议形成的，这似乎不是这里的情况。我需要设置 Django SECURE_PROXY_SSL_HEADER 吗？考虑到它可能不安全的警告，我不确定。

Answer 1

我需要设置 Django SECURE_PROXY_SSL_HEADER 吗？考虑到它可能不安全的警告，我不确定。

是的，你知道。 但是，您需要注意自己在做什么。特别要确保它从外部丢弃 X-Forwarded-Proto。

Answer 2

由于这是谷歌搜索结果中出现的第一个 SO 帖子，我认为分享我如何解决它会很有用。我的具有 Kubernetes 风格，但在底层逻辑与其他逻辑并没有太大区别。

我正在使用位于 Django 前面的 Kubernetes 入口控制器，所以对你来说可能会有所不同，但我会总结一下我的上下文，以便你看看它是否对你有用：

问题

所以我遇到了与 OP 相同的问题，即使我使用 https 访问 api 端点，来自 DRF 的分页链接始终为 http。如果您设置了 Django REST 框架 (DRF) 附带的浏览器 API，您可以更清楚地看到这一点，然后转到 api 根页面。我看到 DRF 生成的所有链接都是http，无论我在访问该站点时使用什么协议。

我的上下文

堆栈，从外部世界到 Django：

1. Kuberenetes Nginx 入口控制器（使用letsencrypt 设置SSL）
2. 入口规则指向 Django 服务
3. Gunicorn 启动 Django 服务器
4. Django 读取settings.py 并开始服务请求

我如何调试并找出原因

1. 转储入口控制器的nginx.conf。如果您不知道如何操作：首先通过 kuberctl get pods -n <namespace of your ingress controller> 找出 pod 名称，写下该名称，然后通过 kubectl exec -it -n ingress_controller_namespace ingress_controller_pod_name cat /etc/nginx/nginx.conf > nginx.conf 转储文件。
2. 查看nginx.conf，检查您的网站域的location 部分中是否有proxy_set_header X-Forwarded-Proto $scheme;，或类似的东西正确设置代理标头X-Forwarded-Proto。默认情况下，Kubernetes nginx 入口控制器应该已经为您提供了这一行（或等效的行）。
3. 接下来将请求定向到 Gunicorn。一个问题是您需要将--forwarded-allow-ips="*" 添加到您的 gunicorn 命令中，或者如果您知道您的 nginx 服务器 IP，则可以限制为那个，以便 gunicorn 为您转发标头，否则 gunicorn 将剥离这些标头.所以你最终会得到像gunicorn django_server.wsgi:application --forwarded-allow-ips="*" --workers=${PROPER_WORKER_NUM} --log-level info --bind 0.0.0.0:8001 这样的命令。通过指定workers=4，您可以拥有 4 个工作人员，通常取决于您在服务器上的 CPU。 --log-level info 仅用于调试目的，它是可选的。
4. 在 Django 中，您需要在 settings.py 中有 SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')，其他答案已经提到。您可能想知道为什么前缀 HTTP_ 而在 nginx 中我们的标题名称是 X-Forwarded-Proto。这是因为 WSGI 会将前缀添加到它识别的标头中。这行基本上说，如果标头 HTTP_X_FORWARDED_PROTO 等于字符串 "https"，那么 Django 将请求识别为安全的。这将影响 Django 中的一些行为，例如你会得到request.is_secure == True、request.build_absolute_uri(None) == 'https://...'，最重要的是，Django REST Framework 分页链接现在将使用https！ （只要你确实通过https点击了api）

好的，现在您可以再次测试。如果 DRF 现在给你 https - 恭喜。或者，如果你和我一样，在上面尝试之后，仍然没有运气 - DRF 仍然生成该死的http 链接。我想分享一些我在调试时的技巧：

如果您有DEBUG=True 并且可以访问服务器日志，则通过print() 在Django 中打印出以下值，或者将它们传递给模板上下文并在html 页面中显示它们（如果这样的话）更容易在启用 SSL 的生产环境中进行测试。

• request.is_secure()：如果你没有让 DRF 使用http，你很可能会得到False。
• request.META 为您提供 Django 收到的所有标头。标题HTTP_X_FORWARDED_PROTO 出现了吗？它有什么价值？
  • 我想分享一下，这对我来说是一个令人振奋的时刻：HTTP_X_FORWARDED_PROTO 的值是 https,https，这告诉我它以某种方式具有重复值，我可能将 proxy_set_header 设置了两次，并且答对了！默认情况下，K8 入口控制器已经有了这一行，并且由于我通过 location-snippet 再次添加了它，所以现在我总共有两行 proxy_set_header X-Forwarded-Proto $scheme;。删除我的 sn-p 后，DRF 显示 https，我很高兴能完成这项工作。这不是那么直截了当，因为我认为proxy_set_header 会覆盖并“设置”标题值。但似乎它只是不断附加。