Aspnetcore: Feature request: Make RouteData or HttpContext available on AuthorizationHandlerContext

[mjrousos]

Is your feature request related to a problem? Please describe.

Prior to endpoint routing, AuthorizationHandlerContext's resource property was of type AuthorizationFilterContext from which it was possible to RouteData, HttpContext, etc.

Now, with EndpointRouting, AuthorizationHandlerContext.Resource is of type RouteEndpoint which describes the endpoint the call is going to, but doesn't include route data.

It's not too hard to work around this with IHttpContextAccessor.HttpContext.GetRouteData() but, given that it seems like a common scenario for auth handlers to access route data, it would be convenient to not have to inject an extra property into the handler to get that data.

Describe the solution you'd like

Expose RouteData or HttpContext directly from AuthorizationHandlerContext

[mjrousos]

@shaulbehr

[javiercn]

@mjrousos thanks for contacting us.

For triage, see related https://github.com/aspnet/AspNetCore/issues/15372

[mjrousos]

Thanks, @javiercn. Count this as another vote for that addition, then :)

[HaoK]

@blowdart this isn't super easy to do unless we introduce an additional context parameter that's part of the base IAuthorizationService contract. We need a breaking change I think

        Task<AuthorizationResult> AuthorizeAsync(ClaimsPrincipal user, object resource, IEnumerable<IAuthorizationRequirement> requirements);

The context factory needs to take the context object too, then we could just update Endpoint routing to pass in whatever it wants RouteData/HttpContext and it'd be available via a new Context object

```
public interface IAuthorizationHandlerContextFactory
{
AuthorizationHandlerContext CreateContext(IEnumerable requirements, ClaimsPrincipal user, object resource);
}

[pranavkm]

@HaoK there was also my PR from 3.x that might still work: https://github.com/dotnet/aspnetcore/pull/16714/files

[blowdart]

What's the risk here, this late on in 5.0? Would it be safer to look at it for 6?

[javiercn]

I think we should be able to do @pranavkm suggested option here. Note that we only need to pass in the HttpContext here, since the endpoint is available through it.

If we were to do this change it would be fine since it's opt-in, and if we wanted, we could even turn it on by default in 5.0 as it would not leave people in an insecure state (would cause an exception when you downcast). If we are willing to leave with the pain we would be causing people.

I don't think it would be a big deal since not many people might be using this aspect (it is somewhat advanced), it requires a trivial update (from ((Endpoint)resource) to ((HttpContext)resource).Features.GetFeature<IEndpointFeature>().Endpoint) and we can make an announcement for it.

I think it is at least worth bringing this into 5.0, even if we do it in an opt-in fashion with the idea of making it a default on 6.0

[willdean]

If someone is looking at the availability of route-data in Auth Handlers, could Blazor Server be considered too? There's currently no way to get it at all, sort of re-splitting the URL.

(Should I file a separate issue?)

[HaoK]

So a targeted fix like Pranav's where we only change the authorization middleware to always pass a new authz context object as the resource doesn't seem too bad. I like passing in a new AuthZMiddleware specific context object since that would let us add things to the context later, while if we just pass in HttpContext, if we ever want to add more things, it's going to be another breaking change.

[HaoK]

I'll open a PR with it on by default just to see how much breaks to start

[javiercn]

@willdean

If someone is looking at the availability of route-data in Auth Handlers, could Blazor Server be considered too? There's currently no way to get it at all, sort of re-splitting the URL.

For Blazor this would be a separate feature, but you can use RouteView and AuthorizeView separately and pass in the RouteData as the Resource to the AuthorizeView.

That said, we should probably expose Resource as part of AuthorizeRouteView, so if you want, feel free to file a separate issue for it.