2016-04-17 11 views
0

[Q1] Welchen Vorteil bietet ein HTTP-Interceptor beim Ändern der config.headers ["Authorization"] (Frontend AngularJS), um den Wert von Token zu enthalten, wenn ich die Anfragen durch Überprüfung überprüfen kann das req.cookies-Objekt? (im Backend NodeJS)MEIN: Anmeldung von JWT

Ich versuche zu verstehen, wie JSON-Web-Token funktionieren. Die Demo-Anwendung, die ich eingerichtet habe, hat eine Login-Funktionalität.

  1. Auf GET '/ login' kann ich ein Token erstellen, ein Cookie damit setzen.
  2. Am Frontend kann ich auf ein JSON-Objekt zugreifen, das das Token enthält.
  3. Ich kann den Cookie in der Entwicklerkonsole anzeigen.

NodeJS:

index.js - Login Route

router.post('/login', function(req, res, next) { 
    Authenticator.find(req.cookies.token, req.body, Heartbeat.common, function(err, warning, data){ 
    if(err) { 
     res.status(404).send({token:false, warning: null, error:err}); 
    } else if(warning){ 
     res.status(200).send({token:true, warning: warning, error:null}); 
    } else { 
     res.cookie('token', data, {maxAge: 3600000, httpOnly:true}); 
     res.status(200).json({token:true, error: null}); 
    } 
    }); 
}); 

Authenticator.ctrl.js - Authenticator.find()

find: function(token, user, heartbeat, callback) { 
    if(!token) { 
    Auth.findOne({email:user.email}, function(err, data){ 
     if(err) { 
     console.log(err); 
     } else { 
     if(data) { 
      if(data.checkHash(user.password)) { 
      callback(null, null,TokenMaker.createToken(user.email, heartbeat)); 
      } else { 
      callback(Errors.login.strict.MISMATCH, null, null); 
      } 
     } else { 
      callback(Errors.login.strict.NOT_REGISTERED, null, null); 
     } 
     } 
    }); 
    } else { 
    callback(null, Errors.login.warning.ACTIVE_REFRESH, null); 
    } 
}, 

Winkelregler

app.controller('userAccessCtrl', ['$scope', '$http', function ($scope, $http){ 
    $scope.user = { 
    email: "[email protected]", 
    password: "12345679" 
    }; 
    $scope.error = {}; 
    $scope.loginAccess = function(user) { 
    var submitReady = true; 
    var emailStatus = EmailValidator.email(user.email); 
    var passwordStatus = EmailValidator.password(user.password); 
    if(typeof emailStatus === "string") { 
     $scope.error.email = emailStatus; 
     submitReady = false; 
    } 
    if(typeof passwordStatus === "string") { 
     $scope.error.password = passwordStatus; 
     submitReady = false; 
    } 
    if(submitReady) { 
     $scope.error = {} 
     var data = $scope.user; 
     $scope.user = {}; 
     $http.post('/login', data) 
     .then(function(success){ 
      console.log(success); 
      },function(error){ 
      console.log(error); 
     }); 
    } 

} 
}]); 

Console Antwort:

{ 
    "data": { 
    "token":true, 
    "error":null 
    }, 
    "status":200, 
    "config":{ 
    "method":"POST", 
    "transformRequest":[null], 
    "transformResponse":[null], 
    "url":"/login", 
    "data":{ 
     "email":"[email protected]", 
     "password":"12345679" 
    }, 
    "headers":{ 
     "Accept":"application/json, text/plain, */*", 
     "Content-Type":"application/json;charset=utf-8" 
    } 
    }, 
    "statusText":"OK" 
} 
+0

Wie wäre es mit einem Code des Interzeptors? Außerdem finden Sie in der Regel Personen, die lokalen und Sitzungsspeicher anstelle von Cookies verwenden. Idealerweise würden Sie das Token nach dem erfolgreichen Authentifizierungsaufruf an Ihr Backend speichern, und der Interceptor übernimmt einfach den Wert und erstellt den Header für jede Anforderung. Die Verwendung von Cookies im Vergleich zum Speicher hängt davon ab, wie Ihr Token eingerichtet ist, enthält beispielsweise das Ablaufdatum und viele andere Faktoren. Lies den Unterschied. – Vaelyr

