AuthorizationContext conflicts with type in Microsoft.AspNet.Authorization

[davidfowl]

We really shouldn't be conflicting with our own system. Can we rename the AuthorizationContext in MVC to FilterAuthorizationContext or something?

/cc @rynowak @Eilon @danroth27

[davidfowl]

Scratch that, we have to rename it aspnet/Security#670 (comment)

[davidfowl]

I wonder if we should have an MvcAuthorizationHandler<TRequirement>:

public abstract class MvcAuthorizationHandler<TRequirement> : AuthorizationHandler<TRequirement, Microsoft.AspNet.Mvc.Filters.AuthorizationContext> where TRequirement : IAuthorizationRequirement
{

}

/cc @blowdart

[blowdart]

Why would mvc a handler all of its own? We worked hard not to link it to mvc. It's not so much a clash as an actual design decision. It won't be that often you need the mvc specifics. Auth on route info or request properties is odd.

[davidfowl]

By default the resource that MVC passes to the AuthHandler its own AuthorizationContext (which is actually quite handy, see the issue linked). This would just be a shortcut for that.

[blowdart]

(So basically no. We should not start having handlers for each framework. The context rename I don't care about though)

[davidfowl]

@blowdart Sure we don't have to have a type, the user can just declare the MVC specific resource. No biggie.

[Eilon]

So let's rename Microsoft.AspNetCore.Mvc.Filters.AuthorizationContext to Microsoft.AspNetCore.Mvc.Filters.AuthorizationFilterContext.