0

好的，经过一番试验后，我发现树脂正在调用我的 AbstractAuthenticator 实现“身份验证”方法，该方法采用 HttpDigestCredentials 对象而不是 DigestCredentials （仍然不知道何时调用它们中的每一个）问题是 HttpDigestCredentials 没有有一个 getDigest() 方法，而是有一个 getResponse() 方法，该方法不返回哈希值或至少不返回可比较的哈希值。

创建我自己的 [[user:realmassword] [nonce] [method:uri]] 哈希后，哈希非常不同，实际上我认为 getResponse() 不会返回摘要，但可能是服务器对浏览器的响应？

无论如何，这是我的调试日志：

USER:user:PASSWORD:password:REALM:resin:METHOD:GET:URI/appe/appe.html:NONCE:HsJzN+j+GQD:CNONCE:b1ad4fa1ba857cac88c202e64528bc0c:CLIENTDIGEST:[B@5dcd8bf7:SERVERDIGEST:I4DkRCh21YG2Mk14iTe+hg==

如您所见，假定的客户端 nonce 与服务器生成的 nonce 非常不同，实际上客户端 nonce 看起来根本不像 MD5 哈希。

请问以前有人做过吗？HttpDigestCredentials 中是否缺少某些内容？我知道摘要几乎没有使用。

拜托，我知道 SSL，但我还没有 SSL 证书，所以不要告诉我“你为什么不使用 SSL”。;)

更新：

不确定这样做是否正确，但正如我之前读到的，Resin 使用 base64 格式的哈希值，所以我使用 apache commons-codec-1.6 来使用 encodeBase64String() 方法，现在哈希值看起来很相似，但它们不一样。

我都试过了passwordDigest.getPasswordDigest(a1+':'+nonce+':'+a2); passwordDigest.getPasswordDigest(a1+':'+nonce+':'+ncount+':'+cnonce+':'+qop+':'+a2);

并且它们都没有给出与 HttpDigestCredentials 中的哈希值相同的哈希值。

4

1 回答 1

0

好吧，我终于成功了。奇怪的主题 咦，只有两种观点？

首先，摘要式身份验证使用用户、密码、领域、nonce、client_nonce、nonce_count、method、qop 和 uri。基本上它使用完整的摘要规范。因此，为了计算哈希，必须用所有的口哨来计算它。只需为 HttpDigestCredentials 中的每个变量调用 get 方法，用户和密码除外。用户将以委托人的形式出现，密码您必须自己在数据库中查找（在我的情况下为 DB4O 数据库）。

然后您必须创建一个 PasswordDigest 对象，该对象将负责使用 getPasswordDigest() 方法生成哈希，但首先必须使用 passwordDigestObject.setFormat("hex") 将格式设置为十六进制。

HA1 有一个 getPasswordDigest(user,password,realm) 方法，还有另一个 getPasswordDigest() 方法，它只接受一个字符串，可以使用它来生成其余的哈希值，包括 HA2 和之前的哈希值 HA1 hash，当然用nonce nonce_count client_nonce 和qop，当然每一个用分号隔开。

然后是棘手的部分，尽管当您从 HttpDigestCredentials 调用 getResponse() 方法时，resin 使用 base64 编码进行摘要，但它返回一个字节数组（这很奇怪），因此为了将它与您的哈希进行比较，我所做的是使用来自 org.apache.commons.codec.binary.Hex 的 Hex.encodeHexString() 方法并传递 HttpCredentialsDigest getResponse() 返回值，这将提供一个很好的十六进制字符串进行比较。

我是反过来做的，我使用 PasswordDigest 中的 Base64 哈希并将 HttpDigestCredentials 哈希转换为 Base64，结果字符串永远不会相同。

于 2012-02-16T18:55:32.720 回答