403 WiFi热点出错

Question

我有一个iOS应用程序通过XMLRPC连接到Django服务器（该协议并不重要）。身份验证通过标准Cookie保留，并由AFNetworking通过NSURLConnection透明地处理。当请求验证失败时，Django XMLRPC库会返回403错误，当发生这种情况时，应用程序会向用户显示登录页面。这种方法已经好几年了。

最近出现了连接到WiFi热点但未通过热点进行身份验证的用户的问题。他们加载了应用程序，并显示了登录页面，该页面必须是从热点返回的403错误的结果。如果他们首先使用热点进行身份验证，那么一切正常。

我正在尝试找到一种解决方案，以防止我的应用将此类403错误解释为失败的身份验证。我假设发生了两件事之一：

• 热点重定向到返回403错误的网址;或
• 热点会立即返回403错误。

通过屏蔽301和302重定向，可以轻松管理第一种方案。幸运的是，AFNetworking使这很容易。

第二种情况比较困难，我认为无法知道403来自哪里。

有没有人知道标题中是否有其他内容可以检测403的来源，或者是否有标准做法在未登录热点时重定向请求？

修改

以下是我在403上的Django服务标题：

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服务器的响应中添加一个自定义标头，并验证客户端中的标头，以确保它来自服务器而不是热点。