BlazorSS app w/ ref to Csla.AspNetCore : Null Reference error when using a Hosted service with timer

[swegele]

Issue: When my BSS app has a reference to Csla.AspNetCore then I get (at startup) a Null Reference error in Csla.AspNet ApplicationContextManager.cs Line 121 because HttpContext is NULL because the code that calls it is initiated inside a Hosted service (e.g. no request and thus not HttpContext).

I'm not sure this is a bug, so posting here as a question. This hosted service has a timer causing it to run at app startup and then every n minutes afterwards (refreshes translations from db).

Here is the Hosted service:

using Microsoft.Extensions.Options;
using TestBlazor.Configuration;

namespace TestBlazor.Services.Translation;

public class TranslationsRefreshService : IHostedService
{
    private System.Threading.Timer? _timer;
    private readonly IServiceScopeFactory _serviceProvider;
    private readonly TranslationsLoadedStatusService _tranlationLoadedStatus;
    private readonly TestBlazorConfiguration _config;

    public TranslationsRefreshService(IServiceScopeFactory serviceProvider, TranslationsLoadedStatusService tranlationLoadedStatus, TestBlazorConfiguration config)
    {
        _serviceProvider = serviceProvider;
        _tranlationLoadedStatus = tranlationLoadedStatus;
        _config = config;
    }

    public Task StartAsync(CancellationToken cancellationToken)
    {

        // timer repeats call to DoWork on scheduled basis (minimum 5 minutes)
        int time = (_config.LocalizationRefreshMinutes < 5) ? 30 : _config.LocalizationRefreshMinutes;
        _timer = new Timer(
            DoWork,
            null,
            TimeSpan.Zero,
            TimeSpan.FromMinutes(time)
        );

        return Task.CompletedTask;
    }

    public Task StopAsync(CancellationToken cancellationToken)
    {
        _timer?.Change(Timeout.Infinite, 0);

        return Task.CompletedTask;
    }

    private void DoWork(object? state)
    {
        //business objects are scoped services while this IHostedService is a singleton...so we have to create a scope here so we can fetch scoped services
        using (var scope = _serviceProvider.CreateScope())
        {
            try
            {
                var sp = scope.ServiceProvider;
                var translationRecordFactory = sp.GetRequiredService<TranslationRecordInfoListFactory>();
                LoadFreshTranslations(translationRecordFactory).Wait();
            }
            catch (Exception ex)
            {
                Common.JTTracing.WriteErrorToTraceWithMessageAndCallerInfoAndTimestamp("Error loading/refreshing translations", ex);
            }
            finally
            {
                _tranlationLoadedStatus.FirstTranslationsLoadAttemptCompleted = true;
            }
        }
    }

    public async Task LoadFreshTranslations(TranslationRecordInfoListFactory translationsFactory)
    {
         //... fetch from db and refresh engine
    }
}

Here is its registration in Program.cs

builder.Services.AddHostedService<TestBlazor.Services.Translation.TranslationsRefreshService>(); //Refresh translations service

I noticed if I remove the reference to Csla.AspNetCore then that error goes away.
But then the trouble is there is no BSS friendly ApplicationContextManager, so every time you call ApplicationContext you get a new instance which wipes out whatever you try to store in it.

So to get around this I first removed the reference to Csla.AspNetCore.
Then I got to thinking...well since all user stuff is "scoped" in BSS, why can't I create my own "Scoped" BlazorApplicationContextManager like so:

The registration in Program.cs

builder.Services.AddScoped<Csla.Core.IContextManager, BlazorApplicationContextManager>();

And here is the class

public class BlazorApplicationContextManager : IContextManager
{
    private System.Security.Principal.IPrincipal Principal { get; set; }
    private ContextDictionary LocalContext { get; set; } = new ContextDictionary();
    private ContextDictionary ClientContext { get; set; } = new ContextDictionary();
    private ApplicationContext _applicationContext { get; set; }
    private Guid _guid = Guid.NewGuid(); //testing to see unique instances in DI

    /// <summary>
    /// Creates an instance of the object, initializing it
    /// with the required IServiceProvider.
    /// </summary>
    /// <param name="httpContextAccessor">HttpContext accessor</param>
    public BlazorApplicationContextManager()
    {
    }

    /// <summary>
    /// Gets the current principal.
    /// </summary>
    public System.Security.Principal.IPrincipal GetUser()
    {
        var result = Principal;
        if (result == null)
        {
            result = new Csla.Security.CslaClaimsPrincipal();
            SetUser(result);
        }
        return result;
    }

    /// <summary>
    /// Sets the current principal.
    /// </summary>
    /// <param name="principal">Principal object.</param>
    public void SetUser(System.Security.Principal.IPrincipal principal)
    {
        Principal = principal;
    }

    /// <summary>
    /// Gets the local context.
    /// </summary>
    public ContextDictionary GetLocalContext()
    {
        return LocalContext;
    }

