BrowserID和HTTPS冲突？

Question

我的烧瓶-webapp正在使用BrowserId。当我试图通过将所有传入请求重定向到HTTPS进一步扩展我的应用程序时。HTTPS重定向工作正常，但现在登录功能导致：

登录失败:错误

是什么导致了这个问题？我该怎么做才能修好它？如果有关系的话，这里是我的webapp。。我正在使用Gunicorn作为服务器部署在heroku上。下面是登录失败的heroku日志

Answer 1

我对重定向POST请求的问题并不熟悉，但我怀疑这可能是因为一个。特别是POST请求前端发送到后端。来验证断言。

您可以尝试的一件事(测试上述理论)是让您的应用程序在端口80上不监听，只在443上监听。这样就不会有HTTP和HTTPS以及烧瓶-sslify的混合，而不必重定向任何东西。

Answer 2

您可以尝试的一件事是尝试修改客户机，将其直接发布到HTTPS。

听起来现在可能发生的事情是客户端是HTTPS的POSTing；然后烧瓶-sslify接收HTTP请求，用重定向响应客户端，并触发客户端将POST请求重新发送到HTTPS URL。

您应该能够检查是否正在使用Firebug或Wireshark或任何其他工具来查看客户端正在发出的请求。

如果这是正确的情况，您可以尝试的一件事是更改客户端，以便它可以直接通过HTTPS发布。换句话说，尝试更改客户端，以便通过HTTPS提交初始POST请求，这样它就不会通过HTTP，也不会触发重定向。我建议试一试，看看它是否能解决问题。如果它确实解决了问题，它会给出问题所在的一些提示(可能客户端没有以您想要的方式处理帖子重定向，或者在烧瓶-sslify中有问题；无论如何，这是一个巨大的线索，应该有助于调试问题)。

您可以验证您是否成功地确保客户端首先使用相同的调试工具(例如Firebug或Wireshark)通过HTTPS提交帖子。

一般来说，让客户机直接使用HTTPS (如果可能的话)比依赖服务器发起的重定向将客户机从HTTP重定向到HTTPS要好。它将简化事情，而且也更安全。(如果客户端通过HTTP发送其初始请求，并且依赖服务器发起的重定向，那么您仍然容易受到中间人的攻击。如果客户端的初始请求是通过HTTPS完成的，那么您就不会受到中间人的攻击。简化这样的事情可能会导致bug消失，而且应该不难检查是否确实是这样。

另一方面，如果您的客户机已经是直接到HTTPS的POSTing (如果您的客户端一开始就没有发送任何HTTP请求，并且没有服务器端重定向)，那么我就不知道到底发生了什么。