Ermitteln, ob das Bearer-Token abgelaufen ist oder nur autorisiert wurde

Question

Meine eckige Anwendung verwendet Träger-Tokens, wie in der Artikelserie http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/ beschrieben. Ich habe das gegabelte Beispiel verfolgt, um Token nahtlos zu aktualisieren, wenn das Zugriffstoken abgelaufen ist (über den HTTP-Code 401).

Meine Frage ist, wie kann ich feststellen, ob das Bearer-Token abgelaufen ist oder nur einfach nicht autorisierte basierend auf der Rolle bestimmt?

Zum Beispiel hat meine Web-API-Methode das Attribut [Autorisieren (Rollen = "Admin")]. Wenn ich anrufe, bekomme ich meinen 401-Fehler zurück, der erwartet wird. Wenn jedoch mein Zugriffstoken abläuft und ich einen weiteren Web-API-Methodenaufruf tätige, wird ebenfalls ein 401-Fehler zurückgegeben. Heres mein responseError Handler in meinem Interceptor:

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

Ich spiele herum mit verschiedenen Dingen, aber im Grunde, würde Ich mag meinen Token aktualisieren und meine Anfrage erneut senden, wenn die Zugriffstoken abgelaufen sind; Ich möchte jedoch mein Token nicht aktualisieren, wenn es aufgrund der angegebenen Rolle wirklich eine abgelehnte Anfrage ist.

Irgendwelche Gedanken?

Answer 1

Wie in meiner Antwort auf Cory Silvas Kommentar erwähnt, wird das Web API Authorize-Attribut immer 401 zurückgeben, das sowohl für die Authentifizierung als auch für die Autorisierung nicht autorisiert ist.

Siehe Artikel und unten fädeln:

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

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

Es sieht aus wie gibt es zwei Möglichkeiten:

1. Wenn ich speichern die von meinem Autorisierungsserver abgerufen Token in localStorage, ich speichere auch den Ablauf des Token. In der Interceptor responseError-Funktion vergleiche ich den gespeicherten Token-Ablauf mit dem aktuellen datetime. Wenn festgestellt wird, dass sie abgelaufen ist, aktualisieren Sie das Token und senden Sie die Anfrage erneut.

   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. die akzeptierte Antwort im Thread Stackoverflow verwendet ich oben Bezug genommen wird und meine eigenen AuthorizeAttribute erstellen Token Ablauf gegen unberechtigten Zugriff zu bestimmen.

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

Ich denke, ich werde Option 2 verwenden, so dass die Fehlercodes ein wenig klarer an den Client.