Правильный способ поддержки нескольких атрибутов авторизации в ASP.Net Web API 2 - PullRequest
0 голосов
/ 16 декабря 2018

Мое приложение ASP.Net Web API создало токен JWT при успешном входе в систему.

public IHttpActionResult LogOn([FromBody] LoginRequest request)
    {
        var result = _service.LogOn(request);
        if (result.Success)
        {
            var token = CreateToken(request.UserName);
            return Ok(OpResult<string>.SuccessResult(token));
        }

        return Ok(result);
    }

У меня есть все методы контроллера, украшенные атрибутом «Authorize», который делегирует мой TokenValidationHandler (наследует от DelegatingHandler) для проверки токена в последующих запросах.

[HttpGet]
[Authorize]
public IHttpActionResult GetAccount(){ // get user details here}

Теперь яесть требование не пускать пользователя, если он не создал учетную запись и не подтвердил свой адрес электронной почты.Так что моя идея заключается в том, что в первом методе (вход пользователя в систему) вместо простой проверки result.success и выдачи токена я бы также проверил, проверена ли полученная учетная запись на электронную почту.Если нет, я бы выдал токен jwt с дополнительным утверждением «emailverified», установленным в false.Таким образом, пользователи, которые еще не активировали свою электронную почту, могут по-прежнему входить в систему и получать этот токен jwt, но единственная разрешенная им операция - это VerifyEmail.

Как мне реализовать этот метод контроллера VerifyEmail?В идеале я хочу, чтобы это выглядело так:

[HttpGet]
[AuthorizeEvenIfEmailNotVerified]
public IHttpActionResult GetAccount()

Как мне реализовать AuthorizeEvenIfEmailNotVerified?Это другой обработчик, который наследует от DelegatingHandler?Но если у меня есть два таких обработчика (мой существующий handelr для обычной авторизации и этот новый), то как механизм ASP.Net узнает, в какой обработчик отправлять атрибут [Authorize] и в какой отправлять [AuthorizeEvenIfEmailNotVerified]?Или я должен использовать AuthenticationFilter?Но в этом случае кажется странным, что у меня есть два атрибута, делающие практически одно и то же (один аутентифицирует проверенного пользователя, а другой аутентифицирует неподтвержденного пользователя).И все же один из них реализован через [Authorize], поддерживаемый обработчиком, наследующим DelegatingHandler, тогда как другой реализован через атрибут, поддерживаемый AuthenticationFilter?

Или я поступаю неправильно?Для справки, я бы предпочел оставить проект свободным от каких-либо связанных с MVC библиотек, если в этом нет крайней необходимости.Также это проект .Net Framework 4.7.

1 Ответ

0 голосов
/ 14 июня 2019

Вероятно, роль будет самым простым решением.Создайте токен с соответствующей заявкой:

identity.AddClaim(new Claim(ClaimTypes.Role, "Verified")); //verified email
identity.AddClaim(new Claim(ClaimTypes.Role, "NotVerified")); //not verified email

Следующее добавление атрибута в контроллер:

[Authorize(Roles="NotVerified")]
...