SignalR 不适用于 Windows-集成身份验证
SignalR not working with Windows-integrated authentication
我有一个 ASP.NET MVC 4 应用程序 (.NET 4.5)，SIgnalR 可以很好地处理基于表单的身份验证（通过 IIS/IIS Express 托管）
一旦我将应用程序更改为 windows-集成身份验证（"web.config" 中的 <authentication mode="Windows"/>），它就会停止工作。
jquery.signalR-2.2.2.min.js:9 WebSocket connection to ws://localhost:51030/signalr/connect?transport=webSockets&blhablahblah failed: Error during WebSocket handshake: Unexpected response code: 403
将 [Authorize] 属性添加到我的集线器后，错误变为
WebSocket connection to ws://localhost:51030/signalr/connect?transport=webSocketsblahblah failed: HTTP Authentication failed; no valid credentials available
应用程序的其他部分工作正常，windows-auth 在服务器上启用并工作，等等
我该如何解决？
如果由于某种原因无法解决（可能是 Chrome 不支持 windows websocket 连接上的身份验证或其他原因）- 为什么它不回退到非 websocket 协议？ 以及如何强制回退？
更新：我创建了一个 github 问题 https://github.com/SignalR/SignalR/issues/3953。问题不是我无法连接。问题是我无法处理返回到另一个传输的错误。 .fail() 和 .error() 都没有被调用。 Try-catch 也无济于事。
2020 年的更新：看起来 Chrome 现在支持 WS 连接上的 NTLM，不再是问题
...提问10小时后...
部分解决（回答我自己的问题）
玩过之后我可以确认，将 [Authorize] 属性添加到我的集线器（或者，将 GlobalHost.HubPipeline.RequireAuthentication(); 添加到您的“Startup.cs”）确实有帮助。 它现在确实回落 到替代传输，即使错误仍然抛入浏览器的控制台。
您还可以指定它返回到哪个传输，方法是调用：
$.connection.hub.start( { transport: ['webSockets', 'longPolling'] });
如果您不喜欢默认的优先级（我猜，“隐藏的 iframe”是默认的第二个选项）。
原因
错误是由Chrome引起的，它不支持websocket连接上的NTLM。有趣的是，IE、MS Edge 和 Firefox 确实支持它（“Chrome 是新的 IE”，呵呵）。
Chromium bugtracker 中有一个未解决的问题https://bugs.chromium.org/p/chromium/issues/detail?id=423609如果有人想向 Chromium 开发人员添加任何输入。
我也遇到了这个错误，但只是在使用 http 进行本地开发时；我认为 Chrome 不喜欢不安全的 ws:// 连接。一旦我部署到具有安全 https 连接的服务器，WebSocket 连接升级到 wss://，并且 Chrome 停止抱怨，与 WebSockets 一起工作得很好——不必退回到其他运输。
tl:博士；确保为您的站点使用 https。
我有一个 ASP.NET MVC 4 应用程序 (.NET 4.5)，SIgnalR 可以很好地处理基于表单的身份验证（通过 IIS/IIS Express 托管）
一旦我将应用程序更改为 windows-集成身份验证（"web.config" 中的 <authentication mode="Windows"/>），它就会停止工作。
jquery.signalR-2.2.2.min.js:9 WebSocket connection to
ws://localhost:51030/signalr/connect?transport=webSockets&blhablahblahfailed: Error during WebSocket handshake: Unexpected response code: 403
将 [Authorize] 属性添加到我的集线器后，错误变为
WebSocket connection to
ws://localhost:51030/signalr/connect?transport=webSocketsblahblahfailed: HTTP Authentication failed; no valid credentials available
应用程序的其他部分工作正常，windows-auth 在服务器上启用并工作，等等
我该如何解决？
如果由于某种原因无法解决（可能是 Chrome 不支持 windows websocket 连接上的身份验证或其他原因）- 为什么它不回退到非 websocket 协议？ 以及如何强制回退？
更新：我创建了一个 github 问题 https://github.com/SignalR/SignalR/issues/3953。问题不是我无法连接。问题是我无法处理返回到另一个传输的错误。 .fail() 和 .error() 都没有被调用。 Try-catch 也无济于事。
2020 年的更新：看起来 Chrome 现在支持 WS 连接上的 NTLM，不再是问题
...提问10小时后...
部分解决（回答我自己的问题）
玩过之后我可以确认，将 [Authorize] 属性添加到我的集线器（或者，将 GlobalHost.HubPipeline.RequireAuthentication(); 添加到您的“Startup.cs”）确实有帮助。 它现在确实回落 到替代传输，即使错误仍然抛入浏览器的控制台。
您还可以指定它返回到哪个传输，方法是调用：
$.connection.hub.start( { transport: ['webSockets', 'longPolling'] });
如果您不喜欢默认的优先级（我猜，“隐藏的 iframe”是默认的第二个选项）。
原因
错误是由Chrome引起的，它不支持websocket连接上的NTLM。有趣的是，IE、MS Edge 和 Firefox 确实支持它（“Chrome 是新的 IE”，呵呵）。
Chromium bugtracker 中有一个未解决的问题https://bugs.chromium.org/p/chromium/issues/detail?id=423609如果有人想向 Chromium 开发人员添加任何输入。
我也遇到了这个错误，但只是在使用 http 进行本地开发时；我认为 Chrome 不喜欢不安全的 ws:// 连接。一旦我部署到具有安全 https 连接的服务器，WebSocket 连接升级到 wss://，并且 Chrome 停止抱怨，与 WebSockets 一起工作得很好——不必退回到其他运输。
tl:博士；确保为您的站点使用 https。