Tastypie的POST请求返回非SSL位置标头 [英] POST request to Tastypie returns a non-SSL Location Header

问题描述

我正在对我的Tastypie api做一个POST请求，它创建一个资源。
它通常通过响应中的Location头返回资源uri。
我遇到的问题是位置标题包含一个非ssl url，即使我的初始请求（和我的整个应用程序）都在https下。

从我的请求标题：

  URL：https://example.com/api/v1/resource/ 
  

从我的回复标题：

 位置：http://example.com/api/v1/resource/80/ 
  

因为这是一个可重用的应用程序，并不总是在ssl下运行，我不想硬编码一个丑的字符串替换。此外，已经有一个301重定向到位，从http到https，但是我不想重定向发生。

所有帮助赞赏！

更新：
这实际上与Tastypie没有任何关系，这是因为服务器/代理配置。

解决方案

原因很简单：看似 request.is_secure（）在您的情况下返回 False ，因此URL使用 http 而不是 https 。

有几种解决方案，但您应该首先找到导致 request.is_secure ）返回 False 。我敢打赌你在一些代理或负载平衡器后面运行。如果您没有更改URL生成背后的逻辑，那么这可能是您的问题的原因。

要解决这个问题，您可以查看 SECURE_PROXY_SSL_HEADER 设置Django 定义标头，表示与代理或负载平衡器建立的SSL连接：

如果您的Django应用程序在后面代理服务器可能会使用代理服务器和Django之间的非HTTPS连接吞没请求为HTTPS的事实。在这种情况下， is_secure（）将始终返回 False - 即使是通过HTTPS完成的请求用户。

在这种情况下，您需要配置代理设置自定义HTTP头，告知Django请求是否通过HTTPS进入，您将要设置 SECURE_PROXY_SSL_HEADER ，以便Django知道要查找的头。

但是，如果您正在设计一个可重复使用的应用程序，并且上述在您的情况下是正确的，请确保它不是不同的。如果您确定是这种情况，请将其留给用户 - 负责安全请求指示的标头应该明确设置，只能由使用您的应用程序的程序员设置。否则这可能意味着一个安全问题。

I am doing a POST request to my Tastypie api, which creates a resource. It normally returns the resource uri, through the Location header in the response. The problem I'm having is the Location header contains a non-ssl url, even though my initial request (and the whole of my application) is under https.

From my request headers:

URL: https://example.com/api/v1/resource/

From my response headers:

Location: http://example.com/api/v1/resource/80/

Because this is a reusable application that is not always running under ssl, I do not want to hardcode an ugly string replace. Also, there is already a 301 redirect in place, from http to https, but I do not want the redirect to happen.

All help appreciated!

Update: This actually didn't have anything to do with Tastypie, it was because of the servers/proxy configuration. See answer below for resolution details.

解决方案

The reason is simple: seemingly request.is_secure() returns False in your case, so the URL is constructed using http instead of https.

There are couple of solutions, but you should first find what caused request.is_secure() to return False. I bet you are running behind some proxy or load balancer. If you did not change the logic behind URL generation, then this is probably the cause of your issue.

To fix that, you can take a look at SECURE_PROXY_SSL_HEADER setting in Django, which defines headers that indicate the SSL connection established with the proxy or load balancer:

If your Django app is behind a proxy, though, the proxy may be "swallowing" the fact that a request is HTTPS, using a non-HTTPS connection between the proxy and Django. In this case, is_secure() would always return False -- even for requests that were made via HTTPS by the end user.

In this situation, you'll want to configure your proxy to set a custom HTTP header that tells Django whether the request came in via HTTPS, and you'll want to set SECURE_PROXY_SSL_HEADER so that Django knows what header to look for.

But if you are designing a reusable app and the above is correct in your case, just make sure it is not something different. If you are sure this is the case, then leave that to the user - the headers responsible for secure request indication should be set explicitly, only by the programmer who uses your app. Otherwise this could mean a security issue.

这篇关于Tastypie的POST请求返回非SSL位置标头的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！