在iPhone上使用HTTP摘要式身份验证

Question

我有一个应用程序与使用HTTP摘要身份验证的服务器通信.

在我看来,iPhone中的"会话"管理对于我们的开发人员来说是相当"黑盒子".是不是我们无法看到框架如何处理/持久化http会话？

如果我只是在这里昏暗,有人会解释如何在iPhone上处理HTTP摘要身份验证吗？

我的基本操作是:

• 向安全网址发出请求
• 服务器发送401
• 客户端创建并保留凭证,并将其传递回服务器
• 服务器验证凭证,验证完成请求,否则发送另一个401.
• 发出后续请求以保护网址
• 服务器再次请求授权........

这适用于单个请求,但如果我发出其他后续请求,则服务器再次请求授权.服务器已经为特定用户持久保存了会话,但是iPhone由于某种原因没有在同一会话中发出请求...因此,服务器必须抛弃认证对象并在每次客户端创建一个新对象向安全网址发出请求.

我确定这不是正确的行为.

如果我们看一下浏览器在这种情况下的行为:

• 浏览器从安全URL请求数据
• 服务器发送401
• 浏览器提示用户输入凭据,持久保存,将其传递给服务器
• 服务器验证凭证,如果验证则返回数据,否则发送另一个401.
• 由于浏览器管理会话,因此不会提示对安全URL发出的后续请求提供凭据.

我正在创建NSURLCredential并将其保留在NSURLCrendtialStorage中.然后,当应用程序收到'didReceiveAuthenticationChallenge'时,我从存储中检索凭证并将其传回,如果不存在(在第一个请求中),则创建凭证.

任何帮助将不胜感激.谢谢.

Answer 1

首先，忘记 HTTP 会话，因为它们不与摘要式身份验证主动登录交互（有一种会话信息功能，但它是不同的）。

\n\n

事实上，使用 Digest 的主要原因之一是不必仅使用会话来维持登录状态。会话量很大并且会损害可扩展性。

\n\n

我无法确定您的问题是什么，但我确实知道我首先要检查的内容是正确使用过时的内容和正确创建随机数。

\n\n

如果用户代理被要求处理相同的随机数，则用户代理只能处理身份验证而无需重新查询用户，或者在另一种情况下我将在稍后介绍（按此顺序更容易解释）。

\n\n

如果您在每个请求中使用相同的随机数，则用户代理将继续使用它以及用户/通行证中的“ha1”来请求后续资源。这是在\xc3\xabmptive 之前完成的，因此挑战永远不会发生。

\n\n

当然，使用相同的随机数会带来不安全因素，因为重放攻击对于任何可以嗅探流量的人来说都变得微不足道。随机数必须定期更改。

\n\n

因此，如果您收到来自用户代理的请求，该请求具有无效的授权标头，但其无效的原因是随机数错误（它使用的是过期的随机数），那么在您的挑战中包括“stale=true” （默认为 false）。这会通知用户代理您拒绝的原因是随机数已过时（当然其他信息也可能是错误的，但这并不重要，因为您不会让它以任何方式播放）。

\n\n

收到这样的 stale=true 时，用户代理将知道它未获得授权，但不会重新查询用户（或者如果它是无 UI 组件，则抛出异常），而是会使用新标准重试旧标准随机数。

\n\n

我无法判断这些是否会影响您，但随机数和过时性的确定和表示方式肯定是我首先要考虑的事情。

\n