Authentication errors when upgrading from v8.0.0-R24031302 to v8.0.0-R24032503 / v8.0.1

[JacoJordaan]

I have a pure server-side Blazor up that was successfully upgraded from .net 7 using csla 7 to .net 8 using v8.0.0-R24031302.
Since I am only using Blazor server-side, I have made no configuration changes for the new Blazor render modes.

Upgrading from v8.0.0-R24031302 to v8.0.0-R24032503 or v8.0.0 or v8.0.1 returns 2 exceptions. I am not sure if it is related.

The first one is due to the ApplicationContext.User.Identity that returns null. Previously this always had a value.
Screenshot of issue where the ApplicationContext was injected into a service:

The next one gives me the following error:

System.InvalidOperationException: Do not call GetAuthenticationStateAsync outside of the DI scope for a Razor component. Typically, this means you can call it only within a Razor component or inside another DI service that is resolved for a Razor component.
   at Csla.DataPortal`1.Create(Type objectType, Object criteria)
   at Csla.DataPortal`1.Create(Object[] criteria)

Is there any configuration changes required to use the latest version of csla or is this a possible bug?

[kcabral817]

I did the same thing but rolled back because of the error, so I'm interested in this too.

[StefanOssendorf]

Where does the service live? Is it in a hosted service besides the blazor stack?
Is it possible for you to create a minimal working example which provokes that exact error to make investigation easier?

[JacoJordaan]

I have created a minimal working example attached.
BlazorServerTestCsla8.zip

I created this initialy in .net7 with csla 7.0.4 and everything was working.
Upgraded to .net8 with csla 8.0.1 and configuration changes for csla 8.

I am not able to replicate the ApplicationContext.User.Identity == null issue, but I still receive the error

Do not call GetAuthenticationStateAsync outside of the DI scope for a Razor component. Typically, this means you can call it only within a Razor component or inside another DI service that is resolved for a Razor component.

[rockfordlhotka]

fwiw, @mtavares628 ran into this and did find a workaround - something to do with how the custom authentication state manager is implemented iirc.

[mtavares628]