    /// <summary>
    /// Sets the local context.
    /// </summary>
    /// <param name="localContext">Local context.</param>
    public void SetLocalContext(ContextDictionary localContext)
    {
        LocalContext = localContext;
    }

    /// <summary>
    /// Gets the client context.
    /// </summary>
    /// <param name="executionLocation"></param>
    public ContextDictionary GetClientContext(ApplicationContext.ExecutionLocations executionLocation)
    {
        return ClientContext;
    }

    /// <summary>
    /// Sets the client context.
    /// </summary>
    /// <param name="clientContext">Client context.</param>
    /// <param name="executionLocation"></param>
    public void SetClientContext(ContextDictionary clientContext, ApplicationContext.ExecutionLocations executionLocation)
    {
        ClientContext = clientContext;
    }

    /// <summary>
    /// Gets or sets a reference to the current ApplicationContext.
    /// </summary>
    public virtual ApplicationContext ApplicationContext
    {
        get
        {
            return _applicationContext;
        }
        set
        {
            _applicationContext = value;
        }
    }

    public bool IsValid => true;
}

That works great - so far so good.

So I guess my questions are:

1. Could the CslaOptions.AddServerSideBlazor() be made to cause the use of a scoped ApplicationContextManager that is BSS friendly?
2. Should that Null reference error be better handled in the AspNetCore ApplicationContextManager in case someone else ends up with non-request triggered code which causes NULL HttpContext?
3. Am I doing something dumb here?

Thanks y'all.

[rockfordlhotka]

I'm not sure how to maintain context in this case - where some code needs to rely on HttpContext and some code needs to rely on something else (I don't know what actually).

How would you implement this scenario?

Or to put it another way, where would you maintain state (like the current user) in a hosted service? Where does the current user come from in that case?

[swegele]

In my particular case, the hosted service fetch of TranslationInfoList (read-only list) is not a protected/secured call, so no user login is required.

I suppose if I actually needed a user, I would have to build that into the hosted service. Would have to first do a kind of "utility login" before doing the fetch and configure the utility login credentials through configuration.

The simple "BlazorApplicationContextManager" I made seems to work great though. It just stores it's own stuff since it is a scoped service. I did some tracking with opening like 3 windows and watching all of the private GUIDs to make sure each one matched the right request. Seemed good to me.
But I don't know what would happen if I were to mix in some Razor Pages with this BSS app? Maybe things get more tricky then?

You must be thinking of functionality that requires HttpContext built in that I haven't bumped into yet...like Authorization stuff that looks for cookies or something. I don't know how you keep it all in your head Rocky!! You're a machine :-)

[TheCakeMonster]

Indeed he is.

I suspect he is also GitHub Copilot. GitHub have convinced everyone that they have created an AI-powered developer tool, but it's all a lie. It's really just Rocky typing in the code people need really fast.

[TheCakeMonster]

Based on my work on the Csla tests, I might be able to help with an idea. It's a bit of a cheat - and not absolutely ideal - but you could create your own ServiceCollection for the hosted service to use, rather than using the root one.

It turns out - and of course I learned this from Rocky! - that creating your own DI container isn't all that hard. If you create an instance of ServiceCollection, configure it the way you want, and then call Build() on it, you get a ServiceProvider that will do DI in a different way to what is going on elsewhere. This is what I do in the unit tests now, so that different unit tests can run with different configuration.

Using this trick, you could create your own ServiceProvider to use within your background/hosted service. That ServiceProvider could be configured with a different implementation of IContextManager that doesn't go anywhere near HttpContext.

The best way to do this would be to refactor your config code in Startup.cs (or Program.cs, is it now?) so that all of your DI config is in an extension method (extending IServiceCollection) that you can call from anywhere. Then, you can use the extension method from both your original startup code AND from your hosted service. This way, all of the config is guaranteed to be the same. After the extension method in the hosted service has run in your hosted service, add a registration for a different implementation of IContextManager, build it and use that ServiceProvider instance to do your DI in the hosted service.

Rough pseudo-code:

// In a new file, or whatever
public static class AllMyLovelyConfigurationExtensions
{
	public static IServiceCollection AddAllMyLovelyConfiguration(IServiceCollection services)
	{
		// TODO: Add ALL of your DI config here, including ...
		services.AddCsla();
	}
}

// In Startup.cs:
services.AddAllMyLovelyConfiguration();

// In your hosted service
IServiceCollection services = new ServiceCollection();
services.AddAllMyLovelyConfiguration();
services.AddSingleton<IContextManager, ApplicationContextManagerStatic>(); // Overrides the default, because it's registered later
IServiceProvider serviceProvider = services.Build();

// TODO: Use serviceProvider to instantiate anything you need from DI, including IDataPortal<T>
var translationRecordFactory = sp.GetRequiredService<TranslationRecordInfoListFactory>();
...

[TheCakeMonster]

Answers to other questions, or maybe other answers to the same questions ...

I'm guessing this is Csla5?

The reason you end up with a context manager that is looking in HttpContext is because Csla tries to load an appropriate one automatically by asking for types that might or might not exist in series, until one is found. Because you have a reference to Csla.AspNetCore, the type that implements IContextManager from within that assembly answers the call to arms during startup. The one that makes sense in AspNetCore is the one that uses HttpContext, so that that should explain the behaviour you are seeing.

1. The call to AddServerSideBlazor() does add a BSS-friendly ApplicationContextManager, I think, at least in Csla 6. The problem is that your hosted service isn't in Blazor, it's in its own little world of disconnectedness, so even that won't help.
2. I think this is probably going to be a bit less of an issue for you in Csla 6, because it's going to use a different ApplicationContextManager in 6 for BSS. However, your point about returning a slightly more helpful error message might be valid, because if you aren't using Blazor but instead MVC, WebAPI or whatever, this error would still occur in 6 in those scenarios. A hosted service can be used in (almost) any host, but it doesn't play by the same rules as that host.
3. No, but even if you were, I'd plead the 5th amendment, even though I'm a Brit and this is an American solution ;-)

[TheCakeMonster]

This looks like confirmation; even if it works sometimes, Microsoft recommend not using IHttpContextAccessor in their security docs.

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/http-context?view=aspnetcore-6.0#blazor-and-shared-state

[swegele]

Good find @TheCakeMonster ...couldn't remember where I saw that strong line from MS to NOT use httpcontextaccessor in blazor apps.

[swegele]

Although, I HAVE to figure out how to get hold of various items from the Request for a user when it first comes in because I need several things like Accept-Language request header so I know what language to serve up to them.
So far every time I access HttpContext it is there except for that Hosted service thing I demo'd. Currently I have an GetDesiredLanguageService which checks for HttpContext and if it is NULL then just default to "en" (english).

I wonder if MS means:

1. Don't ever use it ever
2. You can use it but must check for NULL

[rockfordlhotka]

There's apparently a lot of misinformation out there. If you search for how to get the current user identity in SSB, the answer is always to inject IHttpContextAccessor and get the user from there.

[rockfordlhotka]

https://stackoverflow.com/questions/60264657/get-current-user-in-a-blazor-component

[TheCakeMonster]

@swegele I think the code you posted for BlazorApplicationContextManager is looking more and more attractive. The one change I would recommend is to also accept an instance of AuthenticationStateProvider in the constructor and use it to respect changes to the auth state made outside of Csla, by wiring up a handler for the AuthenticationStateChanged event it exposes. This covers scenarios such as login session timeouts, if the auth mechanism in use implements it.

The handler should await the task and update the stored Principal object once it completes. Object assignments are guaranteed to be atomic, so no locking is required.

If it is possible to do so without causing a recursive loop, you could also try calling the NotifyAuthenticationStateChanged method from your SetUser method. You can only do so if the IPrincipal that is passed is a ClaimsPrincipal of course. If you can avoid a recursive loop then this would be an ideal solution, because users of the framework could either follow the Blazor code samples to log in, or the Csla samples, and both would work perfectly. I think.

I have a nagging doubt about a recursive loop here. I wonder if an equals test might overcome that? It's late and I'm not sure, but see how you get on.

The context manager would need registering as scoped for the event handlers to work correctly.

[rockfordlhotka]

This seems like it is probably the right answer.

[swegele]

The AuthenticationStateProvider stuff is still a little over my head. I haven't had a chance to learn those parts yet. I will read and see how you are using your Csla version of those two classes. I will try it out and post my progress here.

If it works does it make sense to add it to Csla and automatically used it if CslaOptions.AddServerSideBlazor() is called? Or would it get used automatically just because the Blazor dll is referenced?

[TheCakeMonster]

@swegele I know what you mean; the AuthenticationStateProvider thing always throws me a bit too. I think it's because it exposes a task and not a state.

There are spoilers in the separate answer below. It's got some sample code in for you to integrate into yours. If you want the challenge of working it out for yourself then ignore that answer and crack on!

If it works does it make sense to add it to Csla and automatically used it if CslaOptions.AddServerSideBlazor() is called? Or would it get used automatically just because the Blazor dll is referenced?

Yes, it totally makes sense to add it to Csla! Contributions are always welcome; there's a contributor agreement to sign, then you are good to go.

Edited
Yes, I think the automatic selection approach is the best approach. A change to the RegisterContextManager method in the fluent configuration extensions class to check for the Csla.Blazor implementation before the Csla.AspNetCore one is the way to go.

I think this solution will work in both Blazor Server Side and Blazor WebAssembly - but that hypothesis needs to be tested.

[TheCakeMonster]

OK, so here is what I think the changes would look like, roughly. Note: this is untested!

// Firstly, we need to implement IDisposable to avoid a memory leak through our use of event handlers
public class BlazorApplicationContextManager : IContextManager, IDisposable
{
...
	// Add a few private variables
	private readonly ICslaAuthenticationStateProvider _authenticationStateProvider;
	private bool _handlingStateChange = false;

