[SignalR] How Hubs interact with HttpContext

[analogrelay]

We should have a document describing the complex interations between Hubs and HttpContext.

• In a Hub you can get an HttpContext via Context.GetHttpContext() extension method, but it's not guaranteed to work
• Long Polling uses a "simulated" context
• There's no context at all when using Azure SignalR
• IHttpContextAccessor should be avoided
• SignalR has some support for non-HTTP transports (nothing officially supported yet but some future ideas) and those wouldn't even have an HttpContext so it's considered a good design practice to avoid using HttpContext at all in Hubs (to allow portability to non-HTTP transports)

[BrennanConroy]

As part of this, we should talk about grabbing things like the access_token and placing it in a claim if the user wants to access that in the Hub.

[bfcamara]

@BrennanConroy These recommendation still applies? When using HTTP protocols (Websockets, SSE, LongPolling), is it possible to not have a HttpContext inside the hub?

[legistek]

How can a server authenticate a user without the http context and access to the http headers used to initiate the connection initially if they're using a custom authentication mechanism? This makes it impossible for me to use the Azure SignalR service now, and would make it impossible for me to use SignalR at all if you told me in the future I can't get the Httpcontext anymore.

[legistek]

As part of this, we should talk about grabbing things like the access_token and placing it in a claim if the user wants to access that in the Hub.

If you can do that, then make the entire set of headers accessible?

We need Authorization and cookies at minimum, plus every frontend framework has a different X-XSRF mechanism that's usually header based.

You can't just put this stuff in the SignalR messages. With httponly cookies for example Javascript cannot access the token, by design.