WebSocket connection to 'ws://localhost:18245/signalr/connect?transport=webSockets&clientProtocol=1.4&connectionToken=bNDGLnbSQThqY%2FSjo1bt 8%2FL45Xs22BDs2VcY8O7HIkJdDaUJ4ftIc54av%2BELjr27ekHUiTYWgFMfG6o7RaZwhf fpXavzWQ1jvkaxGm5rI%2BWtK7j0g1eQC2aOYP366WmRQLXCiYJfsm4EbwX6T8n2Aw %3D%3D&connectionData=%5B%7B%22name%22%3A%22importerhub% 22%7D%5D&tid=9' Failed: HTTP Authentication Failed; no valid credentials available
有趣的是，我通过Hub通过Controller控制的jquery方法工作正常。
jQuery的：
$(function () {
// Initialize the connection to the server
var importerHub = $.connection.importerHub;
// Preparing a client side function
// called sendMessage that will be called from the server side
importerHub.client.sendMessage = function (message) {
showOrUpdateSuccessMessage(message);
};
$.connection.hub.start();
});
控制器：
var hubContext = GlobalHost.ConnectionManager.GetHubContext<ImporterHub>();
hubContext.Clients.All.sendMessage("All operations complete");
我使用.Net v4.5.1，SignalR v2.1.2.0和IIS 8.5与Windows身份验证。
解决方法
以下是几年前提交的初始问题，报告说Chrome不支持任何形式的HTTP身份验证：
https://code.google.com/p/chromium/issues/detail?id=123862
该问题已经解决了基本和摘要身份验证，但不适用于Windows(NTLM /协商)身份验证。在不到一个月前创建了一个问题，用于跟踪使用WebSockets进行Chrome对Windows身份验证的支持：
https://code.google.com/p/chromium/issues/detail?id=423609
显然，Chrome开发人员渠道部分修复了Windows身份验证问题，但只有客户端在建立WebSocket之前已经对服务器进行了身份验证。
您仍然可以从控制器调用sendMessage的原因是因为当WebSocket连接失败时，SignalR会自动回退到使用除WebSockets之外的传输(即服务器发送的事件或长时间轮询)。 Chrome将正确处理SignalR的其他传输的Windows身份验证。
我建议不要改变任何东西。 Chrome最终将支持WebSockets的Windows身份验证。
除了Chrome控制台中的错误以外，唯一真正的问题是在Chrome中建立SignalR连接可能需要稍长的时间。如果这是一个大问题，您可以随时specify what transports the client should attempt using.所以在Chrome上，您只能尝试serverSentEvents和longPolling，但是当Chrome确实解决问题时，您将不会使用最好的传输，直到您更改代码。
