Question

好了一点实验后我发现树脂正在调用我的AbstractAuthenticator实现“authenticate”方法，该方法使用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相同的哈希值。

Answer 1

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

首先，摘要式身份验证使用user，password，realm，nonce，client_nonce，nonce_count，method，qop和uri。基本上它使用完整的摘要规范。因此，为了计算哈希，必须用所有的哨子计算它。只是从HttpDigestCredentials调用每个变量的get方法，除了用户和密码。用户将以Principal和密码的形式出现，您必须在数据库中自己查找（在我的例子中是DB4O数据库）。

然后你必须创建一个PasswordDigest对象，它将使用getPasswordDigest（）方法生成一个哈希，但首先必须使用passwordDigestObject.setFormat（“hex”）将格式设置为十六进制。

有一个用于HA1 getPasswordDigest（用户，密码，领域），还有另一个getPasswordDigest（）方法只接受一个字符串，一个可以使用它来生成其余的哈希值，包括HA2和前一个哈希值HA1是最后一个哈希值，当然还有nonce nonce_count client_nonce和qop，当然每个都用分号分隔。

然后它是棘手的部分，虽然当你从HttpDigestCredentials调用getResponse（）方法时树脂使用base64编码进行摘要它返回一个字节数组（这很奇怪）所以为了将它与你的哈希进行比较我做了什么使用org.apache.commons.codec.binary.Hex中的Hex.encodeHexString（）方法并传递HttpCredentialsDigest getResponse（）返回值，这将给出一个很好的十六进制字符串进行比较。

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

使用CustomAuthenticator进行Caucho树脂摘要认证，有人请赐教

1 个答案: