3

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

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

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

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

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

第二种情况更困难，我看不出有什么办法知道403起源。

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

编辑

这是我的 Django 服务标头在 a 上的样子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=/
4

1 回答 1

1

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

于 2013-04-30T19:08:21.203 回答