Static Rendering and Antiforgery

[sbwalker]

PR #4239 is related to an issue I encountered when migrating the Blog module's Index.razor component from Interactive rendering to Static rendering. This migration was necessary because the Blog module's Index.razor component is generally used in public facing scenarios and therefore needed to be indexable for SEO purposes, but also needed to avoid the double-rendering UX issues of interactive components. After making the changes and deploying the module into production, a lot of exceptions began to appear in the event log. The exceptions were a bit cryptic:

Unhandled Exception: Incorrect Content-Type: application/json; For Endpoint: Fallback {*path:nonfile}

System.InvalidOperationException: Incorrect Content-Type: application/json;
at Microsoft.AspNetCore.Http.Features.FormFeature.InnerReadFormAsync(CancellationToken cancellationToken)
at Microsoft.AspNetCore.Components.Endpoints.RazorComponentEndpointInvoker.ValidateRequestAsync(HttpContext context, IAntiforgery antiforgery)
at Microsoft.AspNetCore.Components.Endpoints.RazorComponentEndpointInvoker.RenderComponentCore(HttpContext context)
at Microsoft.AspNetCore.Components.Rendering.RendererSynchronizationContext.<>c.<b__10_0>d.MoveNext()
--- End of stack trace from previous location ---
at Microsoft.AspNetCore.Routing.EndpointMiddleware.g__AwaitRequestTask|7_0(Endpoint endpoint, Task requestTask, ILogger logger)
at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
at Oqtane.Infrastructure.JwtMiddleware.Invoke(HttpContext context) in C:\Source\Projects\oqtane.framework\Oqtane.Server\Infrastructure\Middleware\JwtMiddleware.cs:line 90
at Oqtane.Infrastructure.TenantMiddleware.Invoke(HttpContext context) in C:\Source\Projects\oqtane.framework\Oqtane.Server\Infrastructure\Middleware\TenantMiddleware.cs:line 87
at Oqtane.Infrastructure.ExceptionMiddleware.Invoke(HttpContext context, IServiceProvider provider) in C:\Source\Projects\oqtane.framework\Oqtane.Server\Infrastructure\Middleware\ExceptionMiddleware.cs:line 25

It turns out that these are from bots which are making POST requests rather than GET requests to access various blog Urls (not sure why a bot would do this but its probably for nefarious reasons). Either way, this resulted in a deep investigation of the Blazor source code on GitHub to try to identify the source of the problem.

I was able to reproduce the problem locally using POSTMAN and logged the following issue in the Blazor repo:

dotnet/aspnetcore#55582

Steve Sanderson acknowledged the problem and it appears that Microsoft will change the behavior in .NET 9.

However, in the meantime it is not reasonable to deal with constant exceptions being logged so I looked for possible solutions. After enabling more detailed logging in appsettings.json I was able to see that Antiforgery was not being enabled by default for statically rendered components. This is because Oqtane uses a custom route fallback mechanism so that it can support its custom router. I was able to modify the code to enable Antiforgery for static components. The end result is that for this specific POST scenario, Blazor will no longer throw exceptions which resolves the original issue and improves the security profile when running on SSR.

This change should not cause any side effects, but I would still appreciate if folks could do some regression testing ie. browsing, login, logout, different render modes, .NET MAUI, etc...