net7 Blazor WASM AAD authentication ends with There was an error trying to log you in: '"undefined" is not valid JSON'

[hakenr]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Sample project: https://github.com/havit/Bonusario

When upgraded from net6 to net7 the application started to fail with

` There was an error trying to log you in: '"undefined" is not valid JSON'

right after logging in to Azure AD (end of auth workflow).

Applies only for published version, does not occur in development.

After several attempts I found that disabling assembly trimming for Microsoft.AspNetCore.Components.WebAssembly.Authentication resolves the issue.

Expected Behavior

No response

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

7.0.100

Anything else?

Workaround

Add

<assembly fullname="Microsoft.AspNetCore.Components.WebAssembly.Authentication" preserve="all" />

to your TrimmerRootDescriptor.xml.

See https://learn.microsoft.com/en-us/dotnet/core/deploying/trimming/trimming-options

[TanayParikh]

@MackinnonBuck I believe you may've had a patch in the trimming/auth space recently. Is this potentially a dup?

[andref15]

If you don't need the TrimmerRootDescriptor XML for anything else already, a faster workaround is to just add

<ItemGroup>
    <TrimmerRootAssembly Include="Microsoft.AspNetCore.Components.WebAssembly.Authentication" />
</ItemGroup>

in your csproj file

[MackinnonBuck]

@TanayParikh This seems different from the trimming error we saw before. The same issue was described in this comment. I'd say this is a real thing and possibly a servicing candidate.

[hjrb]

Exact same issue for me. Please fix this ASAP

[javiercn]

@hjrb @hakenr I suspect this is a dupe of #44973

[javiercn]

@hakenr disabling the trimming for the assembly is the current workaround

[hjrb]

@hakenr disabling the trimming for the assembly is the current workaround

In a hosted Blazor: is that for the server or the client project or for both? I added it to the server project (which I deploy) but that did not work.

[andref15]

@hjrb In both cases (asp.net core hosted or not) you have to add the TrimmerRootDescriptor or TrimmerRootAssembly tags in the Blazor (client) csproj file

[rena0157]

Added the TrimmerRootAssembly option in .csproj seems to have fixed the issue, but now publishing the project takes more than 10 mins.

[andref15]

@rena0157 That seems odd, publishing time didn't seem to change for me at all. Are you using AOT?

[rena0157]

I am not no, but I do have another TrimmerRootAssembly in the csproj

<ItemGroup>
    <TrimmerRootAssembly Include="Microsoft.Authentication.WebAssembly.Msal" />
    <TrimmerRootAssembly Include="Microsoft.AspNetCore.Components.WebAssembly.Authentication" />
</ItemGroup>

Do you think having both could cause a performance issue? I had the previous one due to a previous trimming issue with auth. Going to remove the first one and see if there is a difference in perf.

[andref15]

Hm, interesting. It might be. The good news is that you don't need the Microsoft.Authentication.WebAssembly.Msal included anymore. That issue is actually fixed in the net7 release. (See #33312)

[rena0157]

Ahh sweet thanks for the tip! I will remove that now and run some tests. Actually it seems that the publishing time for me about doubled when upgrading to .NET 7 in general. Notwithstanding the TrimmerRootAssembly option.

[andref15]

That's true, I noticed a generally longer publishing time as well

[julio-espinosa]

I am not no, but I do have another TrimmerRootAssembly in the csproj

<ItemGroup>
    <TrimmerRootAssembly Include="Microsoft.Authentication.WebAssembly.Msal" />
    <TrimmerRootAssembly Include="Microsoft.AspNetCore.Components.WebAssembly.Authentication" />
</ItemGroup>

Do you think having both could cause a performance issue? I had the previous one due to a previous trimming issue with auth. Going to remove the first one and see if there is a difference in perf.

I have a similar problem. My csproj file has the following.

<ItemGroup>
    <TrimmerRootAssembly Include="Microsoft.Authentication.WebAssembly.Msal" />
</ItemGroup>

I test it out and respond with my results when I deploy to a testing environment.

[julio-espinosa]

So it looks like adding the following in my client .csproj file worked for me

<ItemGroup>
    <TrimmerRootAssembly Include="Microsoft.Authentication.WebAssembly.Msal" />
    <TrimmerRootAssembly Include="Microsoft.AspNetCore.Components.WebAssembly.Authentication" />
</ItemGroup>

It was mentioned that by @andref15 that we could remove the following line because it has been addressed in .net 7 release.

I will comment to confirm.

[rajeshkandati]

Exact same issue for me. Please fix this ASAP. Thank you @hakenr

[edgedj]

seeing this same issue on a production application upgraded straight from .net 5 to 7. These are the contents of the package references in the Client project:

  <ItemGroup>
    <PackageReference Include="Blazored.Modal" Version="7.1.0" />
    <PackageReference Include="Blazored.SessionStorage" Version="2.2.0" />	
	  <PackageReference Include="Blazorise.Bootstrap" Version="1.1.3.1" />
    <PackageReference Include="Blazorise.Icons.FontAwesome" Version="1.1.3.1" />
    <PackageReference Include="Blazorise.Sidebar" Version="1.1.3.1" />
    <PackageReference Include="Microsoft.AspNetCore.SignalR.Client" Version="7.0.0" />
    <PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly" Version="7.0.0" />
    <PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="7.0.0" PrivateAssets="all" />
    <PackageReference Include="Microsoft.Authentication.WebAssembly.Msal" Version="7.0.0" />
    <PackageReference Include="Microsoft.Extensions.Configuration.Binder" Version="7.0.0" />
    <PackageReference Include="Microsoft.Extensions.Http" Version="7.0.0" />
    <PackageReference Include="System.Net.Http.Json" Version="7.0.0" />
    <PackageReference Include="Microsoft.CSharp" Version="4.7.0" />
    <PackageReference Include="Newtonsoft.Json" Version="13.0.1" />
    <PackageReference Include="Number_To_Word_Converter" Version="1.1.8" />
    <PackageReference Include="BlazorInputFile" Version="0.2.0" />
    <PackageReference Include="Azure.Storage.Blobs" Version="12.14.1" />
    <PackageReference Include="ClosedXML" Version="0.97.0" />
    <PackageReference Include="Blazored.Toast" Version="3.2.2" />
  </ItemGroup>

[JasonRodman]

So it looks like adding the following in my client .csproj file worked for me

<ItemGroup>
    <TrimmerRootAssembly Include="Microsoft.Authentication.WebAssembly.Msal" />
    <TrimmerRootAssembly Include="Microsoft.AspNetCore.Components.WebAssembly.Authentication" />
</ItemGroup>

It was mentioned that by @andref15 that we could remove the following line because it has been addressed in .net 7 release.

I will comment to confirm.

When I did this it breaks my app all together. When its deployed with https I get an error like this:

Failed to find a valid digest in the 'integrity' attribute for resource 'https://app.local:8443/_framework/Microsoft.AspNetCore.Components.WebAssembly.Authentication.dll' with computed SHA-256 integrity 'vMnCiawojCEc5uD+LGveolw4GA8hQffXzamBOAdGDzw='. The resource has been blocked.

[javiercn]

Failed to find a valid digest in the 'integrity' attribute for resource 'https://app.local:8443/_framework/Microsoft.AspNetCore.Components.WebAssembly.Authentication.dll' with computed SHA-256 integrity 'vMnCiawojCEc5uD+LGveolw4GA8hQffXzamBOAdGDzw='. The resource has been blocked.

Clean your bin and obj folders and publish again

[rena0157]

Clean your bin and obj folders and publish again

Adding to this, @JasonRodman if you are getting integrity issues in a deployment and are deployed on a CDN I have found that you need to purge the cache in order to fix this issue.

[JasonRodman]

Clean your bin and obj folders and publish again

That worked for me. It now publishes and runs without the error.

[mikequ-taggysoft]

So just to get this straight:

Prior to .NET 7, we needed:

<ItemGroup>
    <TrimmerRootAssembly Include="Microsoft.Authentication.WebAssembly.Msal" />
</ItemGroup>

Then .NET 7 fixed this, but broke something else, and instead of the above, we now need:

<ItemGroup>
    <TrimmerRootAssembly Include="Microsoft.AspNetCore.Components.WebAssembly.Authentication" />
</ItemGroup>

And when changing these entries, we need to make sure to clean obj/bin folders or we get an unclean build with integrity errors.

[yugabe]

For anyone interested, the difference between trimming or not trimming the assembly is 74kB vs 83kB uncompressed (25kB vs 28kB with Brotli). I don't think it's a huge overhead.

I guess either the "Models" or the "Options" folder contains the culprit(s), but didn't go through them one by one to see which needed to be rooted specifically. As they're not in a specific namespace, it's not easy to target them using linker XML either unless you specify them one by one.

[JasonRodman]

For anyone interested, the difference between trimming or not trimming the assembly is 74kB vs 83kB uncompressed (25kB vs 28kB with Brotli). I don't think it's a huge overhead.

I guess either the "Models" or the "Options" folder contains the culprit(s), but didn't go through them one by one to see which needed to be rooted specifically. As they're not in a specific namespace, it's not easy to target them using linker XML either unless you specify them one by one.

If my memory serves me correctly the whole reason we had to add the assembly trimming in the first place was to fix another bug during deployment discussed #33312 here. Is this no longer even necessary? It says its fixed but I never tried removing it and deploying it. Now I will have to remove all of it and see if it just works.

[yugabe]

@JasonRodman To me, the problem with the Microsoft.Authentication.WebAssembly.Msal assembly didn't surface (it had more related issues to trimming, like #44811, #43293). Currently, when the IdP redirects, the "undefined" issue still stands, so the Microsoft.AspNetCore.Components.WebAssembly.Authentication needs to be rooted (instead).

(Btw, I suspect the particular model object that is most suspect is MsalProviderOptions, but there might be bigger underlying issues regarding trimming, because these issues seem to keep popping up.)

[dougclutter]

We're having this problem too. For us, everything works fine on our laptops, but fails as soon as we deploy it to Azure. We're serving the app from a CDN.

When we added this to our csproj, the problem goes away:

<ItemGroup>
    <TrimmerRootAssembly Include="Microsoft.AspNetCore.Components.WebAssembly.Authentication" />
</ItemGroup>

[ghost]

Got it working but, had to add the nuget package Microsoft.AspNetCore.Components.WebAssembly.Authentication only to overcome that issue on Azure App Service.

<Project Sdk="Microsoft.NET.Sdk.BlazorWebAssembly">

	<PropertyGroup>
		<TargetFramework>net7.0</TargetFramework>
		<Nullable>enable</Nullable>
		<ImplicitUsings>enable</ImplicitUsings>
	</PropertyGroup>

	<ItemGroup>
		<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly" Version="7.0.0" />
		<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.Authentication" Version="7.0.0" />
		<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="7.0.0" PrivateAssets="all" />
		<PackageReference Include="Microsoft.Authentication.WebAssembly.Msal" Version="7.0.0" />
		<PackageReference Include="Microsoft.Extensions.Http" Version="7.0.0" />
	</ItemGroup>

	<ItemGroup>
		<TrimmerRootAssembly Include="Microsoft.AspNetCore.Components.WebAssembly.Authentication" />
	</ItemGroup>

	<ItemGroup>
		<ProjectReference Include="..\Shared\ASimpleBlog.Shared.csproj" />
	</ItemGroup>

</Project>

[larry-lau]

I have the same issue. While troubleshooting I saw the state in session storage is set to undefined. Hope this helps.

[javiercn]

this was addressed in 7.0.1 as part of #45028