MapRazorComponents unexpectedly requires antiforgery middleware

[SteveSandersonMS]

Discovered by @davidfowl. If you're trying to make a minimal Blazor Static SSR project from scratch (not from the template), you may be surprised to find that you must call app.UseAntiforgery even if you're only receiving GET requests and don't have any forms in your whole app. If not, trying to visit any @page component will result in the error:

It's a pretty weird inconsistency that you get this for MapRazorComponents endpoints, but do not get this for minimal actions that return RazorComponentResult.

Possible solutions

• We could change EndpointMiddleware so that if it's a GET request, it doesn't try to enforce antiforgery checks. TBH I'm not sure why that's not already the case - do we even support supplying an antiforgery token with a GET request?
• Or, we could change RazorComponentEndpointFactory so that it registers a separate endpoint for GET vs non-GET and the GET endpoint doesn't have the RequireAntiforgeryTokenAttribute metadata.
• Or, we could change MapRazorComponents so that it somehow auto-registers the antiforgery middleware (though this is the least good solution, as it continues to couple different parts of the system and doesn't fix the inconsistency)

[javiercn]

@SteveSandersonMS that's a good catch.

We had some issues around in this area, but I thought we had addressed them.

I believe what is happening is that we wire up the Antiforgery metadata on the endpoint and there's logic to enforce that you have the middleware wired up, same as for the auth middlewares.

We do our own antiforgery handling (and respect the middleware result when present), so this should ideally not happen. We should find a way to be excluded from this check.

@captainsafia knows the details.

[captainsafia]

We could change EndpointMiddleware so that if it's a GET request, it doesn't try to enforce antiforgery checks. TBH I'm not sure why that's not already the case - do we even support supplying an antiforgery token with a GET request?

At the moment, we only check for the metadata in the middleware and not any other properties of the request. Admittedly, this is optimized for the minimal API scenario where we only add the metadata for endpoints that absolutely require it so that no additional checks are needed on the middleware hot path.

Or, we could change RazorComponentEndpointFactory so that it registers a separate endpoint for GET vs non-GET and the GET endpoint doesn't have the RequireAntiforgeryTokenAttribute metadata.

I'd prefer this approach. My "purist" take on this is that metadata should be the only indicator of whether you opt-in to certain behavior. It's up to the component applying the metadata (RazorComponentEndpointFactory or RequestDelegateFactory) to determine whether the metadata should be annotated.

That being said, my pragmatic side says that the first approach is valid, likely easier to implement, and has prior art in the routing middleware.

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.