	// Accept the AuthenticationStateProvider from DI and check it meets our minimum needs
	public BlazorApplicationContextManager(AuthenticationStateProvider authenticationStateProvider)
	{
		if (_authenticationStateProvider is not IHostEnvironmentAuthenticationStateProvider)
		{
			throw new InvalidOperationException("This context manager must be used in conjunction with an implementer of the IHostEnvironmentAuthenticationStateProvider interface");
		}
		_authenticationStateProvider = authenticationStateProvider;
		// Wire up the event handler that is used by Blazor to inform consumers of an authentication state change
		_authenticationStateProvider.AuthenticationStateChanged += AuthenticationStateProvider_StateChanged;
	}

	// Some event handlers needed to convert the Task<AuthenticationState> to an AuthenticationState
	private void AuthenticationStateProvider_StateChanged(Task<AuthenticationState> stateTask)
	{
		// Set up awaiting the completion of the task
		stateTask.ContinueWith(t => AuthenticationStateProvider_StateAvailable(t)).ConfigureAwait(false);
	}

	private void AuthenticationStateProvider_StateAvailable(Task<AuthenticationState> completedStateTask)
	{
		// Use the results of the completed task to get the ClaimsPrincipal and store the result
		_handlingStateChange = true;
		SetUser(completedStateTask.Result.User);
		_handlingStateChange = false;
	}

	public void Dispose()
	{
		// Unregister the event handler to avoid memory leaks
		_authenticationStateProvider.AuthenticationStateChanged -= AuthenticationStateProvider_StateChanged;
	}

So the changes around this part are reasonably straightforward, but for the slightly peculiarity of two event handlers brought about by needing to convert a Task into its resulting T without sync over async nastiness.

This is pretty good as is, but for completeness there is one more bit needed. We should be a responsible citizen of the Blazor authentication infrastructure/community. If someone follows a common Csla practice/code example and changes the principal via SetUser() then we need to tell the whole of Blazor that we have changed the authentication state under them. This involves a change to the SetUser method:

	public void SetUser(System.Security.Principal.IPrincipal principal)
	{
		// I think this might be good practice - but it needs verifying. 
		// Csla has a custom of ClaimsPrincipal to help with serialization
		CslaClaimsPrincipal? cslaPrincipal = principal as CslaClaimsPrincipal;
		if (cslaPrincipal is null)
		{
			// TODO: Does this throw an exception if principal is null??
			cslaPrincipal = new CslaClaimsPrincipal(principal);
		}

		Principal = cslaPrincipal;

		// If the request came via the Csla route and not the Blazor route, then inform 
		// the rest of Blazor that we have been asked to change the principal
		if (!_handlingStateChange)
		{
			IHostEnvironmentAuthenticationStateProvider? stateProvider = 
				_authenticationStateProvider as IHostEnvironmentAuthenticationStateProvider;
			Task<AuthenticationState> authenticationState = Task.FromResult(new AuthenticationState(cslaPrincipal));
			stateProvider?.SetAuthenticationState(authenticationState);
		}
	}

This bit needed two goes. I originally thought we needed to create a custom AuthenticationStateProvider as well, but it turns out that the built in IHostEnvironmentAuthenticationStateProvider interface can help us out. This is used to expose a method that we can pass the new state into (although via a Task.)

This is the reason I've edited my answer above. Now it's only a single class, the approach of changing the RegisterContextManager method to automatically select the Blazor implementation if Csla.Blazor is referenced seems the best way to go.

There is actually one more problem. A Blazor Server site can be used for more than just Blazor; it can host WebAPI controllers and the like. We can only have one IContextManager in play, so we probably need to think about enhancing this to do both this AND what the one in Csla.AspNetCore does.

That, I leave as an exercise for the reader ;-)

[swegele]

I finally threw up my hands when I had a version (pretty close to what you gave above) and when I went to run it I got a "circular reference error for Csla.ApplicationContext" and I was like "huh?" That is when I realized I need to admit I'm in over my head on this for now.

[rockfordlhotka]

Those types are in the client namespace because my understanding was that they were only useful in wasm. It is starting to appear that they are useful in both environments.

[rockfordlhotka]

The CslaUserService is designed to update ApplicationContext as the user changes. My guess is that you are also trying to allow ApplicationContext.User to be set - and that would cause a circular reference.

At least in Blazor wasm, I found that it was best to delegate all user management to the CslaUserService and have the ApplicationContext.User property be effectively read-only.

I suppose this could be inverted. With a Blazor-specific application context manager pulling/pushing the value to CslaUserService. I think I was trying to avoid having a custom context manager, b/c the default one should work just fine if the user identity is pushed to ApplicationContext any time the CurrentUser property is changed.

[rockfordlhotka]

