AuthorizeAttribute对象的生命周期是什么？是每个请求或瞬态网络？

I just wanted to know the life cycle of AuthorizeAttribute and started debugging the default constructor of the AuthorizeAttribute but could't get any hit.

我只是想知道AuthorizeAttribute的生命周期,并开始调试AuthorizeAttribute的默认构造函数,但是无法获得任何命中。

here is the code of custom Authorize filter.

这是自定义Authorize过滤器的代码。

 public class CustomAuthorizeAttribute :  AuthorizeAttribute
 {
    public CustomAuthorizeAttribute() : base()
    {
        string test = string.Empty;
    }
    public override void OnAuthorization(HttpActionContext actionContext)
    {
        //Some code
    }
}

Anyone please help me to understand the life cycle of this AuthorizeAttribute?

有谁请帮我理解这个AuthorizeAttribute的生命周期?

Thanks

1 个解决方案

#1

This is tricky to answer, because AuthorizeAttribute is both an Attribute and an IAuthorizationFilter.

这很难回答,因为AuthorizeAttribute既是Attribute又是IAuthorizationFilter。

In the context of an Attribute, it is loaded when GetAttributes() is called the first time by the MVC framework. Attributes are meta-data, so it shouldn't be surprising if this is loaded before the debugger is attached.

在Attribute的上下文中,当MVC框架第一次调用GetAttributes()时会加载它。属性是元数据,因此如果在附加调试器之前加载它,那就不足为奇了。

In the context of an IAuthorizationFilter, it depends on how the filter is registered. If registered as a global filter:

在IAuthorizationFilter的上下文中,它取决于过滤器的注册方式。如果注册为全局过滤器:

public class FilterConfig
{
    public static void RegisterGlobalFilters(GlobalFilterCollection filters)
    {
        filters.Add(new CustomAuthorizeAttribute());
        filters.Add(new HandleErrorAttribute());
    }
}

Then it is clearly instantiated during the startup of the MVC application, and in this case the filters collection is static so is only instantiated once per startup.

然后它在MVC应用程序启动期间清楚地实例化,并且在这种情况下,过滤器集合是静态的,因此每次启动时仅实例化一次。

If the filter is placed as an attribute on a controller or action method, that's when things get more confusing. When an action is run, the MVC framework loads any attributes that pertain to that action method using the FilterAttributeFilterProvider and executes them. In this case, there is an instance that is loaded as a IAuthorizationFilter which scans for another instance of the same class that is an Attribute.

如果将过滤器作为属性放置在控制器或操作方法上,那么当事情变得更加混乱时。运行操作时,MVC框架使用FilterAttributeFilterProvider加载与该操作方法相关的所有属性并执行它们。在这种情况下,有一个实例作为IAuthorizationFilter加载,它扫描作为Attribute的同一个类的另一个实例。

If you need to explicitly control lifetime of the filter, then you can build your own IFilterProvider that can do just that.

如果您需要显式控制过滤器的生命周期,那么您可以构建自己的IFilterProvider,它可以做到这一点。

But there is no way to control the lifetime of an attribute. You should just assume that it is always loaded as a singleton and there is no way to create or destroy it.

但是没有办法控制属性的生命周期。您应该假设它始终作为单例加载,并且无法创建或销毁它。

The default behavior of AuthorizeAttribute (as a filter) scans for another instance of AuthorizeAttribute (as an attribute) in order to read the user/group metadata that it contains. The filter does the heavy lifting, the attribute is just a marker. If this is too confusing, you can separate them into 2 separate classes as per Passive Attributes.

AuthorizeAttribute的默认行为(作为过滤器)扫描AuthorizeAttribute的另一个实例(作为属性),以便读取它包含的用户/组元数据。过滤器完成繁重的工作,属性只是一个标记。如果这太混乱,您可以根据被动属性将它们分成两个单独的类。

#1