与WiFi热点相关的403号错误

Question

我有一个iOS应用程序，它通过XMLRPC连接到Django服务器(协议并不重要)。身份验证使用标准cookie持久化，并由AFNetworking通过NSURLConnection透明地处理。当请求身份验证失败时，Django XMLRPC库返回一个403错误，当这种情况发生时，应用程序将向用户显示一个登录页面。这一方法几年来一直运作良好。

最近，一个连接到WiFi热点但没有通过热点进行身份验证的用户出现了问题。他们加载了应用程序，并显示了登录页面，这肯定是403错误从热点返回的结果。如果他们首先使用热点进行身份验证，那么一切都很好。

我正试图找到一种解决方案，以防止我的应用程序将此类403错误解释为失败的身份验证。我猜想有两件事正在发生：

• 热点重定向到返回403错误的URL；或
• 热点立即返回一个403错误。

第一种情况很容易通过阻止301和302重定向来管理。幸运的是，AFNetworking使得这很容易。

第二种情况比较困难，我看不出403起源于何处。

有没有人知道头中是否还有其他东西来检测403的起源，或者在没有将请求重定向到热点时是否存在重定向的标准做法？

编辑

下面是我的Django服务头在403上的样子

HTTP/1.1 403 FORBIDDEN
Server: nginx
Date: Sun, 28 Apr 2013 07:21:34 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 0
Connection: keep-alive
Vary: Cookie
Set-Cookie: sessionid=5a5ce154d1229e40c3773e8f6999a32d; expires=Sun, 18-Aug-2013 07:21:34 GMT; httponly; Max-Age=9676800; Path=/

Answer 1

我能找到的最简单的解决方案是在来自Django服务器的响应中添加一个自定义头，并在客户机中验证报头，以确保它来自服务器而不是热点。