Using fallback authorization policy breaks Blazor Server after migrating to .NET 8

[CoskunSunali]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

In .NET 7, the blazor.server.js file has been served by the static files middleware, and placing the static files middleware prior to authorization middleware was enough to serve this file to anonymous users.

In .NET 8, the blazor.server.js file gets served by its own endpoint, using endpoint routing, and requests to this file eventually need to be authorized by the authorization middleware. This change is introduced via dotnet/aspnetcore#45897.

Consider a multi-tenant scenario where both the default and fallback policies are set identically, and the tenant is resolved by using the first segment in the request path; e.g. tld.com/tenant-name/... and those requests to tenant endpoints get authenticated by an additional authentication scheme, which adds an additional identity to the request principal and the fallback authorization policy has requirements that check claims coming via that additional identity.

The problem is that requests to the blazor.server.js file are served at /_framework/blazor.server.js path, this path being hardcoded here, requests to this file do not get authenticated by the additional authentication scheme for tenants but still get challenged by the fallback policy because of the change at dotnet/aspnetcore#45897 and eventually return unauthorized result because the claims are missing - as expectedly.

One way of solving this issue would be to set the policy to be used by this specific endpoint serving the blazor.server.js file but current public API allows setting the authorization policy for the whole Blazor Hub, rather than individual endpoints that Blazor Server creates. We do not want to expose our Blazor Hub to anyone who is not a tenant user, but at the same time want to serve the blazor.server.js file even to the anonymous users.

What would be one way of fixing this behavioral breaking change using public API and will you please consider mentioning this behavioral change in the migration to .NET 8 documents?

Expected Behavior

No response

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

8.0.200

Anything else?

.NET SDK:
Version: 8.0.200
Commit: 438cab6a9d
Workload version: 8.0.200-manifests.cdf2cc8e

Runtime Environment:
OS Name: Mac OS X
OS Version: 14.3
OS Platform: Darwin
RID: osx-arm64
Base Path: /usr/local/share/dotnet/sdk/8.0.200/

.NET workloads installed:
There are no installed workloads to display.

Host:
Version: 8.0.2
Architecture: arm64
Commit: 1381d5ebd2

.NET SDKs installed:
7.0.406 [/usr/local/share/dotnet/sdk]
8.0.200 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 7.0.16 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 7.0.16 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
None

Environment variables:
Not set

global.json file:
Not found

[halter73]

What would be one way of fixing this behavioral breaking change using public API and will you please consider mentioning this behavioral change in the migration to .NET 8 documents?

There are a couple of ways to work around this:

• Apply the [Authorize] attribute in the _Imports.razor file in the Blazor project rather than rely on a fallback policy.
  • For non-blazor endpoints explicitly use [Authorize] or RequireAuthorization.
• Add [AllowAnonymous] to the /_framework/blazor.server.js endpoint.

  app.MapBlazorHub().Add(endpointBuilder =>
  {
      if (endpointBuilder is RouteEndpointBuilder { RoutePattern: { RawText: "/_framework/blazor.server.js" } })
      {
          endpointBuilder.Metadata.Add(new AllowAnonymousAttribute());
      }
  });

• Register a custom AuthorizationHandler that checks the HttpContext to allow the /_framework/blazor.server.js through.

This is a good example of how every bug fix is also a breaking change. A lot of people were running into issues where their configuration of StaticFileOptions interfered with Blazor's ability to server its static resources in dotnet/aspnetcore#19578. That said, you can try submitting a PR to https://github.com/dotnet/docs/blob/main/docs/core/compatibility/8.0.md#aspnet-core if you think it's worthwhile.

This seems similar to dotnet/aspnetcore#51836 where the ask is for some Blazor static resources to be exempted from the fallback authorization policy, so we'll continue using that issue to track making that easier in a future release.

@guardrex It looks like the documentation at https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/blazor/fundamentals/static-files.md ought to be updated to reflect that Blazor static files no longer rely on UseStaticFiles and instead are mapped using endpoint routing. Hopefully anyone else who runs into this problem will find this GitHub issue.