Aspnetcore: Please make Blazor routing data available to AuthorizationHandlers

[willdean]

It's possible to add authorization to Blazor pages using policies, e.g. (from here):

@attribute [Authorize(Policy = "content-editor")]

One can then implement the various classes associated with an ASP.NET Core auth policy and end-up in a custom handler derived from AuthorizationHandler<T> where you can apply your policy.

If you have an app which is a mixture of Blazor pages and 'legacy' MVC/RazorPages code, you might even be able to use the same auth-handlers to enforce policy for both technologies, which feels great.

However, within the auth handler there appears to be no way to get to the routing data, and this would be useful in all the same situations which gave rise to #16695. For Blazor it's worse than #16695, because at least in the situation you can just inject IHttpContextAccessor and get to the routing data without any trouble, but in Blazor it appears that the only option is to poke around in the URL yourself, which is clearly not the intent of the routing architecture.

Perhaps there is some 'route parsing' component one could inject, but I couldn't find it if there is.

Being able to use the same Auth policy code irrespective of specific rendering technology feels like a real win for the architecture, but it's a little bit hindered if the handler can't get the full details of the request it's authorising.

[javiercn]

@willdean thanks for filing an issue.

To be clear, this issue is specifically about Blazor. This can be achieved today using RouteView and AuthorizeView separately and passing the routeData to the AuthorizeView as the Resource parameter.

However, we also ship AuthorizeRouteView but we don't expose the Resource parameter on it, so we can't pass it it as the resource.

The fix here is:

• Declare an object Resource parameter in AuthorizeRouteView
• Pass it as a parameter to AuthorizeRouteViewCore Here so that it is available to the reqruirements that want to evaluate it.

[mkArtakMSFT]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. However, keep in mind that there are many other high priority features with which it will be competing for resources.

[slorello89]

I will work on this one.