One way to explore this, is to create a new SSB project and add one of the pre-built authentication models in the project template. That helps reveal the things Microsoft is expecting to exist.

1. Authentication state
2. Authentication state provider

AuthenticationState is the thing that actually holds the current user identity in a User property. Looking at this, CslaUserService really should be named CslaAuthenticationState and should be a subclass of this type. However, if your app is using some other authentication model, you'd probably use their type, not the CSLA type.

AuthenticationStateProvider seems to be the thing that provides access to the authentication state - including the current user maintained by the AuthenticationState instance. This is the type that the UI (or anything else) uses to access the current user. The CslaAuthenticationStateProvider is a subclass of this type.

It looks to me, like the project templates from Microsoft implement their own AuthenticationStateProvider subclass in the project. Which is good, because you'd need to alter their template code to update the CSLA ApplicationContext with the current value - at least with the current implementation.

This is leading me to think that I should invert the behavior, so the application context manager requires a reference to AuthenticationStateManager and relies on it to implement the User and Principal property getters. Very possibly the context manager should throw an exception when anyone tries to use it to set the current user, b/c people should be setting the current user via the aspnetcore types.

[rockfordlhotka]

I've started making the changes in #2706

[TheCakeMonster]

@swegele @rockfordlhotka Here's a working demo of what I think will do the trick.

https://github.com/TheCakeMonster/Examples/tree/master/CSLA6/BlazorAuthentication

The context manager is in the WebUI project, although I've set the namespace to Csla.Blazor to indicate where I think it should end up. You can see the code at https://github.com/TheCakeMonster/Examples/blob/master/CSLA6/BlazorAuthentication/WebUI/ApplicationContextManager.cs

The demo application - a simple SSB app equivalent of BlazorExample - works. However, it's dependent upon a SQL Server database that backs Identity via EF; hopefully that's not a pain for you if you wanted to run it.

I say it works; it mostly works. You can't save a PersonEdit, but that's because of a bug in LocalProxy that is recorded in issue #2702 rather than anything wrong with the ApplicationContextManager.

As you may notice in the code, there is one small kludge. Because the context manager is created automatically via DI, we don't have control over when it tries to wire itself up to the AuthenticationStateProvider. Depending on the exact application behaviour it is possible for the context manager to be created very early in the life of the SSB circuit; if this happens, it can be before the AuthenticationStateProvider's SetAuthenticationState method is called - in other words, before there is a task from which to retrieve the authentication state. ServerAuthenticationStateProvider in the Microsoft.AspNetCore.Components.Server namespace throws an exception in that scenario - but unfortunately there is no test you can do to avoid that exception. It's necessary to catch the exception and ignore the problem, safe in the knowledge that the event to which your handler is wired will get fired when SetAuthenticationState does get called. Exception handling is slow so I don't really like this kludge, but it does at least work. The exception would be raised once per user at most - and maybe not at all in the majority of applications.

@swegele There were a couple of little gotchas in my code, so I'm not surprised you struggled with it! Sorry about that; I was guessing at what was required, and didn't get it right in a couple of small but important ways.

[TheCakeMonster]

I guess my other wonder/question is : Is it possible / easier to decide up front that I will not mix any non-BSS items into my UI so that I don't need to worry about this mixed environment issue?

It is easier, for sure. I'm with the Ghostbusters on this one ... don't cross the streams! https://www.youtube.com/watch?v=wyKQe_i9yyo

Except, the problem is, it's not always quite that simple. If you output HTML containing an <img> tag with an href in it, then the streams: they be crossed. :-(

There are quite a number of scenarios in which people might need a bit of both. Images are only one. Large file downloads or other downloadable resources might be another. Now imagine that you need to authorise them because people can only see a subset of them - a multi-tenanted solution, for example. If you are using CSLA then there are likely to be CSLA objects in the authorisation chain - and they need to work, rather than throw exceptions.

Images and other resource downloads can be done in a way that avoids the request going outside of Blazor, but then you are putting a lot of data down the pipe intended for only a small amount, which risks breaking your only connection to the client. Furthermore there's only one pipe, so any form of concurrent/parallel requesting of the multiple resources on a large or complex page are gone if you use those approaches. Oh, and so is automated client-side caching of semi-static resources of that type.

The web is built of HTTP requests as a result of the rendering of HTML by browsers, and we largely take it for granted, but it's a valid scenario that CSLA needs to have at least some support for. However, I'd say we shouldn't go as far as to try to build a session store that attempts to bridge the large divide between stateful and stateless environments, whose semantics are very different, mostly because of needing to remain compatible with the early web.

[swegele]

Worms? Let's go fishing and see what we catch :-)
A few weeks ago, I had one of my guys work up a demo that went further with the circuit handler idea mixed with singleton "stuff" storage per user. I will get with him and we will tweak it to be relevant to this convo and post it up for you to see. Maybe it will stir our thinking.

We had a Singleton that stores "stuff" per user and knows each circuit associated with it.

