开发者

Custom Authorization Attribute

开发者 https://www.devze.com 2023-02-15 04:49 出处:网络
I am implementing a CustomAuthorizeAttribute. I need to get the name of the action being executed. How can i get the name of current action name getting executed in the A开发者_Go百科uthorizeCore func

I am implementing a CustomAuthorizeAttribute. I need to get the name of the action being executed. How can i get the name of current action name getting executed in the A开发者_Go百科uthorizeCore function which i am overriding ?


If you're using cache (or have plans to), then overriding AuthorizeCore, like Darin Dimitrov shows in this answer is a much safer bet:

protected override bool AuthorizeCore(HttpContextBase httpContext)
{
    var routeData = httpContext.Request.RequestContext.RouteData;
    var controller = routeData.GetRequiredString("controller");
    var action = routeData.GetRequiredString("action");
    ...
}

The reason for this is documented in the MVC source code itself:

AuthorizeAttribute.cs (lines 72-101)

public virtual void OnAuthorization(AuthorizationContext filterContext) {
    if (filterContext == null) {
        throw new ArgumentNullException("filterContext");
    }

    if (OutputCacheAttribute.IsChildActionCacheActive(filterContext)) {
        // If a child action cache block is active, we need to fail immediately, even if authorization
        // would have succeeded. The reason is that there's no way to hook a callback to rerun
        // authorization before the fragment is served from the cache, so we can't guarantee that this
        // filter will be re-run on subsequent requests.
        throw new InvalidOperationException(MvcResources.AuthorizeAttribute_CannotUseWithinChildActionCache);
    }

    if (AuthorizeCore(filterContext.HttpContext)) {
        // ** IMPORTANT **
        // Since we're performing authorization at the action level, the authorization code runs
        // after the output caching module. In the worst case this could allow an authorized user
        // to cause the page to be cached, then an unauthorized user would later be served the
        // cached page. We work around this by telling proxies not to cache the sensitive page,
        // then we hook our custom authorization code into the caching mechanism so that we have
        // the final say on whether a page should be served from the cache.

        HttpCachePolicyBase cachePolicy = filterContext.HttpContext.Response.Cache;
        cachePolicy.SetProxyMaxAge(new TimeSpan(0));
        cachePolicy.AddValidationCallback(CacheValidateHandler, null /* data */);
    }
    else {
        HandleUnauthorizedRequest(filterContext);
    }
}

Even if you didn't plan on using cache, those two magic strings seem a small price to pay for the peace of mind you get in return (and the potential headaches you save yourself.) If you still want to override OnAuthorization instead, you should at least make sure the request isn't cached. See this post by Levi for more context.


You can get the Action Name like this:

public class CustomAuthFilter : IAuthorizationFilter
    {
        public void OnAuthorization(AuthorizationContext filterContext)
        {
            filterContext.ActionDescriptor.ActionName;
        }
    }

EDIT:

If you want to inherit from the AuthorizationAttribute you'll need to override the OnAuthorization method.

public class CustomAuthAttribute : AuthorizeAttribute
{
    public override void OnAuthorization(AuthorizationContext filterContext)
    {
        base.OnAuthorization(filterContext);
    }
}
0

精彩评论

暂无评论...
验证码 换一张
取 消