SignalR 不适用于 Windows 集成身份验证 [英] SignalR not working with Windows-integrated authentication

问题描述

我有一个 ASP.NET MVC 4 应用程序 (.NET 4.5) 并且 SIGnalR 可以与基于表单的身份验证(通过 IIS/IIS Express 托管)一起正常工作

I have an ASP.NET MVC 4 app (.NET 4.5) and SIgnalR works fine with forms-based authentication (hosted via IIS/IIS Express)

一旦我将应用程序更改为 Windows 集成身份验证(web.config"中的 <authentication mode="Windows"/>)，它就会停止工作.

As soon as I change the app to windows-integrated authentication (<authentication mode="Windows"/> in "web.config") it stops working.

jquery.signalR-2.2.2.min.js:9 WebSocket 连接到 ws://localhost:51030/signalr/connect?transport=webSockets&blhablahblah失败:WebSocket 握手期间出错:意外响应代码:403

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] 属性添加到我的集线器后，错误更改为

After adding the [Authorize] attribute to my hub, the error changes to

WebSocket 连接到 ws://localhost:51030/signalr/connect?transport=webSocketsblahblah 失败:HTTP 身份验证失败；没有可用的有效凭据

WebSocket connection to ws://localhost:51030/signalr/connect?transport=webSocketsblahblah failed: HTTP Authentication failed; no valid credentials available

应用程序的其他部分运行良好，服务器上启用了 windows-auth 并且可以正常工作，等等.

Other parts of the app are working just fine, windows-auth is enabled on the server and works, etc. etc.

我该如何解决这个问题?

如果由于某种原因无法解决(可能是 Chrome 不支持 websocket 连接上的 Windows 身份验证或其他原因) - 为什么它不回退到非 websocket 协议?我要强制回退吗?

And if it is unsolvable for some reason (it could be Chrome not supporting windows auth on websocket connections or something else) - why doesn't it fall back to non-websocket protocol? and how do I force the fallback?

更新:我创建了一个 github 问题 https://github.com/SignalR/SignalR/issues/3953.问题不是我无法连接.问题是我无法处理回退到另一个传输的错误..fail() 和 .error() 都没有被调用.Try-catch 也无济于事.

UPDATE: I created a github issue https://github.com/SignalR/SignalR/issues/3953. The problem is not that I can't connect. The problem is that I cannot handle the error to fall back to another transport. Neither .fail() not .error() are being invoked. Try-catch doesn't help either.

推荐答案

2020 年更新:看起来 Chrome 现在支持 WS 连接上的 NTLM，不再是问题

Update from 2020: looks like Chrome now supports NTLM on WS-connections, not an issue any more

... 10 小时后提出问题...

部分解决(回答我自己的问题)

使用它后我可以确认，将 [Authorize] 属性添加到我的集线器(或者，将 GlobalHost.HubPipeline.RequireAuthentication(); 添加到您的Startup.cs")实际上确实有帮助.它现在确实回退到替代传输，即使错误仍然被抛出到浏览器的控制台.

After playing with it I can confirm, that adding the [Authorize] attribute to my hub (or alternatively, adding GlobalHost.HubPipeline.RequireAuthentication(); to your "Startup.cs") actually does help. It does fall back now to an alternative transport, even though the error is still thrown into the browser's console.

您还可以通过调用指定哪个传输:

You can also specify which transport it falls back to, by calling:

$.connection.hub.start( { transport: ['webSockets', 'longPolling'] });

如果您不喜欢默认优先级(我猜，隐藏 iframe"是默认的第二个选项).

in case you don't like the default priority (I guess, "hidden iframe" is the default second option).

原因

该错误是由 Chrome 引起的，它不支持 websocket 连接上的 NTLM.有趣的是，IE、MS Edge 和 Firefox 确实支持它(Chrome 是新的 IE"哈).

The error is caused by Chrome, it does not support NTLM on websocket connections. Funny enough, IE, MS Edge and Firefox do support it ("Chrome is the new IE" huh).

Chromium bugtracker 中存在一个未解决的问题 https://bugs.chromium.org/p/chromium/issues/detail?id=423609 如果有人想向 Chromium 开发者添加任何输入.

There's an open issue in Chromium bugtracker for this here https://bugs.chromium.org/p/chromium/issues/detail?id=423609 if anyone wants to add any input to Chromium devs.

这篇关于SignalR 不适用于 Windows 集成身份验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！