也许这是一个有点宽泛的问题，但我目前依靠黑暗中的镜头......
我们有时会提供对某些受基本密码保护的 Web URL（运行 Apache 2.4）的访问权限。我自己从未见过这种情况，但我时不时听到外部用户说他们立即地看到401 Unauthorized错误。虽然服务器回复确实是 401 错误代码，但它也附带一个www-authenticate标头，这应该会在用户端触发登录对话框（他们应该在其中输入我们提供的凭据）。在相关情况下，据报道不出现登录对话框。遗憾的是，我从未与受影响的外部用户直接联系，因此无法进行更深入的分析。
- 是否存在某种常见的不理解 www-authenticate 机制的浏览器？ 我可以用吗令人惊讶的是，Sfari 和 Opera 存在问题 - 然而我刚刚对其中一个进行了成功的测试。
- 是否存在其他常见的障碍，例如严格剥离所需 http 标头的防火墙策略？
- 还有其他想法吗在这些情况下可能出现什么问题，或者我可以测试什么？
编辑：关于建议考虑的事项：
- 有问题的 URL 是
https:（我可以说 - 当然吗？） - 问题出现在首次使用的用户身上，即他们一开始就无法“登录”。（尽管如此，我的理解是，缓存的错误密码应该会触发对话框让用户重试）。这似乎也排除了密码管理器问题
- 我怀疑受影响的用户是否已设置好让他们自动尝试使用他们的 Windows 凭据或其他自动登录（对他们而言）外国互联网主机。
答案1
有几件事可以尝试或考虑：
您是否安全地提供这些页面？有一个 GPO 和 Google Workspace 设置仅允许使用 HTTPS 进行基本身份验证 -邮政总局，Chrome 政策
URL 的凭证是否经常更改？可能是因为用户自上次成功登录后没有关闭/重新启动浏览器，因此凭证更改导致 httpauth 缓存不正确并引发问题。
Windows Internet 选项对话框中有一些适用于 Chrome 和 IE 的身份验证设置，可能会导致尝试自动登录。
是否有任何密码管理器可以自动填充登录对话框？
刚刚对一些在线代理和 HTTP 基本身份验证提示进行了一些快速测试，结果好坏参半。有些拒绝加载页面，有些显示自己的登录提示，有些使用内置浏览器提示。这表明配置错误的代理可能会导致不显示登录提示。