+0

@Vaelyr Ich habe diese SO Frage [link] (http://stackoverflow.com/questions/3220660/local-storage-vs-cookies) angesprochen. Ich setze Ablaufzeiten für die Cookies sowie das Token. Ich bin neugierig auf die Verwendung eines Interceptors, wenn jede aufeinanderfolgende Anfrage das Token in dem Cookie enthalten wird (wenn das Speichern des JWT keine Belastung für den Server darstellt) –

+0

Wie ich meine zweite Frage verstehe, ist das nicht so in der Lage, den Cookie zum Laufen zu bringen? Egal, welche Lösung Sie wählen, Sie müssen sie an das Back-End übergeben, um es entweder über Header oder Cookie zu validieren. Es ist ein zustandsloser Mechanismus, also ist es das Gegenteil von der Belastung des Servers - es gibt keine Sitzung. Können Sie den Code anzeigen, in dem Sie die Kopfzeile erstellen? – Vaelyr

Antwort

1

Eigentlich ist es eine falsche Cookies und JWT Token zu verwenden. JWT-Token ist viel besser für die Authentifizierung als Cookies. Wenn Sie token verwenden, muss Ihr Server keine Sitzung in der Speicherdatenbank speichern. Dies ist ein großer Vorteil für Ihre Anwendung. Sie können Ihre Anwendung skalieren, neue Server hinzufügen, ohne darüber nachzudenken, wie Sitzungen zwischen Servern synchronisiert werden.

Kurz gesagt, wenn Sie JWT verwenden Token Ihre Flow nächsten ist:

  • Frontend (in Ihnen Fall ist es ein Winkel) sendet Login und Passwort/Login Route
  • Anmeldeinformationen Backend prüft und sendet Token (in Anfrage Körper, nicht in Cookies)
  • Frontend App speichert Token im lokalen Speicher oder Sitzungsspeicher des Browsers
  • und Sie können HTTP Interceptor schreiben, die alle Anforderungen an Backend ab und es wird „Autorisierung“ heade anhängen r auf alle Anfragen, es sieht aus wie nächste:

    Authorization: Inhaber hier-ist-your-jwt-Token

  • Backend diese Berechtigung Header überprüfen und wenn es richtig ist (siehe http://jwt.io zu lesen, wie Verifikation funktioniert) Backend kann Ihre Anfrage bedienen.

+0

"Eigentlich ist es falsch, Cookies und JWT-Token zu verwenden. JWT-Token ist viel besser für die Authentifizierung als Cookies" können Sie warum warum? Ich habe über XSS- und CSRF-Angriffe gelesen und sie sagen, dass das Speichern von Token in Cookies sicherer ist, indem httpOnly auf true gesetzt wird, sodass js keinen Zugriff auf Cookies ermöglicht. –

+1

Token wird sehr oft mit der API verwendet, wenn einige Server eine API für mobile Anwendungen, Desktops oder Websites bereitstellen. Der Hauptvorteil von Tokens ist ein Stateless - es bedeutet, dass Ihr Server keine Tokens (im Speicher, Redis, Datenbanken, Dateien ...) speichern muss, der Server generiert nur das JWT-Token und gibt es an die Anwendung zurück. Auf diese Weise können Sie Ihre Anwendung einfach skalieren. Wenn Ihre Anwendung sehr geladen ist, stellen Ihre Benutzer viele Anfragen an Ihr Back-End. Die Validierung der Benutzersitzung für alle Anfragen dauert länger als die Validierung des JWT-Tokens. –

+1

Natürlich Session-Cookie mit Flag HTTPonly ist sicherer und viel einfacher zu implementieren, aber wenn Ihr Backend Anforderungen von verschiedenen Hosts bedienen muss (wenn Sie mobile oder Desktop-Anwendung erstellen) wird es besser sein, JWT-Tokens zu verwenden und nicht Sitzung nicht mehr verwenden. –