SignalR not working with Windows-integrated authen

Question

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

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 connection to ws://localhost:51030/signalr/connect?transport=webSockets&blhablahblah failed: Error during WebSocket handshake: Unexpected response code: 403

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

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

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

How do I solve this?

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?

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.

Answer 1

I too was experiencing this error, but only when developing locally using http; I think Chrome doesn't like unsecured ws:// connections. Once I deployed to server with secure https connection, the WebSocket connection was upgraded to wss://, and Chrome stopped complaining, worked fine with WebSockets--didn't have to fall back to other transport.

tl:dr; Make sure to use https for your site.

Answer 2

...10 hours later...

Partially solved (answering my own question)

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'] });

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

The reason

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).

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.