支持或弃用 URL 中的 HTTP 基本身份验证

Question

在一个项目中，我们花费了大量精力来解决基本身份验证问题（因为 webdriver 测试依赖于它，而 webdriver 没有用于基本身份验证的 api），我记得 URL 中的基本身份验证显然不起作用。 IE。无法加载http://username:password@url

只要谷歌“url 中的基本身份验证”，你就会发现很多人在抱怨：https://medium.com/@lmakarov/say-goodbye-to-urls-with-embedded-credentials-b051f6c7b6a3

https://www.ietf.org/rfc/rfc3986.txt

不推荐在 userinfo 字段中使用“user:password”格式。

今天我把这个泥潭告诉了一个朋友，他说他们在 webdriver 测试中使用http://username:password@url 风格的基本身份验证没有任何问题。 我使用当前的 Chrome v71 进入演示页面，令我惊讶的是，我发现它确实运行良好：https://guest:guest@jigsaw.w3.org/HTTP/Basic/

这怎么可能？？我们是否同时生活在平行维度中？ 哪一个是正确的：是否支持或不推荐使用 URL 中的凭据进行基本身份验证？（或者由于我找不到任何参考的投诉，这可能会被添加回 Chrome？）

Answer 1

基本上，已弃用并不意味着不受支持。

哪一个是正确的：使用 URL 中的凭据进行基本身份验证是支持还是弃用？

答案是肯定的，两者都是正确的。它已被弃用，但在大多数情况下（据说）仍受支持。

---

来自中篇文章：

虽然您通常不会在页面中硬编码这些内容，但当您打开 https://user:pass@host 之类的 URL 并且该页面向通过相对路径链接的资源发出后续请求时，这些资源也将获得user:pass@ 部分应用于他们并被 Chrome 禁止。

这意味着像<img src=./images/foo.png> 这样的网址，而不是像<a href=/foobar>zz</a> 这样的网址。

RFC 规范指出：

在用户信息字段中使用格式“用户：密码”是 已弃用。应用程序不应将任何数据呈现为明文 在用户信息中找到的第一个冒号 (":") 字符之后 子组件，除非冒号后面的数据是空字符串 （表示没有密码）。应用程序可以选择忽略或 当收到此类数据作为参考的一部分时，拒绝此类数据，并且 应拒绝以未加密的形式存储此类数据。这 以明文形式传递身份验证信息已被证明是 几乎在所有使用它的情况下都存在安全风险。

为了用户反馈而呈现 URI 的应用程序，例如 在图形化超文本浏览中，应该以一种方式呈现用户信息 在可行的情况下，将其与 URI 的其余部分区分开来。这样的 渲染将在用户信息已被删除的情况下为用户提供帮助 被误导为看起来像受信任的域名 （第 7.6 节）。

因此，不鼓励使用 user:pass@url，并有具体的建议和禁用使用的原因作为支持。它还声明应用程序可以选择拒绝 userinfo 字段，但它并没有说应用程序必须拒绝这个。