Chrome 87无法针对Windows IIS 10在CORS中进行Windows身份验证 [英] Chrome 87 is failing Windows Authentication in CORS against Windows IIS 10
问题描述
Chrome 86(及更低版本)，Edge，Curl和IE都能够针对Windows 2019计算机上的IIS 10 ASP.NET服务执行跨源Windows身份验证，而没有任何问题.
Chrome 86 (and prior), Edge, Curl, and IE all are able to do cross-origin Windows Authentication against my IIS 10 ASP.NET service on Windows 2019 machine without any problem.
但是Chrome 87失败，并通过CORS策略阻止了从来源"http://[DIFFERENT]"访问"https://[REDACTED]"处的XMLHttpRequest:No'Access-Control-Allow-Origin标头出现在所请求的"
But Chrome 87 fails with "Access to XMLHttpRequest at 'https://[REDACTED]' from origin 'http://[DIFFERENT]' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested"
很奇怪-Chrome 87可以与配置相同的Windows 2008计算机(不要问)上的IIS 7.5中运行的相同ASP.NET服务一起使用.
更新:注意-我意识到[2020-12-04]系统碰巧位于一个已经添加到我的始终可以使用Cookie的站点"的域中，列表.因此，修复"从一开始就盯着我... ...)
使用curl-我看不到Windows身份验证的IIS响应之间的任何区别.
Using curl - I can't see any difference between the IIS responses for Windows Authentication.
如果我入侵了我的ASP.NET，并且对所有请求(而不是主要请求)都包含回显的Access-Control-Allow-Origin'http://[DIFFERENT]'，则Chrome 87发出401-未经授权-而不是来回进行Windows身份验证.Curl和其他浏览器也可以使用其他标头.
If I hack my ASP.NET and have it include a echoed Access-Control-Allow-Origin 'http://[DIFFERENT]' to all requests instead of the main one - then Chrome 87 barks a 401 - not authorized - instead of continuing with the Windows Authentication back and forth. Curl and the other browsers are just fine with the additional headers.
直接调用网站(无跨域)效果很好.
Invoking the website directly (without cross-origin) works just fine.
任何人都知道Chrome 87在做什么不同吗?开发工具仅显示最后"消息.链中的请求-因此我不知道发生故障之前发生了什么.
Anyone have a clue what Chrome 87 is doing different? The Dev Tools only shows the "last" request in the chain - so I don't know what is happening prior to the failure.
更新:[2020-12-02] 很明显，Chromium团队声称它正在按照需要的方式工作...但是对我来说，这似乎很奇怪.
https://bugs.chromium.org/p/chromium/issues/detail?id = 1154281
"这现在是预期的行为-阻止第三方cookie现在就像设置crendials:忽略第三方请求一样.我们将看到有多少关于此的报告，但是以前的行为是有问题的，因为真正的非凭据请求和那些提供HTTP身份验证凭据但没有cookie的请求将共享套接字."
推荐答案
我们在我们的环境中看到了同样的情况，Chrome 87现在将cookie规则应用于Kerberos和NTLM身份验证(显然是一个错误).这不仅影响XHR，还影响从另一个站点加载的任何资源(图像，iframe等).
We are seeing the same in our environment, Chrome 87 is now applying the cookie rules to Kerberos and NTLM authentication (clearly a bug). This is affecting not just XHR but any resource loaded from another site (images, iframes, etc).
我们有阻止第三方Cookie"设置并发现将受影响的站点和域添加到始终可以使用cookie的站点"中，Chrome中的列表已恢复身份验证；这是我们可以接受的解决方法，因为我们通过组策略管理Chrome，并且可以轻松推出更新的网站列表.
We have "Block third-party cookies" set and have found that adding affected sites and domains to the "Sites that can always use cookies" list in Chrome has restored authentication; and is an acceptable workaround for us since we manage Chrome via Group Policy and can push out an updated list of sites easily.
2020-12-02:截止到今天，MS Edge 87表现出相同的行为.
2020-12-02: As of today MS Edge 87 exhibits the same behaviour.
这篇关于Chrome 87无法针对Windows IIS 10在CORS中进行Windows身份验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
