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

Question

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

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

\n

\n

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

\n

\n

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

\n\n

来自媒体文章：

\n

\n

虽然您通常不会在页面中硬编码这些内容，但当您打开类似 https://user:pass@host 的 URL 并且该页面对通过相对路径链接的资源发出后续请求时，\xe2\x80\x99s 当这些资源将还可以将 user:pass@ 部分应用到他们身上并被 Chrome 禁止。

\n

\n

这意味着 url like<img src=./images/foo.png>但不是 url like<a href=/foobar>zz</a>。

\n

RFC 规范指出：

\n

\n

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

\n

在可行的情况下，为了用户反馈而呈现 URI 的应用程序（例如图形超文本浏览）应该以与 URI 的其余部分区分开来的方式呈现用户信息。当用户信息被误导性地设计为看起来像受信任的域名时，这种\n呈现将帮助用户（第 7.6 节）。

\n

\n

因此，不鼓励使用 user:pass@url，并通过具体建议和禁用原因来支持。它还指出应用程序可以选择拒绝用户信息字段，但并没有说应用程序必须拒绝这一点。

\n