Разница между AuthorizeAttribute и IAuthenticationFilter

Question

В ASP.Net Web API 2 (Owin), в чем разница между IAuthenticationFilter и AuthorizeAttribute?

В настоящее время я реализовал свое разрешение на создание моего собственного AuthorizeAttribute так:

public class IntegratedAuthorization : AuthorizeAttribute 
{ 
    protected override bool IsAuthorized(System.Web.Http.Controllers.HttpActionContext actionContext) 
    { 
     bool returnValue = false; 

     if (actionContext.Request.Headers.Authorization != null) 
     { 
      if (actionContext.Request.Headers.Authorization.Scheme != null) 
      { 
       if (actionContext.Request.Headers.Authorization.Scheme.ToLower() == "basic") 
       { 
        if (actionContext.Request.Headers.Authorization.Parameter != null) 
        { 
         // .... 
         // .... 
         // .... 
        } 
       } 
      } 
     } 

     return returnValue; 
    } 
} 

чем я добавил его к моему HttpConfiguration так:

config.Filters.Add(new IntegratedAuthorization()); 

Все работает отлично, но когда я искал в Интернете, я нашел много разработчиков, которые используют IAuthenticationFilter, как в этом уроке: Authentication Filters in ASP.NET Web API 2.

Теперь реальный вопрос, в чем разница между этими двумя методами? Что я должен использовать?

Спасибо!

Answer 1

AuthorizeAttribute - класс, предназначенный для авторизации приложения. Вы выполняете правильный подход.

IAuthorizationFilter - это более обобщенный интерфейс, который реализуется многими фильтрами, но они не обязательно обеспечивают авторизацию. В то время как MVC не очень-то заботится так или иначе, only way Сторонние библиотеки могут идентифицировать компонент авторизации в приложении и, таким образом, подключиться к безопасности приложения, это проверить, наследует ли он AuthorizeAttribute. Суть в том, что если ваш компонент авторизации не наследует AuthorizeAttribute, некоторые сторонние библиотеки могут работать некорректно в вашем приложении.

С AuthorizeAttribute реализует IAuthorizationFilter, у вас все еще есть доступ ко всем его функциям, включая метод OnAuthorization, о котором упоминал Фархад.

Единственным недостатком является то, что Microsoft полагает, что каждое приложение будет основываться на пользователях и ролях, создавая эти свойства AuthorizeAttribute. Итак, если у вас есть приложение, которого нет, вам может потребоваться скрыть эти свойства в вашей реализации.

[Obsolete("Not applicable in this class.")] 
[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)] 
[Browsable(false), EditorBrowsable(EditorBrowsableState.Never)] 
new public string Roles { get; set; } 

[Obsolete("Not applicable in this class.")] 
[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)] 
[Browsable(false), EditorBrowsable(EditorBrowsableState.Never)] 
new public string Users { get; set; } 

Одно дополнительное ограничение требуется для 3 сторон для подключения к вашей безопасности приложений - если вы переопределить OnAuthorization (обратите внимание, что вы не должны), важно, что успешное возвращение null разрешения на actionContext.Response собственности и неудачная авторизация должна установить его на ненулевое значение (обработчик, который будет принимать меры на основе отказа). Так работает реализация по умолчанию, и вы должны следовать одному шаблону, если вам нужно его настроить.