Learn-json-web-tokens: Stockage Web et amélioration progressive

Créé le 15 oct. 2015  ·  9Commentaires  ·  Source: dwyl/learn-json-web-tokens

Dans #5, #46 et la plupart des discussions en ligne, les gens semblent utiliser par défaut le stockage local / stockage de session pour les JWT, plutôt que dans un cookie. Cela nécessite l'utilisation d'AJAX dans toute l'application afin que l'en-tête puisse être défini à partir du stockage Web à chaque fois. Je crois comprendre que cela empêche les falsifications de demandes intersites (et tire essentiellement parti de la politique de même origine pour le faire).

Comment cela s'intègre-t-il avec l'amélioration progressive, où certains appareils ne prennent pas du tout en charge le javascript ?

enhancement question

Commentaire le plus utile

Pas nécessairement, bien que cela dépende de votre ensemble d'outils. Angular, par exemple, vous permet de définir cela une fois .. je pense que vous pouvez même le faire facilement avec jquery.

$.ajaxSetup({
   headers: { 'x-my-custom-header': 'some value' }
});

Un autre problème avec les cookies en tant que couche de transport pour les jetons est que vous utilisez 2 délais d'attente et que vous n'obtenez pas l'avantage d'éviter les problèmes CORS. Les cookies compliquent l'accès aux services Web RESTful. Il est beaucoup plus facile de construire un curl one liner pour accéder à une ressource avec un jeton que de le regrouper dans un cookie.

Tous les 9 commentaires

_Another_ _GRAND _ Question du _Wizard_ ! :+1:
Pour les besoins de ce micro-exemple, je pense que c'est "_Ok_" pour utiliser localStorage .
Soyons honnêtes, _tout le monde_ utilise React ces jours-ci sans se soucier de l'accessibilité.
Tous les enfants cool sont _way_ plus intéressés par _Shiny New Frameworks_ que par _Progressive Enhancement_...

Toutefois...
Dans notre application _actual_, nous utilisons cookies _precisely_ pour la rétrocompatibilité et l'amélioration progressive.
C'est pourquoi nous avons ajouté l'option à JWT2 ... voir : https://github.com/dwyl/hapi-auth-jwt2#want -to-sendstore-your-jwt-in-a-cookie

Donc, en conclusion : j'ajouterais localStorage à l'exemple de ce référentiel et j'ajouterais un comment informant les gens que l'utilisation de cookies pour stocker les JWT est "_Ohkay_" car vous obtenez toujours toute la _évolutivité horizontale_ et la sécurité avantages de l'utilisation des JWT tout en économisant _effort_ d'avoir à définir/obtenir le JWT et à l'ajouter aux en-têtes à chaque demande...

@rjmk & @nelsonic

y a-t-il une raison spécifique pour laquelle le JWTS stocké dans le stockage local doit être envoyé dans les en-têtes ou y a-t-il quelque chose de vulnérable/"mauvais" à propos de l'utilisation de https://www.npmjs.com/package/node-localstorage ?

@Jbarget construisez-vous un "_Universal_" qui vous oblige à avoir accès à localStorage sur le serveur ? Si tel est votre cas d'utilisation, le module node-localstorage servira votre objectif.
_Cependant_ vous devrez toujours envoyer _manuellement_ le JWT dans le header pour le renvoyer au serveur dans les requêtes "AJAX"... donc il n'y a pas beaucoup d'avantage à utiliser un _module_ si tout ce que vous voulez faire est d'obtenir/définir le jeton vers/de localStorage ...

@nelsonic, nous

@Jbarget avez-vous une _objection_ au stockage du JWT dans un cookie ? (_ça vous simplifie la vie..._)

@nelsonic pas d'objection, ai-je raison de penser que cela simplifie ma vie en pouvant accéder aux cookies de n'importe où dans l'application, par opposition au stockage local/de session ?

Cela simplifie votre application car une fois le cookie _défini_ par le serveur, _toutes_ les requêtes envoyées/reçues contiendront toujours le cookie. ce qui signifie que vous n'avez jamais besoin d'y penser après ce point.
En revanche, stocker le JWT dans localStorage signifie que vous ne pouvez pas avoir d'interaction non-ajax et vous devez vous rappeler de SET l'en-tête auth pour chaque demande que vous faites au serveur. .

Pas nécessairement, bien que cela dépende de votre ensemble d'outils. Angular, par exemple, vous permet de définir cela une fois .. je pense que vous pouvez même le faire facilement avec jquery.

$.ajaxSetup({
   headers: { 'x-my-custom-header': 'some value' }
});

Un autre problème avec les cookies en tant que couche de transport pour les jetons est que vous utilisez 2 délais d'attente et que vous n'obtenez pas l'avantage d'éviter les problèmes CORS. Les cookies compliquent l'accès aux services Web RESTful. Il est beaucoup plus facile de construire un curl one liner pour accéder à une ressource avec un jeton que de le regrouper dans un cookie.

Ce problème est automatiquement fermé car il a plus d'un an. N'hésitez pas à le rouvrir s'il est toujours pertinent pour votre projet.

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

rhewitt22 picture rhewitt22  ·  5Commentaires

nelsonic picture nelsonic  ·  5Commentaires

nelsonic picture nelsonic  ·  4Commentaires

sarneeh picture sarneeh  ·  3Commentaires

KumarS-Naveen picture KumarS-Naveen  ·  3Commentaires