ApplicationContext.User lost inside razor component when switching to Azure SignalR Service

[j055]

Created a bug report:

#2007

[rockfordlhotka]

Ahh, this is perhaps a better place to discuss.

I've never done this @j055 - how does the SignalR server get the user principal/identity?

(as in: I've never manually created a signalr server, so I don't know how the tech works or gets the user identity from the client)

[j055]

I think the article is suggesting you grab what state you need from HttpContext on initial page render and pass a custom class to the root razor component which will look after it while the client is connected to the SignalR service, wherever it may be.

I'm wondering if we can keep this state in memory and reference it using the Circuit Id by implementing a custom CircuitHandler?

https://docs.microsoft.com/en-us/aspnet/core/blazor/advanced-scenarios?view=aspnetcore-5.0

I haven't really got my head round it yet though - still at the 'bouncing ideas around' stage. Questions so far:

• Would we need a new IContextManager - what does implementation look like?
• Can we avoid creating a custom ComponentBase to set ApplicationContext properties?
• Does AuthenticationStateProvider help - https://docs.microsoft.com/en-us/aspnet/core/blazor/security/?view=aspnetcore-5.0#implement-a-custom-authenticationstateprovider
• What about LocalContext and ClientContext?

I'm sure there a more?!

[rockfordlhotka]

Wait a minute - you are NOT talking about a custom signalr server, you are just using server-side Blazor? Or are you using a custom signalr server?

Normal SSB is stateful on the server, so storing the user principal/identity is basically a non-issue, because it is just there in memory. I show how to make this work in my Blazor book, and there's just a little config required.

I assumed (incorrectly?) that you were talking about a more complex scenario with some external signalr server outside of the one created and managed by SSB.

[j055]

Yes an external service: Azure SignalR Service. If you need your app to be scalable in production then you would most likely consider this service.

There's quite a bit of noise out there about why you shouldn't use HttpContext in a SignalR connection, see below. It's bad that you can get HttpContext to work in development with SignalR and then find that its broken when you upgrade to an external SignalR service. There shouldn't be anything more than a config change and the tooling in Visual Studio tries to make it super easy to scale out to Azure SignalR when you publish to an App service.

dotnet/aspnetcore#12724 (comment)
dotnet/AspNetCore.Docs#14974

[rockfordlhotka]

Is that compatible with SSB though?

[j055]

We recommend using the Azure SignalR Service for Blazor Server apps. The service allows for scaling up a Blazor Server app to a large number of concurrent SignalR connections. In addition, the SignalR service's global reach and high-performance data centers significantly aid in reducing latency due to geography.

https://docs.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/server?view=aspnetcore-5.0#deployment

[rockfordlhotka]

OK, now that (at least I) understand that this is a server-side Blazor app configured to use an external SignalR (via Azure) backbone, I'm happy to try and sort out what's happening - though this is a busy time in my day job because it is the annual kickoff for the year, etc. So my time is limited, so I'm happy to offer thoughts, but can't do research.

I've never configured this sort of setup, and I don't know how the SSB state is managed when the SignalR messaging is flowing somewhere other than to the web server. Does SSB manage the state on the backbone server instead of the web server?

And in any case, taking CSLA out of the equation, how does SSB and/or SignalR normally manage the current user identity in this scenario? This is the core question

Remember that CSLA doesn't actually manage the current user identity in aspnetcore scenarios. CSLA relies entirely on aspnetcore to maintain the user identity, and the ApplicationContext.User property is just an abstraction that points to the aspnetcore-managed ClaimsPrincipal.

So once we understand how and where the user principal/identity are stored by aspnetcore and/or SignalR, then it might be necessary to create a CSLA context manager for this scenario.

I am going to close the bug/issue, because right now I don't see where there's a work item to be done - I, at least, don't know that any changes to CSLA are required.

[j055]

@rockfordlhotka I appreciate your thoughts and time on this. I have a pretty heavy workload too but I will try to mock up a prototype based on what I know so far. Yes I think we can pass state/identity to the SignalR service. There are also ways to send state to the client to store using browser APIs (even for SSB). I think it would be good to allow the web server to be stateless and use the SignalR service over websocket to be stateful and find a low impact way of transferring state between the two. Maybe an intelligent context manager is required.

I have a meeting with MS support tomorrow about this so I'll try to find out as much as I can from them. I'll post any updates or findings here.

[j055]

This is not an answer yet but a reference to the recommended way to pass state to a (sever-side) Blazor app. It also provides a statement about NOT using IHttpContextAccessor within Blazor apps.

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/http-context?view=aspnetcore-5.0

Additionally, again for security reasons, you must not use IHttpContextAccessor within Blazor apps. Blazor apps run outside of the context of the ASP.NET Core pipeline. The HttpContext isn't guaranteed to be available within the IHttpContextAccessor, nor is it guaranteed to be holding the context that started the Blazor app.

The recommended way to pass request state to the Blazor app is through parameters to the root component in the initial rendering of the app:

Define a class with all the data you want to pass to the Blazor app.
Populate that data from the Razor page using the HttpContext available at that time.
Pass the data to the Blazor app as a parameter to the root component (App).
Define a parameter in the root component to hold the data being passed to the app.
Use the user-specific data within the app; or alternatively, copy that data into a scoped service within OnInitializedAsync so that it can be used across the app.