Does BlazorSignalR support authentication?
DNF-SaS opened this issue · 6 comments
As far as I can see, opening the websocket-connection does not transport any headers (-> no auth-token transmitted). Using LongPolling, it works fine.
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?
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.
@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.
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?)
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.
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.