当应用程序托管在 IIS（协商 + NTLM）上时，两个 401（Unauth）响应后跟一个 200（OK）响应

Question

我的情况与Eradicating 401 "Unauthorised" responses followed by 200 "Ok" responses中提到的情况非常相似

但它并没有为我们提供足够的回应。

我有一个简单 GET 请求的示例，当通过在没有 IIS 的情况下在本地运行 api 进行时，会产生一个响应，即 OK/200： Fiddler trace here

但是当它托管在 IIS 上时，它会返回两个 401 和一个 200：Fiddler trace here

这里还有 IIS 网络身份验证配置：Config

在调用 API 的应用程序中，我们检查 200 响应代码，我们在代码中收到间歇性的 200/401，这使得验证非常烦人，请求在每种情况下都能完美通过。

非常感谢这里的任何帮助，如果这是 NTLM 身份验证的工作方式，是否有任何其他方法来验证对 api 的调用最终是否成功？最后，这就是我们想在调用者应用程序中了解的内容。

正如一些文章中提到的，我尝试将 NTLM 移动到 IIS -> 身份验证 -> 提供程序列表中的提供程序列表顶部（底部协商），但这并不能解决此问题

感谢观看。

编辑：这是 fiddler 中 IIS 的请求标头：

1. 使用 401 请求 1：img
2. 使用 401 请求 2：img
3. 请求 2 和 200：img

编辑 2：根据 MisterSmith 的回答和其他阅读，这就是 NTLM 身份验证的工作方式，更多的是关于我们如何处理应用程序中的响应。

在我的情况下，我使用 .net core HttpClient 库发出请求，它处理 NTLM 身份验证的方式可能存在问题。 如果有人对此感兴趣，可以在这里找到：NTLM authentication HttpClient in Core

Answer 1

这基本上就是它的工作原理 - 用户的前 2 个握手请求尚未成功通过身份验证，因此 401 是预期的并且完全合理。

如果您可以（以某种方式）让浏览器始终发送身份验证标头（仅针对此站点！），这将删除一个 401，另一个是不可避免的，而无需完全放弃 NTLM。

在您的情况下，在本地运行和在 IIS 中运行之间的区别在于身份验证模块正在拦截和修改标头。如果您要在 IIS 中关闭身份验证，它也会返回单个 200 响应（这是一个测试而不是解决方案，原因很明显）。

代码中的 200/401 让验证非常烦人

401、401、200 将按顺序来自同一个套接字。如果您查看 401 上的响应标头，您应该能够确认哪些是预期的。 IIS 在访问日志和 IIS 中运行的代码的请求上下文中也有一个可见的子状态。很确定您可以根据子状态条件和标头进行重写 - 这可能有助于区分请求作为最后的手段？

还有其他方法可以验证对 api 的调用是否成功 最终

NTLM 使用保持活动套接字发送多个请求 - 只需继续从套接字读取直到合理的超时并存储收到的最终响应代码。

将 NTLM 移至提供商列表的顶部

我不确定更改顺序会做什么，但有些事情让我很震惊-system.webServer/security/authentication/windowsAuthentication 部分被锁定是很常见的，因此 web.config 级别的更改将被忽略并且需要为applied at the machine.config level。