是否可以将 Digest-Authentication 与 XMLHTTPRequest 一起使用？答案

【问题标题】：Is it possible to use Digest-Authentication with a XMLHTTPRequest?是否可以将 Digest-Authentication 与 XMLHTTPRequest 一起使用？
【发布时间】：2011-11-01 20:08:38
【问题描述】：

我有一个简单的问题：是否可以将 Digest-Authentication 与 XMLHTTPRequest 一起使用？

如果答案是否定的，技术原因是什么？或者如果可能的话 - 我该怎么做？

非常感谢……谷歌目前还没有好的答案：-/

编辑：

感谢您的回答。在收到随机数后修改标头以匹配摘要身份验证方案似乎是一种解决方案。

但我真正想要的是我可以更改我当前的调用： xmlhttp.open("GET", url, false, username, password); 对某事像那个 xmlhttp.open("GET", url, false, username, password, "DIGEST");

这也是我最初的问题的一部分：为什么 open-method 不提供进行摘要请求的选项？

也许有一个 js-lib 可以推荐让我这样做 - 正如你想象的那样，我真的不想将一个简单的 xmlhttp.open 更改为多个请求并首先获得一个随机数。

【问题讨论】：

到目前为止你尝试过什么？如果您的服务器页面需要 Digest auth（向未经身份验证的请求返回 401），并且您将用户名和密码传递给 XHR open() 调用，那么一切都应该正常。
你做到了吗？我真的很感激一些代码。谢谢！

标签： javascript http xmlhttprequest web

【解决方案1】：

你可以做到没有问题。只需遵循您喜欢的规范部分；)
https://www.rfc-editor.org/rfc/rfc2617
开始在客户端编写您的身份验证库
http://pajhome.org.uk/crypt/md5/
所缺少的一切。

预交换用户名和密码
嘿，我要认证 ----> 服务器
好的，这是一个 nonce/salt ----> 客户端
这是我的用户名密码时间戳和盐的 md5 哈希总和 -----> 服务器
我只是以与您相同的方式设置了您的密码和用户名，它们是相同的 ----->client
这些是它的基础。

我遗漏了您需要在哈希和中包含所请求资源的 URI！！！！
当然，您对向服务器发出的每个资源请求都执行此操作，这样拦截散列的人只能查看您请求的内容而无法请求杂项资源。此方法不能保护仅访问的数据给它。

【讨论】：

我不同意。任何人都可以向服务器请求一个随机数。您希望如何安全地将其传输到客户端？
您 dont it is just to make it more difficult to figure out your password from the md5 and make each authentication attempt unique. http://en.wikipedia.org/wiki/Cryptographic_nonce. This way some one can not man in the middle you hash and re authenticate with it at another time. In fact they use a nonce in Oauth. I know what you are thinking thats 仍然完全不安全，但这种身份验证的目的只是为了保留您的用户名和密码。这是非常基本的。
我想补充一点，这个摘要方法需要服务器知道密码。如需更安全的方法，请参阅 rfc8146

【解决方案2】：

看看这篇文章：https://web.archive.org/web/20130227152456/http://marcin-michalski.pl/2012/11/01/javascript-digest-authentication-restful-webservice-spring-security-javascript-ajax/。它解释了如何在服务器端使用 SpringSecurity 为摘要身份验证做 JavaScript 客户端。代码在github上：https://github.com/Arrowgroup/JSDigestAuth

【讨论】：

这是最好的答案。指向完成所有工作并提供完整源代码的某人的帖子（通过非常简单的方法对其进行测试）
是的，除了链接现在已经死了，回答也没用。

【解决方案3】：

我为此编写了一个完整的工作流程，一旦您使用 MD5 的外部库（我使用 Crypto-js），这一点都不难。

您可能遇到的最大问题是，在第一个服务器 401 回复上，任何最常用的浏览器都会打开一个对话框来获取您的凭据。据我所知，没有简单的方法可以规避这一点：How can I supress the browser's authentication dialog?

为了解决这个问题，我修改了从 C# codeplex 项目中编码的网络服务器。在第一个请求中，客户端传递了一个“警告”标头，上面写着“不要引发 401”。服务器创建挑战并使用自定义的非 401 HttpException 将其发送回（我目前使用 406，这在 HTTP 中是“不可接受的”）。客户端创建哈希并将其发送回。

如果有人感兴趣，我可以发布一些代码 sn-ps，这是一个老问题。

【讨论】：

这对于 Safari 来说似乎不是这样，当它通过 XHR 收到 401 时。
“这个”是什么意思？ "this" = "浏览器也会为 XHR 401 打开一个对话框"？如果是这种情况，则不需要警告标题技巧。广泛兼容的解决方案仍需要解决方法。

【解决方案4】：

最好的方法是使用 SSL。我认为不存在任何其他安全的解决方案（如果我错了，请纠正我）

【讨论】：

Digest 比 Basic + SSL 更安全！查看 RFC 2617，安全部分。
如果没有 SSL，MitM 攻击者（例如，恶意或受损的代理；例如在公共 WiFi 接入点）可以将任意 JavaScript（或简单的链接）注入 HTML。这样，攻击者的请求将来自用户的浏览器，因此服务器将没有任何机会判断这些是来自用户的不是。攻击者甚至不需要知道密码。

【解决方案5】：

只要你的浏览器支持，你真的不应该关心网站使用哪种身份验证方法。

如果您指定用户名和密码来打开方法并且不与 Authorization 头混淆，XMLHttpRequest.send() 将首先尝试发送未经身份验证的请求，接收带有 WWW-Authenticate 头的 401 响应，然后重试请求，提供名称根据网站要求的授权方式和密码。

（尽管在这个两阶段过程中可能会触发一些额外的事件处理程序）。

【讨论】：

【解决方案6】：

为避免默认浏览器身份验证对话框，您只需将 WWW-Authenticate 设置为 Digest/YourString（例如您的领域）。这一切都在第一个响应中，并不那么悲惨。我的自定义代码直到昨天都运行良好，现在我正在尝试调试突然发生的奇怪事情，仍然试图理解..

【讨论】：