Circular Dependency on ApplicationContext

[saulyt]

I am upgrading a Blazor WASM app to CSLA 6.1 and I am having an issue with a circular dependency on ApplicationContext. I am using Azure AD for authentication with a ClaimsPrincipalFactory for getting the users application claims from the database once authenticated. I am injecting an IDataPortal<User> into the ClaimsPrincipalFactory and using that for retrieving the claims. If I am reading this correctly it seems that ApplicationContext is dependent on Microsoft.AspNetCore.Components.WebAssembly.Authentication.RemoteAuthenticationService which I am ultimately making dependent on my custom ClaimsPrincipalFactory, which in turn is dependent on ApplicationContext via the IDataPortal<User> I am injecting.

I am looking for advice on how to set this up differently to avoid the circular dependency. If need be I can retrieve the claims via a separate web service end point without using CSLA, but I am hoping for a better solution.

Error Message:

System.InvalidOperationException: A circular dependency was detected for the service of type 'Csla.ApplicationContext'.
Csla.ApplicationContext -> Csla.Core.ApplicationContextAccessor -> System.Collections.Generic.IEnumerable<Csla.Core.IContextManager> -> Csla.Core.IContextManager(Csla.Blazor.WebAssembly.ApplicationContextManager) -> Microsoft.AspNetCore.Components.Authorization.AuthenticationStateProvider(Microsoft.AspNetCore.Components.WebAssembly.Authentication.RemoteAuthenticationService<Microsoft.AspNetCore.Components.WebAssembly.Authentication.RemoteAuthenticationState, Microsoft.AspNetCore.Components.WebAssembly.Authentication.RemoteUserAccount, Microsoft.Authentication.WebAssembly.Msal.Models.MsalProviderOptions>) -> Microsoft.AspNetCore.Components.WebAssembly.Authentication.AccountClaimsPrincipalFactory<Microsoft.AspNetCore.Components.WebAssembly.Authentication.RemoteUserAccount>(AppClaimsPrincipalFactory<Microsoft.AspNetCore.Components.WebAssembly.Authentication.RemoteUserAccount>) -> Csla.IDataPortal<MyLibrary.User>(Csla.DataPortal<MyLibrary.User>) -> Csla.ApplicationContext

This is setup up via:

builder.Services.AddMsalAuthentication(options =>
{
    builder.Configuration.Bind("AzureAd", options.ProviderOptions.Authentication);
    options.ProviderOptions.....
    options.ProviderOptions.....
}).AddAccountClaimsPrincipalFactory<AppClaimsPrincipalFactory<RemoteUserAccount>>();

My ClaimsPrinipalFactory looks like this:

public class AppClaimsPrincipalFactory<TAccount> : AccountClaimsPrincipalFactory<TAccount> where TAccount : RemoteUserAccount
{
	private readonly IDataPortal<User> _userPortal;
	public AppClaimsPrincipalFactory(IAccessTokenProviderAccessor accessor, IDataPortal<User> userPortal)
	: base(accessor)
	{
		_userPortal = userPortal;
	}
	private static bool Done = false;
	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;
				var appUser = await _userPortal.CreateAsync();
				appUser = await appUser.FetchByEmail(identity);
				foreach (var claim in appUser.Claims)
					identity?.AddClaim(new Claim(claim.ClaimType, claim.ClaimValue));
		}
		return user;
	}
}

Thanks you.

[rockfordlhotka]

In a Blazor runtime the IContextManager implementation does require the ApplicationContextManager service, because that's what has the API to get at the current user.

And the ApplicationContext service requires/contains an IContextManager, to get at the per-runtime behavior for accessing the current user (and other per-platform things).

And a lot of things, including the client-side data portal, make use of ApplicationContext, because that's the app state and also the way to get at the user identity, and much more.

I suspect the easiest way to break the cycle is to have AppClaimsPrincipalFactory ask for the current service provider, and then you can use that service provider to call GetRequiredService<ApplicationContext> - so it isn't injected during construction.

UPDATE - that probably won't work either will it? That'll still cause a circular reference, just at a different point.

So yeah, you might need to use a non-CSLA service.

Or maybe defer loading of the current user - do as I suggest here, but make sure the CreateUserAsync method completes so the object graph is completed before actually loading the user identity?

[saulyt]

Thanks @rockfordlhotka. That was definitely an easy solution. I've had it so ingrained that using service locator is an anti-pattern that I didn't think of it.