好的，经过一点实验，我发现resin正在调用我的AbstractAuthenticator实现"authenticate"方法，该方法采用HttpDigestCredentials对象而不是DigestCreCredentials（仍然不知道何时调用它们中的每一个）。问题是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中的哈希相同的哈希。
好吧，我终于成功了。奇怪的主题啊，只有两种观点？
首先，摘要身份验证使用user、password、realm、nonce、client_nonce、nonce_count、method、qop和uri。基本上，它使用了完整的摘要规范。因此，为了计算哈希，必须使用所有的口哨来计算它。只需要为HttpDigestCredentials中除用户和密码之外的每个变量调用get方法。用户将以主体和密码的形式出现，您必须自己在DB（在我的情况下是DB4O数据库）中查找该密码。
然后，您必须创建一个PasswordDigest对象，该对象将负责使用getPasswordDigests（）方法生成哈希，但第一个对象必须使用passwordDigestObject.setFormat（"hex"）将格式设置为hex。
有一个用于HA1的getPasswordDigest（user，password，realm），还有另一个getPasswordDigest（）方法，只需要一个字符串，就可以使用它来生成其余的哈希，HA2和上一个哈希的HA1都是最后的哈希，当然还有nonce nonce_count client_nonce和qop，当然每一个都用分号分隔。
然后是棘手的部分，尽管resin在从HttpDigestCredentials调用getResponse（）方法时使用base64编码进行摘要，但它返回一个字节数组（这很奇怪），所以为了将其与哈希进行比较，我使用了org.apache.commons.codec.binary.Hex中的Hex.encodeHexString（）方法，并传递HttpCredentialsDigest getResponce（）返回值，这将提供一个很好的十六进制字符串进行比较。
我是用另一种方式来做的，我使用PasswordDigest中的Base64哈希，并将HttpDigestCredentials哈希转换为Base64，结果字符串永远不一样。