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

Question

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

hakenr opened this issue 2 years ago · comments

Robert Haken commented 2 years ago

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

Tanay Parikh · Answer 1 · Thu Nov 10 2022 03:37:37 GMT+0800 (China Standard Time)

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

André · Answer 2 · Thu Nov 10 2022 04:27:42 GMT+0800 (China Standard Time)

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

Mackinnon Buck · Answer 3 · Thu Nov 10 2022 06:25:38 GMT+0800 (China Standard Time)

@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.

hrb · Answer 4 · Fri Nov 11 2022 05:01:00 GMT+0800 (China Standard Time)

Exact same issue for me. Please fix this ASAP

Javier Calvarro Nelson · Answer 5 · Sat Nov 12 2022 01:36:16 GMT+0800 (China Standard Time)

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

Javier Calvarro Nelson · Answer 6 · Sat Nov 12 2022 01:42:48 GMT+0800 (China Standard Time)

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

hrb · Answer 7 · Sat Nov 12 2022 04:59:32 GMT+0800 (China Standard Time)

@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.

André · Answer 8 · Sat Nov 12 2022 05:08:47 GMT+0800 (China Standard Time)

@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

Adam Renaud · Answer 9 · Mon Nov 14 2022 03:48:46 GMT+0800 (China Standard Time)

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

André · Answer 10 · Mon Nov 14 2022 03:52:25 GMT+0800 (China Standard Time)

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

Adam Renaud · Answer 11 · Mon Nov 14 2022 03:53:52 GMT+0800 (China Standard Time)

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.

André · Answer 12 · Mon Nov 14 2022 03:56:42 GMT+0800 (China Standard Time)

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)

Adam Renaud · Answer 13 · Mon Nov 14 2022 04:02:18 GMT+0800 (China Standard Time)

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.

André · Answer 14 · Mon Nov 14 2022 04:05:49 GMT+0800 (China Standard Time)

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

julio-espinosa · Answer 15 · Tue Nov 15 2022 00:21:13 GMT+0800 (China Standard Time)

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 · Answer 16 · Tue Nov 15 2022 03:50:25 GMT+0800 (China Standard Time)

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 · Answer 17 · Tue Nov 15 2022 04:36:08 GMT+0800 (China Standard Time)

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

edgedj · Answer 18 · Tue Nov 15 2022 18:30:26 GMT+0800 (China Standard Time)

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>

JRod · Answer 19 · Wed Nov 16 2022 05:19:58 GMT+0800 (China Standard Time)

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.

Javier Calvarro Nelson · Answer 20 · Wed Nov 16 2022 15:59:48 GMT+0800 (China Standard Time)

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

Adam Renaud · Answer 21 · Wed Nov 16 2022 22:50:56 GMT+0800 (China Standard Time)

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.

JRod · Answer 22 · Thu Nov 17 2022 03:48:51 GMT+0800 (China Standard Time)

Clean your bin and obj folders and publish again

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

Mike Qu · Answer 23 · Thu Nov 17 2022 06:14:30 GMT+0800 (China Standard Time)

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.

Gabe Szabo · Answer 24 · Thu Nov 17 2022 21:43:52 GMT+0800 (China Standard Time)

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.

JRod · Answer 25 · Thu Nov 17 2022 22:01:53 GMT+0800 (China Standard Time)

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.

Gabe Szabo · Answer 26 · Thu Nov 17 2022 22:09:45 GMT+0800 (China Standard Time)

@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.)

Doug Clutter · Answer 27 · Mon Nov 21 2022 21:33:13 GMT+0800 (China Standard Time)

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>

Eric Brunner · Answer 28 · Sat Nov 26 2022 06:08:03 GMT+0800 (China Standard Time)

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 · Answer 29 · Fri Dec 09 2022 07:15:15 GMT+0800 (China Standard Time)

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

Javier Calvarro Nelson · Answer 30 · Thu Dec 15 2022 20:44:14 GMT+0800 (China Standard Time)

this was addressed in 7.0.1 as part of #45028