Determina se il token al portatore è scaduto o è appena autorizzato

Question

La mia applicazione angolare utilizza i token al portatore come indicato nella serie di articoli http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/. Ho seguito l'esempio biforcuto per aggiornare in modo continuo i token quando il token di accesso è scaduto (tramite codice http 401).

La mia domanda è come è possibile determinare se il token al portatore è scaduto o semplicemente non autorizzato in base al ruolo determinato?

Ad esempio, il mio metodo web API ha l'attributo [Authorize (Roles = "Admin")]. Quando faccio una chiamata a questo, torno il mio errore 401, che è previsto. Tuttavia, quando il mio token di accesso scade e faccio un'altra chiamata al metodo web api, restituisce anche un errore 401. Heres mio gestore responseError nel mio intercettore:

 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; 
     } 

stavo giocando intorno con cose diverse, ma in fondo, mi piacerebbe per aggiornare il mio token e inviare nuovamente la mia richiesta quando il token di accesso è scaduto; tuttavia, non desidero aggiornare il mio token se si tratta di una richiesta negata a causa del ruolo specificato.

Qualche idea?

Answer 1

Come notato nella mia risposta al commento di Cory Silva, l'attributo Autorizzazione API Web restituirà sempre 401 non autorizzati sia per l'autenticazione che per l'autorizzazione.

leggi l'articolo e filo di seguito:

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

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

Sembra che ci sono due opzioni:

1. Quando devo conservare il token recuperato dal mio server di autorizzazione a localStorage, memorizzo anche la scadenza del token. Nella funzione interceptor responseError, si confronta la scadenza del token memorizzato con il datetime corrente. Se è determinato essere scaduto, aggiornare il token e inviare di nuovo la richiesta.

   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. Utilizzare la risposta accettata nel thread StackOverflow ho fatto riferimento sopra e creare il mio AuthorizeAttribute per determinare scadenza del token contro accessi non autorizzati.

   [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); 
        } 
       } 
   } 
   

Penso che ho intenzione di utilizzare l'opzione 2 in modo che i codici di errore un po 'più chiaro al cliente.