我遇到过在IIS6上运行ASP.NET 3.5的大型内部企业基于Web的应用程序的情况,生成401“未授权”响应,然后是200“Ok”响应(由Fiddler描述)。我知道为什么会发生这种情况(集成auth强制浏览器重新发送凭据)但我正在寻找一些关于如何最小化或根除情况的想法。有问题的应用程序在WAN中运行,一些用户遇到的延迟时间高达250毫秒,因此强制后续请求会对页面加载时间产生明显影响,尤其是当页面上有许多级联下拉列表时。 / p>
应用程序的用户是托管桌面环境内部的,因此从部署角度来看,可以强制浏览器在第一个请求上发送凭据(这是否可能?)。这适用于需要用户身份但不需要身份验证的资源(WebResource.axd,ScriptResource.axd和一些自定义Web服务)的页面,允许匿名身份验证。我已经看过在web.config中基于每个位置定义这个,但结果是混合的(仍然是401个响应)。
对于处理这种情况的“最佳实践”,我表示感谢。有很多资源可以识别问题,但我找不到提供可行解决方案的资源。
谢谢!
编辑:可以通过向Web配置添加位置条目匿名请求不需要身份验证的资源(即用于级联下拉列表的Web服务),但我还没有找到经过身份验证的资源的答案。
答案 0 :(得分:16)
不幸的是,这是HTTP NTLM authentication scheme的一件神器。
简而言之,浏览器(Internet Explorer或其他方式)不知道它需要进行身份验证,直到它被包含WWW-Authenticate
响应标头的401响应退回。
在WWW-Authenticate: NTLM
的情况下 - 令人讨厌 - 它需要在单个持久连接上完成两个 401响应,并且一旦HTTP持久连接完成,就必须重复此过程关闭。因此,即使您能够让浏览器发起盲目尝试NTLM的请求,也不能从事务中删除至少一个401响应。
我认为最好的办法是最大限度地延长持久连接在空闲时保持打开的时间。
答案 1 :(得分:3)
CSCRIPT.EXE c:\ inetpub \ adminscripts \ ADSUTIL.VBS SET W3SVC / AuthPersistSingleRequest FALSE
将显着减少401的数量。
答案 2 :(得分:0)
我相信您可以说服Firefox通过“about:config”设置自动将NTLM凭据发送到列入白名单的域集 - 使用“network.automatic-ntlm-auth.trusted-uris”设置。我自己也没试过。我不确定Internet Explorer是否有任何等价物。
不幸的是,如果您使用其他类似Kerberos的东西,似乎没有办法避免使用。
答案 3 :(得分:0)
如果401引发的延迟太长,您可能需要考虑表单身份验证。用户必须明确登录,但只需登录一次。然后你可以使用cookie或cookieless方案并在第一次尝试时获得响应。
我想如果你有级联下拉菜单,你的初始页面加载会填充一个值,导致POST获取下一个列表,设置该值,另一个POST再次获取下一个列表,并且等等。如果是这种情况,也许您需要在第一次往返时填充所有这些下拉菜单而不是等待POST响应。
答案 4 :(得分:0)
TL; DR我将HTTP标头信息放在HTTP正文中
我的示例在Angular中,但是任何TypeScript / JavaScript(框架)都可能有相同的问题。
在对后端API进行HTTP后调用时,该操作要求标头包含已登录的用户信息,我在我的HTTP正文应为HTTP标头且标头为空的地方添加了HTTP标头。
问题
markInstructionAsCompleted(visitScheduleId: string, instructionId: number) {
return this.http.post(`${environment.apiUrl}/VisitInstructions/schedule/${visitScheduleId}/done/${instructionId}`, this.getHeaderWithAuthorization());
}
解决方案,请注意,HTTP post调用中添加了第二个参数,即null
markInstructionAsCompleted(visitScheduleId: string, instructionId: number) {
return this.http.post(`${environment.apiUrl}/VisitInstructions/schedule/${visitScheduleId}/done/${instructionId}`, null, this.getHeaderWithAuthorization());
}