We could offer a window.open mechanism which allows a user to open a new window where the new window circuit knows automatically it's associated with the same "stuff" from previous window...so now you can start having multiple windows knowing about eachother (for same user). Imagine a logoff button that says "Nope, you've got other windows open" or "Do you want logoff and close the other (3) windows you have open?" etc.

Coming soon...

[TheCakeMonster]

@swegele Oh blimey, shared session state across tabs. Well, that will be exciting!

Well, if you really want to do that, then it's dead easy. Claims are your friend. Add a custom claim to ClaimsIdentity (via ClaimsPrincipal) - for example a hash of the username or userid - and have at it. It's available with a line or two of code in all of the environments with almost no effort. Be sure to avoid using an integer, because the next session's id is fairly guessable that way - and that makes request tampering quite successful.

However, I can't emphasise enough how I would recommend you not do that. There be dragons, and they bite. Take it from a guy who was bitten badly by shared state across multiple tabs - in my case due to the way ASP.NET's built in session works - that shared state is a whole raft of security vulnerabilities waiting to happen. I want exactly the opposite of shared state across tabs, and my demo was intended to show just that very thing. Blazor Server is the first web tech in a long time that can offer more segregated state via a browser, and that's one of the reasons I would recommend it as a technology. If I were you, I wouldn't fight that.

Having said that, I can't quite decide which I would recommend against more; shared state or creating your own session provider.

This recommendation has generally dropped off the OWASP top ten because OWASP have been quite successful in spreading the word about it. I quite like the wording at the following link, although it's from long enough ago that I appreciate it seems like it might be out of date - but it only seems that way.

https://owasp.org/www-project-mobile-top-10/2014-risks/m9-improper-session-handling

Here's a nice write up from 2020 that hopefully indicates that this is still a risk:

https://www.coveros.com/understanding-session-management-one-of-owasp-top-10-part-1/

Sometimes session and authenticated user are mixed up in the wording of some of the discussions - or some of the mental pictures that people imagine based on reading the text. The two can be separate - and both are a problem.

Having data from user's browser tab 2 (and which has been stored in shared session) overwriting the data from some entirely unrelated task being undertaken in tab 1 is not something I'd recommend you rush to experience. It's not much fun.

[swegele]

Warning clearly heard and understood. Here is Microsoft's version of the caution:

Warning
We don't recommend apps on the same server share state using singleton services unless extreme care is taken, as this can introduce security vulnerabilities, such as leaking user state across circuits.

And then they say:

You can use stateful singleton services in Blazor apps if they are specifically designed for it. For example, it's ok to use a memory cache as a singleton because it requires a key to access a given entry, assuming users don't have control of what cache keys are used.

I don't know about you, but I just read that I CAN have a pet dragon, but to feed him cautiously :-)

Those bits are just above the section, in the web page you found, saying to not use HttpContext in Blazor Server Side:
https://docs.microsoft.com/en-us/aspnet/core/blazor/security/server/threat-mitigation?view=aspnetcore-6.0#blazor-and-shared-state

Now, according to their recommended way, in our demo we use a GUID key (not the circuitid) which is:

• TEMPORARILY placed in ProtectedBrowserSessionStorage prior to window.open javascript
• New tab opens and starts a new circuit
• CircuitHandler immediately sees the key in PBSS
• CircuitHandler deletes the keys PBSS
• In addition, our keys have a < 3 second time to live value so they can't live indefinitely
• upon first use the key is inactivated so another tab can't sniff (break encryption) and re-use value
• the whole operation takes milliseconds usually

But again, warning heeded and I'm still in evaluate and try mode.

There are only about 2 or 3 scenarios (very rare) where we actually need this particular behavior e.g.

• open multiple windows with image viewers so user can compare n images together or full screen)
• open a separate signature popup window that can be dragged to a touch screen monitor and presented to user on other side of glass
• and such
  So I'm not worried about concurrency issues.

But again, warning heeded :-)

[swegele]

Steve wrote a really good article that is applicable here. I'm drinking from the firehose and my brain hurts!

https://gist.github.com/SteveSandersonMS/ba16f6bb6934842d78c89ab5314f4b56

[rockfordlhotka]

fwiw, there are two reasons Csla.Blazor references the Csla.AspNetCore package.

1. The HttpClient-based context manager is in aspnetcore - but that reason is no longer valid
2. The Http data portal host is in the aspnetcore package, so if you want to host a data portal endpoint this is required

[TheCakeMonster]

Oh yeah, that.

That's the hybrid stuff I have been talking about. It'll be caused by a non-Blazor request - it's probably being raised by the login page or something - or perhaps the revalidating state provider, which I think runs revalidation code on a background task - every 30 minutes, if I recall.

I think in my version I caught the error and ignored it to begin with. I then went the extra mile and switched to the hybrid context manager which senses whether it is in Blazor or not and uses that to decide whether to delegate to the Blazor or ASP.NET version.

[TheCakeMonster]