@rockfordlhotka If this is related to my issue where the identity is null, I never actually found a solution (Note that the title for that discussion doesn't match where the problem was truly found). I got pulled into another project for the last few weeks, so I haven't been able to follow up with you about it. But the issue was introduced for me in pull request #3632 and in particular this commit from it: d3aa7cc.

My code still ran after this but the performance was terrible, and I think it's because it's throwing an exception from calling GetAuthenticationState before SetAuthenticationState which may be related to this problem. I'm hoping to be finished with my other project by next week, and can revisit this to see what's going on and how we can fix it.

[rockfordlhotka]

Is there any configuration changes required to use the latest version of csla or is this a possible bug?

Yes, there's a config change that's necessary. CSLA 8 defaults to using the new state management subsystem, and if you are doing a pure render mode (like .NET 7) app you need to use the "in memory" state management.

builder.Services.AddCsla(o => o
  .AddAspNetCore()
  .AddServerSideBlazor(ssb => ssb.UseInMemoryApplicationContextManager = true));

cc @russblair as this is what we were just discussing

[russblair]

To recreate this issue, I upgraded the BlazorExample.sln from CSLA 8.0.0-R24021201 to CSLA 8.1.0.

I had to change the CslaStateController.cs to override the new StateManager.Get and I had to remove the Home.razor code related to StateManager.IsStateAvailable.

When I run it and click on the “List people” menu option it produces the error “Do not call GetAuthenticationStateAsync outside of the DI scope for a Razor component. Typically, this means you can call it only within a Razor component or inside another DI service that is resolved for a Razor component.”

[russblair]

The error is the same after changing the BlazorExample/Program.cs to .AddServerSideBlazor(ssb => ssb.UseInMemoryApplicationContextManager = true)

[rockfordlhotka]

Thanks for doing the research @russblair - I'll look into this further.

[swegele]

Just bumped into this same error after upgrading my all-server-side-interactive blazor project.

builder.Services.AddCsla(o => o
  .AddAspNetCore()
  .AddServerSideBlazor(bsco => bsco
    .UseInMemoryApplicationContextManager = true)
  .Security(so => so.FlowSecurityPrincipalFromClient = true));

[kcabral817]

IMHO, I think .NET 8 release is way more than just a breaking change. I get the sense from reading the conversations here that it is a fundamental shift for Blazor communication. Does anyone know why such a change is warranted and what benefit it will bring?

[StefanOssendorf]

As far as I understand it's necessary to support the new rendering modes.

[rockfordlhotka]

The new render modes in Blazor 8 are an amazing feature - once they are understood.

In my experience, most apps have lots of read-only pages that show data, graphs, charts, and all sorts of stuff. There's no reason to set up SignalR pipelines or download wasm runtimes to display data - the web was great at doing this from day 1 back in the 1990s.

Blazor was requiring that all pages have either SignalR or wasm, which is total overkill for all those pages.

The new render model allows us to create server-static pages that don't have any of that overhead, just sending html/css to the browser. And for longer data reports, you can use streaming, where the user sees the data as it is sent to the browser over time. Very good experience imo.

For pages that do need interactivity, you can use server-interactive or wasm-interactive. The thing is, both of those have some upfront setup time - either to create the SignalR pipeline or to download the wasm files. To give the user a more immediate feel, you can use InteractiveAuto.

InteractiveAuto does this (on the very first use of an interactive page):

1. Render using server-static to show the user something immediately
2. Render using server-interactive, because setting up a SignalR pipeline is fairly fast; and behind the scenes while the user is using the page, the wasm files are being downloaded
3. On a subsequent visit to the page by the user, render using server-static to show the user something immediately; the wasm files are being JIT compiled behind the scenes
4. On that subsequent visit, render the page using wasm-interactive to shift the workload to the client device and entirely off the server
5. On future visits to the page, render the page using wasm-interactive because it has been downloaded and compiled, so it can be just launched directly

As long as you have a reliable way to detect the current render mode and understand this workflow, you can make a very compelling user experience that leverages interactivity.

For example:

1. On server-static rendering, render placeholders so the user knows something is coming
2. On interactive rendering, render the data and show all the buttons and other stuff the user can see and use

This avoids double-loading the data (on server-static and then again in interactive mode) by only loading the data in interactive mode, but giving the user a decent "loading" visual in the meantime.

[swegele]

I'm wondering if .NET 8 changed the error and message such that this little test we added in CSLA 6 and .NET 6 is no longer catching the condition (which would explain why it happens for both inmemory and not) :

See both:

• Csla.AspNetCore\Blazor\ApplicationContextManagerInMemory
• Csla.AspNetCore\Blazor\ApplicationContextManagerBlazor

private void InitializeUser()
{
  Task<AuthenticationState> task = default;
  try
  {
    task = AuthenticationStateProvider.GetAuthenticationStateAsync();
  }
  catch (InvalidOperationException ex)
  {
    task = Task.FromResult(new AuthenticationState(UnauthenticatedPrincipal));
    string message = ex.Message;
    if (message.Contains(nameof(AuthenticationStateProvider.GetAuthenticationStateAsync))
        && message.Contains(nameof(IHostEnvironmentAuthenticationStateProvider.SetAuthenticationState)))
    {
      SetHostPrincipal(task);
    }
    else
    {
      throw;
    }
  }
  AuthenticationStateProvider_AuthenticationStateChanged(task);
}

If I get some time I will debug to see if we are hitting that condition and passing over it because the error message possibly no longer mentions the "SetAuthenticationState" part like it used to?

[StefanOssendorf]

There are cases when the catch can be hit. That's the case when GetAuthenticationStateAsync() like in your other quote is not async. In that case the exceptions is thrown immediately without an await. In all other cases - with a proper async implementation - the catch is never hit because the exception is waiting in the task to be awaited.
I'll create a bug/research issue to keep track of that.

[swegele]

I was able to get rid of the error by changing the InitializeUser method to the following:

    private async Task InitializeUser()
    {
      Task<AuthenticationState> task = default;
      try
      {
        await (task = AuthenticationStateProvider.GetAuthenticationStateAsync());
      }
      catch (InvalidOperationException ex)
      {
        task = Task.FromResult(new AuthenticationState(UnauthenticatedPrincipal));
        string message = ex.Message;
        if (message.Contains(nameof(AuthenticationStateProvider.GetAuthenticationStateAsync) + " outside of the DI scope for a Razor component"))
        {
          SetHostPrincipal(task);
        }
        else
        {
          throw;
        }
      }
      AuthenticationStateProvider_AuthenticationStateChanged(task);
    }

[swegele]

@russblair @rockfordlhotka - Hey all, I followed Russ' breadcrumb path

• Upgrading the BlazorExample project to 8.1 nuget
• Changed the CslaStateController line to this: public override StateResult Get(long lasttouched) => base.Get(lasttouched);
• Commented out this on Home: //IsStateReady = StateManager.IsStateAvailable;
  Note - I did not change Program.cs at all.

Run project and go to list page -
BOOM see the error

Next

• Make the change in the message just above this post to these files InitializeUser method:
  • Csla.AspNetCore\Blazor\ApplicationContextManagerInMemory
  • Csla.AspNetCore\Blazor\ApplicationContextManagerBlazor
• Paste this into the BlazorExample project properties : Build : Events : Post-build event

xcopy /y /d  "C:\repos\csla\Bin\Debug\net8.0\Csla.dll" "$(TargetDir)"
xcopy /y /d  "C:\repos\csla\Bin\Debug\net8.0\Csla.pdb" "$(TargetDir)"
xcopy /y /d  "C:\repos\csla\Bin\Debug\net8.0\Csla.AspNetCore.dll" "$(TargetDir)"
xcopy /y /d  "C:\repos\csla\Bin\Debug\net8.0\Csla.AspNetCore.pdb" "$(TargetDir)"
xcopy /y /d  "C:\repos\csla\Bin\Debug\net8.0\Csla.Blazor.dll" "$(TargetDir)"
xcopy /y /d  "C:\repos\csla\Bin\Debug\net8.0\Csla.Blazor.pdb" "$(TargetDir)"

This copied the dlls you just compiled over the nuget ones at after build of blazor project so you get new behavior.

Now run and the blazor list page loads without error.

[rockfordlhotka]

@swegele if you make InitializeUser return async Task, then you can't call it from the constructor. How did you get around that?

[swegele]

I think it simply gets treated as normal sync...so it seems a little confusing to me to mark the InitializeUser method as async since the only caller to it is the sync CTOR. But maybe it does seem more correct to have the method be async if it ever needed to be called from elsewhere.

@StefanOssendorf had the nice suggestion of adding this _ = InitializeUser(); to make the compiler message go away in the CTOR :-)

Anyway, for my situation the issue was the changed error message from microsoft not the task await thing.

[rockfordlhotka]

Will be fixed in #3903 (CSLA 9)