Django REST Framework 分页链接不使用 HTTPS

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

我已经仔细检查了初始请求是否已通过 HTTPS 发出，以及第二个答案这个问题 https://stackoverflow.com/questions/37097643/django-rest-framework-https-for-absolute-urls指出它应该在形成的 URL 中使用 HTTPS，因为请求是通过 HTTPS 发送的。

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

DRF 文档 http://www.django-rest-framework.org/api-guide/reverse/提到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;

}

这个问题 https://stackoverflow.com/questions/22279893/djangorestframework-https-links-with-routers-and-viewsets包含一个非常详细的答案，但最终说 url 是使用与请求相同的协议形成的，但这里的情况似乎并非如此。我需要设置 Django SECURE_PROXY_SSL_HEADER 吗？考虑到它可能不安全的警告，我不确定。

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

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

问题

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

我的背景

堆栈，按照从外部世界到 Django 的顺序：

1. Kubernetes Nginx Ingress Controller（使用 LetsEncrypt 进行 SSL 设置）
2. Ingress 规则指向 Django 服务
3. Gunicorn 启动 Django 服务器
4. 姜戈读到settings.py并开始处理请求

我如何调试并找出原因

1. Dump nginx.conf入口控制器的。如果您不知道如何执行此操作：首先通过以下方式找出 pod 名称kuberctl get pods -n <namespace of your ingress controller>，写下该名称，然后转储文件kubectl exec -it -n ingress_controller_namespace ingress_controller_pod_name cat /etc/nginx/nginx.conf > nginx.conf.
2. 看着那（这nginx.conf，检查你是否有proxy_set_header X-Forwarded-Proto $scheme; in the location您的网站域的部分，或设置代理标头的类似内容X-Forwarded-Proto适当地。默认情况下，Kubernetes nginx 入口控制器应该已经为您提供了这一行（或同等内容）。
3. 接下来，请求被发送至 Gunicorn。一个问题是您需要添加--forwarded-allow-ips="*"到你的gunicorn命令，或者如果你知道你的nginx服务器IP，你可以限制到那个IP，这样gunicorn就会为你转发标头，否则gunicorn会去掉这些标头。所以你最终会得到像这样的命令gunicorn django_server.wsgi:application --forwarded-allow-ips="*" --workers=${PROPER_WORKER_NUM} --log-level info --bind 0.0.0.0:8001。您可以通过指定拥有 4 个工作人员workers=4，通常取决于服务器上的 CPU。这--log-level info仅用于调试目的，它是可选的。
4. 在 Django 中，你需要有SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https') in settings.py，其他答案已经提到了。您可能想知道为什么前缀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)

好了，现在你可以再次测试了。如果 DRF 现在为您提供 https - 恭喜。或者，如果你和我一样，经过上述尝试，仍然没有运气 - DRF 仍然产生该死的http链接。我想分享一些我在调试时的技巧：

在 Django 中打印以下值，可以通过print()， 如果你有DEBUG=True并有权访问服务器日志，或者只是将它们传递到模板上下文并在 html 页面中显示它们，如果这可以让您更轻松地在启用 SSL 的生产环境中进行测试。

• request.is_secure()：如果您无法使用 DRFhttp，你很可能会得到False.
• request.META gives you all headers that Django received. Did the header HTTP_X_FORWARDED_PROTO show up? What value is it?
  • 我想分享的是，这对我来说是一个顿悟时刻：HTTP_X_FORWARDED_PROTO is https,https，这告诉我它以某种方式具有重复的值，并且我可能有proxy_set_header设置两次，宾果游戏！默认情况下，K8 入口控制器已经有这条线，因为我通过location-snippet，现在我有两行proxy_set_header X-Forwarded-Proto $scheme;总共。删除我的代码片段后，DRF 显示https我非常高兴能完成这件事。事情并不是那么简单，因为我想proxy_set_header将覆盖并“设置”标头值。但似乎它只是不断附加。