Copy the code of my hybrid state provider from my demo into your app and use that to switch between the new one in Csla.Blazor and the one in Csla.AspNetCore. I think that will sort it for you.

You need HybridApplicationContextManager.cs, IdentifyingCircuitHandler.cs and BlazorIdentification.cs, plus a line of code in the startup to register the IdentifyingCircuitHandler class.

[swegele]

In the simple demo, I have no asp.net nor api or mvc or controllers or anything extra. Only server side blazor.

Like before, I believe it is coming from the HostedService (which runs on a timer) and not a page request.

[TheCakeMonster]

Possibly - although the phrase "it's turtles all the way down" is looming off in the distance, clamouring for attention. Something has to host a Blazor server-side site. _Host.cshtml is it by default - a Razor Pages page.

[swegele]

Is this related...
dotnet/aspnetcore#28684

the GetAuthenticationStateAsync works only if the AuthenticationStateProvider service is synchronously called from a Blazor page.
In any async call running in the background it fails with the mentioned error message.

It's troubling how that issue has languished for over a year with so many chiming in saying they are having the same problem.

[swegele]

No your right, I was just answering in general not from a feature request point of view.

edit: it just cracks me up that they say you should never use it - then they tell you how to use it. Not to mention all the misinformation (as you mentioned) out there related to this topic especially.

[swegele]

OK guys, here is an update and I hope it helps.

@rockfordlhotka , I copied your Csla.Blazor.AuthenticationStateContextManager into my demo project so I could debug it.
In the InitializeUser method I get that error mentioned.

Soooo I decided to listen to what the error was saying and call SetAuthenticationState before the GetAuthenticationStateAsync

Here is the modified method.

private void InitializeUser()
{
    if (AuthenticationStateProvider is IHostEnvironmentAuthenticationStateProvider hostEnvironmentAuthProvider)
    {
        //i've no idea what i'm doing except to call set before get like error says
        var task = new Task<AuthenticationState>(() => new AuthenticationState(UnauthenticatedPrincipal));

        //the following set triggers the authentication state changed so why do it again below?
        hostEnvironmentAuthProvider.SetAuthenticationState(task);
    }
    else
    {
        //??
        AuthenticationStateProvider_AuthenticationStateChanged(AuthenticationStateProvider.GetAuthenticationStateAsync());
    }
}

The AuthenticationStateProvider IS INDEED an IHostEnvironmentAuthenticationStateProvider so this actually works.
Yay happy boy...but then I bump into this down below in the file:

public virtual void SetUser(IPrincipal principal)
{        
    throw new NotSupportedException(nameof(SetUser));
}

Now what is interesting is that SetUser method is called by Csla itself!! See Csla.Channels.Local.LocalProxy at line 44

        manager.SetUser(parentContext.User);

I'm stuck there as I'm not sure what the intent was of throwing that NotSupportedException and then the framework being the first offender?

[rockfordlhotka]

That is unexpected obviously.

The problem is that the AuthenticationStateProvider has no way to set the user value. The server implementation has such a thing, but the abstract base type does not. As a result, there's no way to reliably know that the manager.SetUser method could actually work, so I had it throw the exception.

I'm not really sure how to resolve the issue either, given that there isn't a way to reliably set the current user in all cases when using AuthenticationStateProvider as the source for the current principal.

[TheCakeMonster]

Ah yes, interesting. We made a change late on to how LocalProxy deals with creating its own little bubble of context due to a bug causing the state to be lost. That's why SetUser is now causing us an issue when it wasn't before.

I think there are two potential solutions:

1. Go back to using the AsyncLocal version of the context manager within LocalProxy. It turned out that the bug was to do with an omission from the state transfer code associated with the context manager, and not the context manager in use, so this should work OK.
2. It is possible to implement the SetUser method in SSB, with a little, erm, limitation. An interface called IHostEnvironmentAuthenticationStateProvider is available for implementation by an AuthenticationStateProvider, and is indeed implemented by the AuthenticationStateProvider used in SSB. IHostEnvironmentAuthenticationStateProvider exposes the SetAuthenticationState method that is mentioned in the exception. A (successful) cast of the provider to that interface enables the SetUser method to be completed. This is what I did in my demo, but I did that before the change to the type of context manager used by LocalProxy.

In my demo, I checked in the constructor that the AuthenticationStateProvider implemented that interface; if it didn't I threw an exception. That's not very friendly to consumers of CSLA who might try to use other AuthenticationStateProvider implementations that don't offer this.

I think option 1 is probably the right approach. I think the issue with the code in LocalProxy wasn't about the type being used, it was that the clone of the context was incomplete. I don't think raising a notification event to the UI to indicate that a state change has occurred - a part of option 2 - is really the right thing to do as part of every data access method.

[swegele]

