search

csnewman / BlazorSignalR

SignalR Core C# client Blazor compatibility
MIT License
64 stars 21 forks source link

Does BlazorSignalR support authentication? #1

Closed DNF-SaS closed 6 years ago

DNF-SaS commented 6 years ago

As far as I can see, opening the websocket-connection does not transport any headers (-> no auth-token transmitted). Using LongPolling, it works fine.

csnewman commented 6 years ago

Currently authentication is handled via a query parameter (access_token) in WebSocketsTransport.ts

You are correct about headers not being transmitted. Does authentication not work for you with websockets?

springy76 commented 6 years ago

I have an ASP.NET Core 2.1 server which accepts multiple authentication schemes: Basic auth, a custom API token header, NTLM/Kerberos via IIS and maybe OpenAPI when 2.2 is out.

A desktop app using official SignalR by .WithUrl(uri, options => options.Headers.Add(key,value)) works as expected: I can use both Basic auth or custom API token header and the SignalR requests are authorized.

Doing the same in a blazor app using .WithBlazorUrl() works when forcing long polling, but with web sockets some of the negotiate requests are authorized correctly but the final upgrade request expecting 100 continue comes in as unauthorized (no custom headers at all) - so authentication does not work for me using websockets.

csnewman commented 6 years ago

@springy76 Yeah, custom headers are currently not supported in either server side events or websockets. It should be something easy enough to implement. I'm unsure when I'll get the time, so feel free to submit a PR.

DNF-SaS commented 6 years ago

ATM, only long polling is possible without JS? So I suppose, you did header-transport only with C#-implemented long polling? (in other words: header-transport has to be implemented mainly in TS/JS?)

csnewman commented 6 years ago

Basically, atm, the c# implementations are just the signalr .net client implementations and then the JS implementations are based heavily on the signalr js/ts client.

The real issue is that the JS websocket (and I think eventsource) does not support setting headers. This is why the auth token is encoded as a query parameter, just like in the SignalR Core TS client.

csnewman commented 6 years ago

I do not see any bug here, as authorisation works with all the support transport mechanisms. Setting of headers is not possible due to a webbrowser limitation, and instead the token is encoded as a query parameter.

If there is a bug, please open a new issue with it, however for now I'm going to close this issue.