Xác định xem mã thông báo mang đã hết hạn hay chỉ được ủy quyền

Question

Ứng dụng góc của tôi đang sử dụng mã thông báo mang như được nêu trong loạt bài viết http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/. Tôi đã làm theo ví dụ được chia đôi để mã thông báo làm mới liên tục khi mã thông báo truy cập đã hết hạn (qua mã http 401).

Câu hỏi của tôi là làm cách nào tôi có thể xác định liệu mã thông báo mang đã hết hạn hay chỉ đơn giản là trái phép dựa trên vai trò được xác định?

Ví dụ: phương pháp api web của tôi có thuộc tính [Authorize (Roles = "Admin")]. Khi tôi thực hiện cuộc gọi đến đó, tôi nhận lại lỗi 401 của tôi, dự kiến. Tuy nhiên, khi mã thông báo truy cập của tôi hết hạn và tôi thực hiện một cuộc gọi phương thức api web khác, nó cũng trả về lỗi 401. Heres handler responseError tôi trong đánh chặn của tôi:

 responseError: function (rejection) { 
      var deferred = q.defer(); 
      if (rejection.status === 401) { 
       var authService = $injector.get('authService'); 
       authService.refreshToken().then(function (response) { 
        _retryHttpRequest(rejection.config, deferred); 
       }, function() { 
        authService.logOut(); 
        $location.path('/dashboard'); 
        deferred.reject(rejection); 
       }); 
      } else { 
       deferred.reject(rejection); 
      } 
      return deferred.promise; 
     } 

Tôi đã chơi xung quanh với những thứ khác nhau nhưng về cơ bản, tôi muốn làm mới thẻ của tôi và gửi lại yêu cầu của tôi khi thẻ truy cập đã hết hạn; tuy nhiên, tôi không muốn làm mới mã thông báo của mình nếu đó thực sự là yêu cầu bị từ chối do vai trò được chỉ định.

Mọi suy nghĩ?

Answer 1

Như đã lưu ý trong phản hồi của tôi đối với nhận xét của Cory Silva, thuộc tính Web API Authorize sẽ luôn trả lại 401 trái phép cho cả xác thực và ủy quyền.

Xem bài viết và sợi dưới đây:

http://leastprivilege.com/2014/10/02/401-vs-403/

Why does AuthorizeAttribute redirect to the login page for authentication and authorization failures?

Dường như có hai tùy chọn:

1. Khi tôi lưu trữ các thẻ lấy từ máy chủ uỷ quyền của tôi trong localStorage, tôi cũng lưu trữ hết hạn mã thông báo. Trong hàm response response, tôi so sánh hết hạn token đã lưu với datetime hiện tại. Nếu nó được xác định là hết hạn, hãy làm mới mã thông báo và gửi lại yêu cầu.

   responseError: function (rejection) { 
       var deferred = q.defer(); 
   
       if (rejection.status === 401) { 
        var tokenExpired = false; 
        var authData = localStorage.get('authorizationData'); 
        if (authData) { 
         tokenExpired = moment().isAfter(authData.expiration); 
        } 
   
        if (tokenExpired) { 
         var authService = auth;//$injector.get('authService'); 
         authService.refreshToken().then(function (response) { 
          _retryHttpRequest(rejection.config, deferred); 
         }, function() { 
          authService.logOut(); 
          $state.go('error'); 
          deferred.reject(rejection); 
         }); 
        } 
        else { 
         $state.go('error'); 
         deferred.reject(rejection); 
        } 
       } else { 
        $state.go('error'); 
        deferred.reject(rejection); 
       } 
       return deferred.promise; 
   } 
   

2. Sử dụng các câu trả lời được chấp nhận trong thread stackoverflow tôi tham chiếu ở trên và tạo AuthorizeAttribute của riêng tôi để xác định hết hạn thẻ so với truy cập trái phép.

   [AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited = true, AllowMultiple = true)] 
   public class AuthorizeAttribute : System.Web.Http.AuthorizeAttribute 
   { 
       protected override void HandleUnauthorizedRequest(HttpActionContext actionContext) 
       { 
        if (actionContext.RequestContext.Principal.Identity.IsAuthenticated) 
        { 
         actionContext.Response = actionContext.Request.CreateResponse(HttpStatusCode.Forbidden); 
        } 
        else 
        { 
         base.HandleUnauthorizedRequest(actionContext); 
        } 
       } 
   } 
   

Tôi nghĩ rằng tôi sẽ sử dụng phương án 2 để các mã lỗi một chút rõ ràng hơn cho khách hàng.