Are there 3 distinct problems to deal with here:
(forgive if I'm still not seeing all the parts yet - but I am starting to feel a flicker of understanding)

1. Change LocalProxy back to previous, as per @TheCakeMonster suggestion above, so that it doesn't call SetUser
   (currently it is calling that often as child business objects are being created in my scenario)

2. Make it safe to call SetUser method by having it call IHostEnvironmentAuthenticationStateProvider.SetAuthenticationState
   (this seems better than throwing an exception if someone calls it)

3. Fix InitializeUser to not blowup on call to AuthenticationStateProvider.GetAuthenticationStateAsync() for scenarios like where a HostedService makes a call outside of a circuit/user context.

SWAG suggestion for InitializeUser and helper method:

private void InitializeUser()
{
    Task<AuthenticationState> getUserTask;
    try
    {
        getUserTask = AuthenticationStateProvider.GetAuthenticationStateAsync();
    }
    catch (InvalidOperationException ioex)
    {
        //?? It might be good enough to just test for that ioex but might we inadvertently catch other unrelated ones with same ioex type??
        //?? Is it safe to go further and test for the method names being present in the exception without tripping over culture specific error messages 
        string message = ioex.Message;
        if (message.Contains(nameof(AuthenticationStateProvider.GetAuthenticationStateAsync))
            && message.Contains(nameof(IHostEnvironmentAuthenticationStateProvider.SetAuthenticationState)))
        {
            SafeSetCurrentUser(UnauthenticatedPrincipal);
        }
        return;
    }

    AuthenticationStateProvider_AuthenticationStateChanged(getUserTask);
}

private void SafeSetCurrentUser(ClaimsPrincipal principal)
{
    if (AuthenticationStateProvider is IHostEnvironmentAuthenticationStateProvider hostEnvironmentAuthProvider)
    {
        var task = new Task<AuthenticationState>(() => new AuthenticationState(principal));
        hostEnvironmentAuthProvider.SetAuthenticationState(task);
    }
}

SWAG suggestion for SetUser

public virtual void SetUser(IPrincipal principal)
{        
    CurrentPrincipal = principal;
    if (CurrentPrincipal is ClaimsPrincipal)
    {
        SafeSetCurrentUser((ClaimsPrincipal)CurrentPrincipal);
    }
    else
    {
        //??
    }
}

EDIT: And I guess we could keep an eye on this issue being fixed which might make the check in InitizlizeUser method no longer needed in future.
dotnet/aspnetcore#28684

EDIT2: Upon looking at the microsoft repo of aspnet code I believe it is safe to look for the method names in that invalidoperationexception that is thrown by them:

    public override Task<AuthenticationState> GetAuthenticationStateAsync()
        => _authenticationStateTask
        ?? throw new InvalidOperationException($"{nameof(GetAuthenticationStateAsync)} was called before {nameof(SetAuthenticationState)}.");

[rockfordlhotka]

Keep in mind that we're solving for Blazor wasm as well as SSB, so we can't rely on that server-only interface or implementation,.

Or we need two context managers - one for SSB and another for Blazor wasm.

[swegele]

I cannot speak with any high level of expertise or certainty, but my gut says that there are enough differences around Blazor SS and WASM that you might end up needing one for each.

I'm reading heavily about AuthenticationStateProvider and ServerAuthenticationStateProvider. I see repeated mentions how BSS works different than BWASM in this area.
This article for instance:
https://gist.github.com/SteveSandersonMS/175a08dcdccb384a52ba760122cd2eda#implementing-a-custom-authenticationstateprovider

Server-side Blazor has a built-in AuthenticationStateProvider DI service that obtains authentication state data from ASP.NET Core's server-side HttpContext.User. This is how it integrates with all the existing server-side authentication mechanisms.
For server-side Blazor, it is very unlikely that you should implement a custom AuthenticationStateProvider. The built-in implementation already integrates with ASP.NET Core's built-in authentication mechanisms. If you implement a custom one, you may introduce security vulnerabilities.
The only common scenario for a custom AuthenticationStateProvider is client-side Blazor, because in that case you may want to integrate with any number of external authentication systems independently of your server-side code. Also, in client-side Blazor, authentication only exists to present a convenient UI to well-behaved users - it's not actually the place where security is enforced, since client-side rules can always be bypassed.

I so surprised by how much misinformation is out there. I've read for days on this auth stuff and that article today is the first time I've ever seen that extra bit. The web is full of "Hello World" examples of custom AuthenticationStateProviders and not much depth to any of them (with the 'why' questions answered)

[swegele]

Slight tweak to SafeSetCurrentUser in above post...

private void SafeSetCurrentUser(ClaimsPrincipal principal)
{
    if (AuthenticationStateProvider is IHostEnvironmentAuthenticationStateProvider hostEnvironmentAuthProvider)
    {
        var authState = new AuthenticationState(principal);
        hostEnvironmentAuthProvider.SetAuthenticationState(Task.FromResult(authState));
    }
}

The previous way I had it caused the CascadingAuthenticationState to think it was "Authorizing" indefinitely.