Пользовательский атрибут AuthorizeAttribute не реализуется

В нашем решении MVC у нас есть две пользовательские реализации AuthorizeAttribute: одна называется BasicHttpAuthorizeAttribute и используется в производственной среде уже много лет, а другая RoleAuthorizeAttribute добавлена ​​недавно.

При создании RoleAuthorizeAttribute я просто скопировал BasicHttpAuthorizeAttribute и изменил некоторые уже переопределенные методы.

Оба атрибута служат для аутентификации пользователя и RoleAuthorizeAttribute проверки наличия у пользователя требуемой роли.

Однако RoleAuthorizeAttribute никогда не аутентифицирует пользователя. Он просто не вызывается, и вместо этого наши контроллеры MVC выдают исключение, когда пользователь, не вошедший в систему, достигает действия контроллера, и код запрашивает пользователя контекста.

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

Кто-нибудь может объяснить, почему этот класс не используется для аутентификации пользователей? Почему пользователь, не прошедший проверку подлинности, не перенаправляется на страницу входа, но если я заменяю RoleAuthorize на BasicHttpAuthorize или просто базовый Authorize, они перенаправляются?

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited = true, AllowMultiple = false)]    
public class RoleAuthorizeAttribute : System.Web.Http.AuthorizeAttribute
{
    /// <summary>
    /// Gets or sets the <see cref="Role"/> enumerations required for authorization.
    /// </summary>
    public Role[] RequiredRoles
    {
        get {...}
        set {...}
    }

    public bool RequireSsl { get; set; };

    public bool RequireAuthentication { get; set; }

    public RoleAuthorizeAttribute(params Role[] requiredRoles)
    {
        // ...
    }

    public override void OnAuthorization(System.Web.Http.Controllers.HttpActionContext actionContext)
    {
        // ...
    }

    protected override void HandleUnauthorizedRequest(System.Web.Http.Controllers.HttpActionContext actionContext)
    {
        // ...
    }

    private bool Authenticate(System.Web.Http.Controllers.HttpActionContext actionContext)
    {
        // ...
    }

    public static bool TryGetPrincipal(string authHeader, out IPrincipal principal)
    {
        // ...
    }

    public static bool TryGetAuthCookie(out IPrincipal principal)
    {
        // ...
    }

    private static string[] ParseAuthHeader(string authHeader)
    {
        // ...
    }

    private static bool TryGetPrincipal(string username, string password, out IPrincipal principal)
    {
        // ...
    }
}

А вот пример его использования:

namespace MyProject.Areas.Customer.Controllers
{
    [RoleAuthorize(Role.Customer, Role.CompanyAdmin)]
    public partial class OrderController : MyCustomController
    {
        private static readonly ILog Log = LogManager.GetLogger(typeof (OrderController));

        public ActionResult Index(int id)
        {
            // ...
        }
    }
}

Мы используем обычную аутентификацию, поэтому заголовок установлен следующим образом:

введите здесь описание изображения

Я видел старые вопросы о той же проблеме, но в этих случаях они также переопределяют метод AuthorizeCore, которого больше нет в классе AuthorizeAttribute.


comment
как вы используете этот атрибут? есть ли другие фильтры авторизации в конвейере запросов? что у вас в заголовках запросов?   -  person vasily.sib    schedule 23.04.2019
comment
Обновлен OP с запрошенной информацией.   -  person awj    schedule 23.04.2019


Ответы (1)


Я сам понял, почему это происходит.

Есть два AuthorizeAttributes — один в пространстве имен System.Web.Http, а другой в System.Web.Mvc. Я не знал об этом и пытался создать универсальный атрибут, поэтому мой атрибут работал для запросов WebAPI, но не для запросов контроллера MVC.

Разница между этими двумя атрибутами заключается в методе OnAuthorize, где каждый из них принимает другой аргумент контекста.

Как только я создал два отдельных атрибута (почти идентичных), каждый из которых производен от другого AuthorizeAttribute, все заработало, как и ожидалось.

person awj    schedule 30.04.2019