Blazor WASM - Upgrading from CSLA 6 to CSLA 8 - Setting ApplicationContext User throws Not Supported Exception

[saulyt]

I have a Blazor WASM app that I am upgrading CSLA 8. I use AddMsalAuthentication to setup login with Azure AD and AddAccountClaimsPrincipalFactory to set a custom ClaimsPrincipalFactory. In my claims principal factory, I am overrideing the CreateUserAsync method and setting the ApplicationContext as such

ApplicationContext appcontex = _serviceProvider.GetService<Csla.ApplicationContext>();
appcontex.User = user;

This code throws an unsuported exception in when I attempt to upgrade to CSLA 8. If I remove the line that sets the user everything works, but I then lose the user when I navigate from one page (component) to the next.

I assume this somehow relates to this but I don't really understand that discussion and also that was not a WASM app.

What would be the correct way to set the user in a CSLA 8 Blazor WASM app so that I would not lose the identity after the initial login?

For clarity as to what I am doing here is the entire method:

        public async override ValueTask<ClaimsPrincipal> CreateUserAsync(TAccount account, RemoteAuthenticationUserOptions options)
        {
            var user = await base.CreateUserAsync(account, options);
            if (account != null)
            {
                var identity = user.Identity as ClaimsIdentity;
                if (_appUser == null)
                {
                    var userPortal = _serviceProvider.GetService<IDataPortal<User>>();
					_appUser = await userPortal.FetchAsync(User.GetEmailAddress(identity));
				}
                if(_appUser != null)
                {
                    ApplicationContext appcontex = _serviceProvider.GetService<Csla.ApplicationContext>();
                    appcontex.User = user;
                    foreach (var claim in _appUser.Claims)
                        identity?.AddClaim(new Claim(claim.ClaimType, claim.ClaimValue));
                }
            }
            return user;
        }

[rockfordlhotka]

The reason CSLA no longer allows setting the User or Principal properties in Blazor webassembly is because the only way to reliably maintain the user principal in that runtime is through the use of an AuthenticationStateProvider. Specifically, a custom provider, and so there's no standard API by which CSLA can set the principal into an unknown implementation of this provider.

Here's an example of a custom AuthenticationStateProvider: https://github.com/JasonBock/BlazorTopToBottom/blob/main/src/Rocky/BlazorAuthentication/BlazorAuthentication/BlazorAuthentication.Client/ServerAuthenticationStateProvider.cs

In that example, the provider is calling a server endpoint to get the user principal object on request. How you authenticate the user and where you create that authenticated ClaimsPrincipal/ClaimsIdentity pair can vary a lot, and that's why there's no way for CSLA to set the value.

fwiw, I talk about this in my VS Live Blazor talks and in my online Blazor class.

[rockfordlhotka]

That should be correct. That implementation is here:

https://github.com/MarimerLLC/csla/blob/v8.x/Source/Csla.Blazor.WebAssembly/ApplicationContextManager.cs

You can see that it always attempts to retrieve the current principal from the AuthenticationStateProvider, and only falls back to using any internally stored value if the state provider can't provide the value.

I suppose we could be more aggressive and throw an exception if the state provider isn't available, but I don't think that would be good either.

My guess though, is that there's some issue with the state provider in the app, where it isn't providing the principal (or the correct principal) at all times?

[saulyt]

I modified my comment above as after login the CSLA ApplicationContext.User does have all the claims that were added. (It was cut off from my log.) The only issue is that when refreshing the page the CSLA ApplicationContext.User is empty.

I think the issue is that when the page is refreshed and Msal Authentication retrieves the user from the session data rather than doing a full login, the AuthenticationStateProvider.AuthenticationStateChanged event is never raised. As such ApplicationContextManager.AuthenticationStateProvider_AuthenticationStateChanged never gets called to set the AuthenticationState in the ContextManager.

[rockfordlhotka]

That sounds like something worth bringing up on the Blazor github (or searching there) to see if there's a known solution or if this is an oversight.

Can your code know that a refresh happened? If so, perhaps we can make a way for your code to tell the context manager to refresh the value.

[rockfordlhotka]

Another thing that occurs to me, that you could try, is to use a context manager that does not cache the principal. Maybe that would be better?

Specifically here:

csla/Source/Csla.Blazor.WebAssembly/ApplicationContextManager.cs

Line 77 in 85162c1

if (_currentPrincipal == null)

Rather than maintaining any reference to the current principal, the code could just always return the value from the task (if available).

[saulyt]

Yes, that does work. I copied the ApplicationContextManager class, removed the if statement, and registered IContextManager to use my custom implementation. When doing this everything works as expected on a browser refresh. Is there any benefit to caching the principal?

Thank you!

[rockfordlhotka]

I don't think there is any value, so we should change this - I'm glad you got a working solution!