ios - WiFi 热点 403 错误

Question

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

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

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

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

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

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

有谁知道 header 中是否还有其他任何东西可以检测 403 的来源，或者是否有在未登录热点时重定向请求的标准做法？

编辑

这是我的 Django 服务 header 在 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

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