Maintenant que nous avons compris l'authentification basée sur les jetons en utilisant les jetons Web JSON,
et également compris les avantages de l'utilisation de cette approche.
Le fait que nous construisons maintenant un serveur basé sur l'API Rest,
dans ce cours, signifie que
l'authentification basée sur le jeton Web JSON
est le plus adapté pour ce serveur que nous construisons.
Donc, mettons à jour notre serveur API Rest pour utiliser les jetons Web JSON dans cet exercice.
Pour commencer à mettre à jour le serveur sur votre terminal,
installons d'abord le jeton Web JSON et le module passeport JWT Node.
Ainsi, à l'invite de type npm, installez,
passeport JWT JSON Web Token et moins enregistrer.
Comme vous pouvez le voir, j'utilise JSON Web Token 8.3.0 et passeport JWT 4.0.0 dans ce cours.
Maintenant que nous avons terminé l'installation, continuons à mettre à jour notre serveur express.
Aller maintenant à notre code,
ajoutons un fichier nommé
conflict.js dans le dossier racine de notre projet.
Maintenant, ce fichier conflict.js, je vais l'utiliser
pour stocker des informations de configuration pour notre serveur.
Maintenant, c'est une façon de centraliser toute la configuration de notre serveur.
Dans ce fichier conflict.js,
permettez-moi d'exporter un objet JSON ici.
Donc, nous allons dire, SecretKey,
et c'est là que
je vais spécifier la clé secrète que je vais utiliser pour signer mon jeton Web JSON,
et aussi me laisser spécifier une URL Mongo ici,
qui sera l'URL de
mon serveur MongoDB localhost 27017.
Une fois que nous avons terminé cela,
alors nous allons aller au fichier authenticate.js,
et dans le fichier authenticate.js, nous allons
maintenant créer la stratégie JWT.
C' est la stratégie de jeton web JSON qui est fournie par
notre module de nœud JWT passeport que nous venons d'inclure et donc nous dirons, la
stratégie de générativité passeport generativity.strategy.
Cela nous fournira
une stratégie basée sur JSON Web Token pour configurer notre module de passeport,
puis extraire JWT, que je
vais également obtenir de passeport JWT.
Nous aurons besoin de passeport JWT,
puis nous dirons « Extraire JWT ».
Ensuite, nous allons importer
le module JSON Web Token
que nous venons d'installer.
Une fois que nous les avons importés,
continuons et commençons à configurer quelques choses.
Avec ceux-ci, permettez-moi d'importer la configuration que j'ai
créée le fichier config.js que je viens d'ajouter à mon projet.
Une fois que j'ai terminé cela, laissez-moi aller de l'avant et
introduire quelques fonctions supplémentaires que j'exporterai d'ici.
Nous dirons, Exports.getToken,
cette fonction lorsque nous fournissons un paramètre là que j'appellerai simplement l'utilisateur,
qui sera un objet JSON,
cela créera le jeton et le donnera pour nous.
Pour créer le jeton, nous utiliserons le module jsonwebtoken que nous venons d'importer.
Donc, ici, nous allons dire retour JWT.sign,
cela nous aide à créer le jeton Web JSON et ainsi à l'intérieur qu'il
me permettra de fournir la charge utile et
la charge utile ici vient comme le paramètre ici appelé utilisateur,
puis le deuxième paramètre est
la clé secrète ou privée que je reçois de config. clé secrète,
que je viens de configurer un peu plus tôt.
Nous pouvons fournir des options supplémentaires ici.
Une option que je vais fournir à ceci est...
Ok, laissez-moi passer à la ligne suivante ici,
l'option que je vais fournir est ExpiResin.
Le ExpiResin vous dira combien de temps le jsonwebtoken sera
valide donc dans ce cas, je dis 3,600, ce qui signifie 3,600 secondes ou environ une heure.
Une heure plus tard, vous devrez renouveler le jsonwebtoken.
Une heure est assez longue pour que nous puissions tester notre application.
Vous pouvez définir ce paramètre pour être beaucoup plus long si vous le souhaitez.
Dans une application réelle, vous pouvez définir cela pour être une valeur beaucoup plus longue peut-être
quelques jours et vous attendre à ce que l'utilisateur se réauthentifie tous les quelques jours.
Maintenant, nous allons également configurer
la stratégie basée sur jsonwebtoken pour notre application de passeport.
Donc, permettez-moi de déclarer une variable appelée opts,
ce qui n'est rien d'autre que les options que je vais spécifier pour ma stratégie basée sur JWT.
Donc, nous dirons opts JWTFromRequest.
Maintenant, cette option spécifie
comment le jsonwebtoken doit être extrait du message de demande entrante.
C' est là que nous allons utiliser l'extrait JWT.
Cet extrait JWT prend en charge diverses méthodes
pour extraire des informations à partir de l'en-tête.
Il dira de AuthHeader de AuthHeader comme jeton porteur,
à partir de l'en-tête quel schéma et ainsi de suite.
Si vous lisez la documentation, il
vous dira différentes façons d'extraire le jsonwebtoken.
Vous pouvez passer le jeton dans le corps
du message de demande entrante et ensuite vous pouvez l'extraire à partir de là,
vous pouvez également utiliser des extracteurs personnalisés et ainsi de suite.
Dans ce cours, je vais utiliser la méthode la plus simple appelée
à partir de l'en-tête d'authentification comme jeton de porteur.
Nous sommes déjà familiers avec
l'en-tête d'authentification parce que nous l'avons utilisé avec
l'authentification de base et l'authentification basée sur les cookies plus tôt.
Donc, je vais juste utiliser
ce même champ d'en-tête dans le message de requête pour porter le jsonwebtoken.
Donc, je vais dire opts comme jeton porteur jsonwebtoken.
Le suivant, nous dirons Opts.SecretorKey,
c'est le deuxième paramètre qui m'aide à
fournir la clé secrète que je vais utiliser dans ma stratégie pour la connexion.
Donc, c'est l'autre option que je vais spécifier ici.
Une fois que je spécifie ces deux,
permettez-moi d'exporter la stratégie Passport
que je vais configurer ici pour dire ExportJWTPassport,
puis nous dirons passeport.use.
Rappelez-vous la façon dont vous avez spécifié la stratégie locale plus tôt.
Ici, nous spécifions la stratégie basée sur JWT,
puis nous allons créer une nouvelle stratégie JWT,
rappelons que nous venons d'importer la stratégie JWT
ici, c'est ce que nous allons utiliser pour créer une nouvelle stratégie.
Cette stratégie JWT prend
l'objet options que je viens de créer comme premier paramètre.
Les options de stratégie et la seconde est la fonction de vérification que je dois fournir,
et donc la fonction de vérification que je vais fournir dans la ligne suivante ici,
nous allons dire FunctionJWT_PayLoad.
Fait. Donc, lorsque cette fonction est appelée,
le fait est le rappel qui est fourni par passeport.
Ainsi, chaque fois que vous avez un passeport que vous configurez avec une nouvelle stratégie,
vous devez fournir le deuxième paramètre fait.
Grâce à ce paramètre fait,
vous transmettrez des informations au passeport qu'il
utilisera ensuite pour charger des choses sur le message de demande.
Ainsi, lorsque passeport analyse le message de demande,
il utilisera la stratégie, puis extraire des informations,
puis la chargera sur notre message de demande.
Donc, puisque cela se trouve être une fonction,
je vais juste utiliser une fonction de flèche ici,
j'ai aimé les fonctions de flèche.
Donc, laissez-moi créer cela comme une fonction de flèche ici,
et à l'intérieur de cette fonction,
nous allons définir la fonction.
Alors, que faisons-nous à l'intérieur de la fonction ?
Laissez-moi faire un console.log de
charge utile JWT et puis
laissez-moi juste déconnecter l'option qui vient ici,
l'option de charge utile JWT venir ici,
afin que vous puissiez voir ce qui est à l'intérieur de la charge utile JWT.
Ensuite, nous allons chercher un utilisateur en disant user.findone,
et puis je sais que dans le jwt.payload,
il y a un champ ID qui entre.
Donc, c'est ce que je vais affecter comme champ ID ici.
Donc, je dirai, user.findone et le second
est une fonction de rappel.
Comme vous vous rendez compte, cette méthode utilisateur Mongoose et vous essayez de trouver.
Donc, nous dirons si erreur alors, retour fait.
Qu' est-ce que cela a fait ? Ceci fait est le rappel que
passeport passera dans votre stratégie ici.
Donc, nous allons appeler cette fonction faite.
Cela fait dans le passeport prend trois paramètres.
Donc, vous pouvez voir les trois éléments d'information que cela fait attend il dit, erreur : any.
Donc, si vous avez une erreur, vous la transmettrez comme premier paramètre.
Le deuxième paramètre, l'utilisateur ? ,
Si un utilisateur existe,
alors la valeur de l'utilisateur sera transmise, puis si des informations ? :, any.
Donc, ces deux paramètres sont facultatifs et donc,
si vous transmettez des informations,
alors cela sera utilisé dans l'application.
Si je transmets false comme deuxième paramètre,
cela signifie que l'utilisateur n'existe pas ou cela.
Donc, il interprétera que l'utilisateur n'existe pas.
Donc, je pourrais dire, erreur,
faux, parce que c'est une erreur.
Donc, je ne vais pas passer une valeur utilisateur là,
je vais juste passer faux.
Là, le suivant,
nous pouvons dire, sinon si (utilisateur).
Donc, si l'utilisateur n'est pas nul,
nous dirons retour fait (null). Il
n'y a pas d'erreur donc, le premier paramètre sera
nul et le second paramètre est l'utilisateur,
mais nous venons de recevoir du MongoDB.
Sinon, nous reviendrons
fait avec null, false.
Donc, dans le dernier cas,
nous n'avons pas pu trouver l'utilisateur,
donc nous allons passer faux.
Donc, on va le gérer comme ça.
Si vous le souhaitez, vous pouvez créer un nouveau compte d'utilisateur à ce stade,
mais je vais garder cela simple juste pour que ce soit facile pour nous à comprendre.
Donc, nous allons juste dire, nul, faux. Ça fait six.
Donc, c'est la stratégie de passeport JSONWebToken que je viens de configurer ici.
Aussi, permettez-moi d'exporter
une fonction de plus à partir d'ici appelée verifyUser.
Maintenant, cette fonction VerifyUser,
je vais l'utiliser pour vérifier un utilisateur entrant.
Donc, c'est là que j'utiliserai passeport.authenticate.
Donc, le passeport.authenticate, la stratégie est la stratégie jwt que je viens de configurer,
la stratégie JsonWebToken que je viens de configurer.
Puis, la deuxième partie,
je dirais, session : faux.
Donc, cela signifie que,
nous ne créerons pas de sessions dans ce cas.
Comme vous vous souvenez, une application inverse,
nous utilisons l'authentification basée sur des jetons.
Donc, nous ne créerons pas de sessions.
Donc, c'est pourquoi j'ai défini cette session d'option sur false ici
, et bien sûr, la première a spécifié la stratégie que je vais utiliser.
Donc, pour vérifier un utilisateur,
j'utiliserai la stratégie JWT.
Comment fonctionne la stratégie des JWT ?
Dans la requête entrante,
le jeton sera inclus dans l'en-tête d'authentification comme nous l'avons vu ici.
Nous avons dit en-tête d'authentification comme jeton de porteur.
Si cela est inclus, cela sera extrait et qui sera
utilisé pour authentifier l'utilisateur en fonction du jeton.
Correction mineure ici, cela devrait être user.findone_id est égal à jwt_payload. _id,
car c'est la valeur id qui se trouve dans la charge utile de mon JSONWebToken.
Donc, nous cherchons l'utilisateur avec cet ID donné.
Donc, une fois que nous avons terminé cela, alors maintenant,
la deuxième partie que nous devons faire est que nous devons créer le jeton quelque part.
Maintenant, où créons-nous le jeton ?
Donc, c'est là que quelque chose que nous faisons dans le fichier users.js est très utile pour nous.
Dans le fichier users.js,
rappelez-vous que vous avez déjà ce point de terminaison appelé login.
Dans le point de terminaison de connexion,
vous utilisiez le nom d'utilisateur et le mot de passe pour authentifier l'utilisateur.
Ainsi, même avec le JSONWebToken pour émettre le JSONWebToken,
vous devez d'abord authentifier l'utilisateur en utilisant l'une des autres stratégies,
et si vous allez d'abord utiliser la stratégie locale,
nous authentifierons l'utilisateur en utilisant le nom d'utilisateur et le mot de passe.
Une fois que l'utilisateur est authentifié avec le nom d'utilisateur et le mot de
passe, nous émettrons le jeton à l'utilisateur en disant :
« Ok, vous êtes un utilisateur valide,
je vais vous donner le jeton ».
Toutes les requêtes suivantes porteront simplement le jeton
dans l'en-tête du message de demande entrante.
Donc, plus tôt, nous avions l'habitude de créer des sessions.
Lorsque l'utilisateur est authentifié,
nous n'utiliserons plus de sessions.
Au lieu de cela, lorsque l'utilisateur est authentifié à l'aide de la stratégie locale,
nous émettons un jeton à l'utilisateur.
Donc, à l'intérieur de cette méthode router.post que nous avons fait sur ce point de terminaison /login,
je vais créer un jeton et transmettre ce jeton à l'utilisateur.
Donc, ici, nous allons dire un router.post.
Laissez-moi créer un jeton.
Pour créer un jeton,
nous avons cette fonction dans le module d'authentification appelé Authenticate.GetToken.
Donc, rappelez-vous, que nous avons déjà,
pour faire usage de cela bien sûr,
même avant que nous commencions là,
je dois importer l'authentification.
Module ici. Donc, nous allons dire Authenticate require. /authentifier.
Donc, alors, quand dans votre code ici,
nous pouvons maintenant dire Authenticate.getToken,
et le getToken prend le paramètre ici.
Maintenant, rappelez-vous, revenant au fichier authenticate.js.
Le fichier authenticate.js prend ici un paramètre
qui sera utilisé comme charge utile lorsque vous créez le JSONWebToken.
Donc, dans le fichier users.js,
je vais créer un jeton en donnant une charge utile,
qui ne contient que l'ID de l'utilisateur.
Donc, nous allons dire id : req.user. _id.
C'est suffisant pour créer le JSONWebToken.
Nous ne voulons pas inclure d'autres informations de l'utilisateur.
Si vous choisissez, vous pouvez inclure d'autres parties des informations de l'utilisateur,
mais je suggère que garder le JsonWebToken petit.
L' ID utilisateur est suffisant car si vous avez besoin de rechercher l'utilisateur,
l'ID utilisateur est suffisant pour rechercher l'utilisateur dans MongoDB.
Donc, je vais juste encoder seulement l'ID de l'utilisateur ici.
Maintenant, vous savez que req.user serait déjà présent,
car lorsque passeport.authenticate ('local') authentifie l'utilisateur avec succès,
cela va charger la propriété utilisateur sur le message de requête.
Donc, c'est pour ça que je suis capable de faire ça ici.
Donc, c'est ce que je vais utiliser pour créer le jeton.
Maintenant, une fois le jeton créé,
je veux transmettre ce jeton à l'utilisateur.
Donc, dans l'objet rest.json que je fournis ici,
je porte déjà le drapeau vrai succès et aussi,
un message d'état ici.
Permettez-moi d'ajouter le jeton
comme l'une des propriétés dans le message de réponse ici.
Donc, le jeton que je viens de créer,
je vais le passer comme deuxième propriété à l'intérieur de cette chaîne Json ici.
Donc maintenant, lorsque mon client reçoit cette chaîne Json dans le corps du message de réponse,
il peut entrer et extraire le jeton de là.
C' est ça. Donc, nous avons maintenant mis à jour le fichier users.js,
et vous pouvez maintenant voir comment le jeton sera
créé et renvoyé à l'utilisateur lorsque l'utilisateur est authentifié avec succès.
Maintenant, ce schéma peut également être utilisé
lorsque vous utilisez une authentification tierce comme basée sur OAuth 2.0,
que nous allons examiner dans le module suivant.
Maintenant, la procédure sera similaire.
Vous allez créer un jeton lorsque l'utilisateur est authentifié par
le fournisseur d'authentification tiers ou OAuth,
puis vous transmettrez le jeton à l'utilisateur,
dans une approche similaire à celle que vous voyez ici.
Maintenant, une fois que nous avons fait cela,
alors nous allons au fichier app.js.
Dans le fichier app.js, parce que nous avons inclus un fichier de configuration ici.
Donc, laissez-moi exiger le fichier de configuration ici,
puis l'URL que j'utilise ici au lieu de coder cette URL,
je dirai Config.Mongourl.
Donc, maintenant, vous voyez comment mon fichier config.js peut être utilisé comme
un endroit centralisé où je peux préparer la configuration pour mon application.
C' est ça. Donc, ce qui se passe maintenant, c'est que lorsque l'utilisateur
s'authentifie sur le point de terminaison /login et que l'utilisateur est authentifié avec succès,
le jeton sera créé par le serveur et renvoyé au client ou à l'utilisateur.
Ainsi, le client inclura le jeton dans
chaque demande entrante suivante dans l'en-tête d'autorisation.
Maintenant, comment inclue-t-il l'en-tête d'autorisation ?
Revenons à authentic.js et ici,
vous voyez que nous avons dit extractJWt.FromAuthHeaderAsBearerToken ici.
Ainsi, cela sera inclus dans l'en-tête d'authentification en tant que jeton de porteur.
Je vais vous montrer comment cela est fait,
puis nous utilisons le facteur pour inclure le jeton porteur dans l'en-tête d'authentification.
Maintenant, quand cela arrive,
alors vous vous rappelez que juste en bas ici,
vous avez configuré cette méthode ici appelée VerifyUser,
qui fait appel à l'authentification du passeport avec JWT.
Donc, celui-ci utilise le jeton qui
vient dans l'en-tête d'authentification, puis vérifie l'utilisateur.
Donc, chaque fois que je veux vérifier l'authenticité de l'utilisateur,
je peux simplement appeler check user,
et cela va lancer l'appel au passeport.authenticate et vérifier le sser.
Si cela réussit,
cela me permettra de poursuivre.
Cette procédure est très similaire à ce que vous avez fait dans le
fichier users.js où vous appelez le même passeport.authenticate ('local').
Donc, si cela réussit,
alors vous allez de l'avant.
Si elle échoue, la fonction d'authentification renvoie le message d'erreur
au client indiquant que l'utilisateur n'est pas autorisé.
Donc, c'est déjà pris en charge.
Donc maintenant, que nous avons inclus ceci dans mon fichier authenticate.js,
n'importe quel endroit que je veux vérifier l'utilisateur,
je peux simplement appeler
cette fonction VerifyUser que
j'ai spécifiée ici ou l'exportation que j'ai spécifiée ici,
que nous allons appeler passeport.authenticate en utilisant
la stratégie JWT pour authentifier l'utilisateur.
Maintenant, comment on utilise ça ?
Maintenant, ce que nous allons faire, c'est nous allons aller dans chacun de nos routeurs,
et contrôler les options sur toutes les routes que nous voulons contrôler.
Donc, revenant au fichier app.js, maintenant,
que nous n'utilisons pas de sessions, je vais supprimer cette session d'ici,
parce que nous n'utilisons plus de sessions.
De même, je vais supprimer ce passeport.session d'ici aussi.
Ce n'est pas non plus nécessaire.
En outre, cette authentification, voir plus tôt,
lorsque j'ai configuré cette authentification,
cette authentification a été appliquée à chaque requête entrante unique.
Maintenant, je vais changer mon application, de
sorte que je ne demanderai l'authentification que sur certaines routes et pas sur toutes les routes.
Donc, laissez-moi supprimer complètement cette authentification de app.js.
Donc, maintenant, lorsque la requête arrive,
si elle est sur /point de terminaison,
l'index sera servi.
S' il est sur le point de terminaison /users, il vous permettra de naviguer vers
les différentes routes qui sont montées sur les /users dans le fichier users.js
, puis par la suite, les autres.
Ce que je vais faire maintenant, c'est que je vais laisser
le dossier public ouvert pour que tout le monde puisse y accéder.
Maintenant, dans de nombreuses applications,
cela peut être très bien.
Donc, je vais laisser ça ouvert.
Maintenant, sur les plats, les
promotions, et le point de terminaison des leaders,
Toutes les demandes get.
Je laisserai ces réponses sans nécessiter d'authentification.
Pourquoi voudrais-je faire ça ?
Si un utilisateur fait une demande get,
il veut juste récupérer des informations.
Donc, par exemple, du côté client si j'implémente une application Web en utilisant Angular
ou une application cliente en utilisant
un script ionique ou natif, alors peut-être que je veux implémenter mon application de telle sorte que la page principale affiche déjà des informations,
les informations génétiques que vous voulez mettre à la disposition de toute personne qui
visite votre site Web ou qui ouvre votre application.
Ainsi, les informations de base peuvent être affichées là.
Mais si vous voulez changer quoi que ce soit,
vous vous attendez à ce que l'utilisateur soit authentifié.
Ainsi, vous autorisez les opérations POST, les opérations de mise
et les opérations de suppression à effectuer uniquement par des utilisateurs authentifiés.
De même, pour les commentaires par exemple,
vous pouvez dire que les commentaires ne peuvent être publiés ou modifiés que par des utilisateurs authentifiés.
Ainsi, vous pouvez restreindre uniquement certaines routes pour les utilisateurs authentifiés,
l'autre route que vous pouvez laisser ouverte. Comment on fait ça ?
Maintenant, c'est là que l'utilisateur de vérification que nous
avons exporté à partir du fichier authenticate.js est utile.
Maintenant, au lieu de contrôler tous les points de fin,
toutes les différentes opérations sur les plats, promotions
et leaders en points,
nous n'ouvrirons que les opérations get pour n'importe qui
, mais les
opérations post, put et delete seront limitées aux utilisateurs authentifiés.
Dans l'affectation, vous allez ajouter une catégorie supplémentaire d'utilisateurs appelés utilisateurs admin.
Maintenant, vous limiteriez certaines opérations à effectuer uniquement par les utilisateurs admin.
Ainsi, par exemple, la modification des plats
ou la suppression des informations de vaisselle de la base de données,
sera limitée uniquement aux utilisateurs administrateurs.
Mais les utilisateurs de base peuvent poster des commentaires,
modifier les commentaires qu'ils ont postés,
et peut-être même enregistrer certains plats préférés.
Nous ferons cette partie dans le quatrième module.
Maintenant, comment contrôlons-nous des itinéraires spécifiques ?
C' est donc là que nous devons aller dans chacun des routeurs
, puis importer des contrôles sur des routes spécifiques.
Alors, commençons par la route de la vaisselle.
Donc, pour la route des plats,
vous vous souviendrez que cela est contrôlé dans le fichier dishRouter.js.
Donc, en allant à dishRouter.js,
nous allons d'abord importer l'authentification ici.
Donc, nous allons dire, const authenticate
require../authenticate parce que ce
fichier authenticator.js est dans le dossier de niveau supérieur.
Alors, rappelez-vous../authentifiez-vous ici.
Donc, une fois que vous importez l'authentification,
pour la route du routeur plat pour cette route
, l'opération get, je vais autoriser sans aucun problème.
Donc, c'est ouvert.
Donc, je n'imposerai aucune restriction.
A partir du post, si nous voulons appliquer plusieurs middleware,
nous pouvons simplement ajouter le principal à l'intérieur de celui-ci derrière l'autre.
Maintenant, quand le post est appelé, en ce
moment, vous exécutez simplement cette fonction ici.
Maintenant, juste avant cela,
je peux aller et dire, Authenticate.VerifyUser, là.
Alors, qu'est-ce que ça fait ?
Cela dit que si une demande de poste arrive,
j'exécuterais d'abord ce middleware, que
j'ai exporté à partir du fichier authentic.js,
j'applique d'abord cela,
ce qui équivaut à dire passeport authentifier JWT et vous vérifiez l'utilisateur.
Ensuite, si cela réussit,
alors je passerai à faire le reste.
Si l'authentification échoue à ce stade
, Passport Authenticate
répondra au client avec le message d'erreur approprié.
Donc, cela est déjà géré par passeport authentifier,
donc je n'ai pas à m'inquiéter quoi que ce soit au-delà de ce point.
Si j'ai traversé ce middleware et puis j'arrive à
exécuter la fonction suivante, cela signifie que mon authentification a réussi,
donc je suis capable de poursuivre à partir de ce point.
Donc, cela agit comme la barrière pour cette méthode de post.
Maintenant, en utilisant le même argument,
je peux simplement appliquer ce middleware particulier à toutes les autres méthodes.
Je peux le faire à la vente.
Bien que dans ce cas,
mettre ne va pas faire quoi que ce soit.
Mais en tout cas,
je vais simplement par souci d'uniformité,
je vais appliquer l'utilisateur de vérification à mettre également et bien sûr,
pour supprimer aussi, je vais appliquer mettre.
De même, en descendant à /dishid,
je vais permettre que cela fonctionne sans aucun problème.
Poster, je vais appliquer l'utilisateur de vérification.
Mettez aussi je vais appliquer l'utilisateur de vérification et pour supprimer aussi même.
Pour les /dishid/comments, je vais laisser le get open,
c'est correct pour tout le monde de récupérer des commentaires sur un plat spécifique.
Poster, je vais fermer ceci,
donc seuls les utilisateurs vérifiés peuvent poster des commentaires.
Mettez aussi je fermerai cela et supprimerai aussi.
Vous devez aller un peu plus loin et dire,
« Seuls les utilisateurs qui ont posté le commentaire peuvent supprimer leurs propres messages. »
Mais nous le ferons dans le prochain module.
Pour le moment, je vais dire,
« Ok, un utilisateur vérifié peut supprimer n'importe quel commentaire. »
Ce n'est bien sûr pas vrai,
nous pouvons mettre un contrôle supplémentaire,
mais nous le ferons dans le prochain module de ce cours.
Donc, pour supprimer aussi j'applique la même chose.
Encore une fois, pour le routeur de plat commentaires/commentaires Id,
obtenez je vais le laisser ouvert.
Post, je vais le laisser fermé.
Mettez aussi fermez-le et puis pour supprimer aussi je fermerai cela.
Supprimer bien sûr, comme je
l'ai dit, l'opération de suppression devrait être autorisée seulement un utilisateur qui
a créé le commentaire devrait être invité à le supprimer,
mais vous devez mettre en place quelques choses supplémentaires pour que cela fonctionne correctement,
ce que nous allons faire dans le module suivant.
Pour le moment, nous disons qu'un utilisateur vérifié peut supprimer un commentaire spécifique, c'est tout.
Maintenant, nous allons appliquer le même principe au routeur promo et aussi au routeur leader.
Donc, aller dans le routeur promo,
laissez-moi importer authentifier
et puis obtenir est ouvert,
donc c'est le routeur leader.
Donc, obtenir est ouvert.
Post, Je vais contrôler que,
mettre, contrôler, supprimer, contrôler,
routeur de leader, ID de leader,
get est ok, post,
contrôlé, mettre est contrôlé et supprimer est contrôlé.
Même chose avec le routeur promo.
Laissez-moi, exiger l'authentification
et puis pour la route get est ouvert,
POST est contrôlé, mis est contrôlé,
delete est contrôlé, la même chose pour le Promorouter/PromoID.
Get est ouvert, POST est contrôlé,
mettre et supprimer sont également contrôlés, c'est tout.
Sauvegardons tous les changements.
Donc, une fois que nous avons terminé toutes les modifications,
sauvegardons les modifications.
Maintenant, notre application est prête à être testée.
Donc, allons redémarrer notre serveur,
ou si le serveur n'est pas en cours d'exécution,
nous allons juste démarrer le serveur.
En allant au terminal,
mon serveur n'est pas en cours d'exécution.
Donc, laissez-moi démarrer le serveur en tapant npm start.
Fait intéressant, il vient de lancer une erreur ici,
je voulais juste vous illustrer que même je peux faire des erreurs,
donc vous verrez qu'il y a une erreur ici qui dit,
« Impossible de trouver module.authenticate », puis si je regarde à travers le code,
je trouve que ce problème s'est produit dans le,
où est-ce que cela s'est produit ?
Donc, je cherche juste ici,
et puis quelque part ici,
j'ai remarqué que ce problème s'est produit dans mon fichier users.js.
Donc, juste là, il dit,
c'est dans le fichier users.js.
Donc, en allant au fichier users.js, réparons cela.
Aller
au fichier users.js, juste en haut quand j'avais besoin d'authentifier, j'ai dit,
« .authenticate », et comme je vous le disais,
cela devrait être un point car il est dans le dossier supérieur.
Ce fichier users.js dans le dossier Routes,
et authenticate se trouve dans le dossier Projets Route, donc il doit être dot authenticate.
Donc, si vous faites des erreurs, voilà,
c'est comme ça que vous allez vous rappeler l'erreur que vous avez introduite.
Donc, sauvegardons les modifications, puis redémarrez notre serveur.
Encore une fois, revenant à ce terminal,
laissez-moi démarrer mon serveur et mon serveur est maintenant opérationnel,
allons à Postman et puis testez notre application.
Maintenant, dans Postman, permettez-moi d'abord de faire
un GET sur localhost : 3000/plats, puis quand je fais un GET,
c'est réussi parce que le point final GET n'est pas contrôlé.
Donc, je peux faire un GET sur les plats,
je peux faire un GET sur les promotions,
et tout fonctionne très bien.
Mais si j'essaie de faire un POST sur les plats,
alors laissez-moi trouver où j'ai fait un POST sur les plats.
Ici, j'ai fait un POST sur les plats.
Donc, quand j'ai essayé de faire un POST sur la vaisselle,
il dit immédiatement non autorisé.
Donc, mon module Passport a réalisé que je ne suis pas autorisé, donc je ne suis pas autorisé à le faire,
donc c'est ce dont il me rappelle.
Laissez-moi nettoyer les cookies de,
au cas où vous trouvez un cookie dans votre Postman il suffit de supprimer le cookie
correspondant au localhost parce
que ce cookie n'est plus nécessaire et ne sera pas nécessaire.
Donc, même si je supprime le cookie puis POST,
il dira toujours non autorisé.
Donc, je ne suis pas autorisé à faire ces opérations.
Donc, je dois me connecter.
Maintenant, si vous avez fait l'exercice précédent,
vous auriez quitté l'utilisateur que vous avez inscrit plus tôt.
Donc, par exemple, vous auriez inscrit cet utilisateur particulier dans l'exercice précédent,
laissez-moi essayer d'inscrire à nouveau le même utilisateur et
mon serveur devrait se plaindre en disant UserExistsError, ce qui signifie que l'utilisateur existe,
donc je n'ai pas besoin de m'inscrire à nouveau.
Si vous avez supprimé l'utilisateur de votre MongoDB,
il suffit d'inscrire cet utilisateur une fois de plus, puis nous allons nous connecter.
Donc, nous allons envoyer une demande de connexion à ce point final.
Donc, lorsque j'envoie la demande de connexion en faisant un POST à l'utilisateur final,
remarquez ce qui est retourné par mon serveur.
Vous remarquez immédiatement que dans le message de réponse
avec l'indicateur de succès et le message d'état,
vous obtenez également un jeton ici.
Maintenant, ce jeton particulier,
j'ai besoin de copier ce jeton,
car dans mes demandes suivantes,
je devrai inclure ce jeton.
Donc, laissez-moi aller à la version brute de ceci et que je vais copier ce jeton.
Ce jeton n'est rien d'autre qu'une longue chaîne là-bas,
alors laissez-moi copier ce jeton.
Alors maintenant, si vous êtes curieux de savoir ce qui est contenu dans ce jeton,
le jeton Web JSON peut être examiné.
Il existe un site particulier où vous pouvez entrer et taper
votre jeton Web JSON, puis vérifier réellement ce qui se trouve à l'intérieur du jeton Web JSON.
Faisons ça comme la prochaine étape.
Dans une fenêtre de navigateur,
tapez simplement jwt.io et cela vous mènera à ce site appelé JSON Web Token jwt.io.
Si vous vous souvenez, dans la conférence,
je vous avais montré la structure du jeton Web JSON
et vous avais montré que le jeton Web JSON contient trois parties : l'en-tête,
la charge utile et les informations qui s'y trouvent.
Maintenant, dans ce cas,
les informations sont ici donc je vais
coller mon jeton Web JSON dans ce côté gauche,
alors laissez-moi le sélectionner et puis coller mon jeton Web JSON dans
le côté gauche dans la partie codée, puis sur le côté droit,
il vous montre exactement ce qui est dans le jeton Web JSON que je viens de créer.
Donc, il dit que l'en-tête contient ces deux éléments d'information.
La charge utile indique qu'elle contient l'ID de
l'utilisateur, puis la signature en bas ici.
Donc, c'est ce qui est contenu dans mon jeton Web JSON.
En revenant à Postman,
laissez-moi essayer de prendre la vaisselle.
Donc, quand je dis GET localhost:3000/plats,
il retournera toujours une chaîne vide,
tableau vide ici parce que ma base de données ne le contient pas.
Donc, laissez-moi POST un plat dans ma base de données.
Donc, je vais choisir l'opération POST et dans le corps,
vous voyez que j'ai mon plat ici.
Dans l'en-tête, je vais ajouter le nouvel en-tête appelé
autorisation et vous vous souvenez que précédemment pour l'autorisation de base,
vous avez dit basique et ensuite vous aviez la chaîne codée Base 64 là.
Si vous voulez inclure votre jeton Web JSON dans l'en-tête d'autorisation,
parce que dans notre code,
nous avons dit autorisation comme jeton porteur.
Donc, si vous voulez inclure le jeton dans l'en-tête d'autorisation,
dans l'autorisation, nous dirons porteur et ensuite nous allons coller
cette chaîne de jeton que nous venons de copier à partir de notre demande entrante.
Donc, nous allons coller la chaîne de jeton dedans.
Donc, c'est ce qui sera contenu dans
l'en-tête d'autorisation de ma demande sortante ici,
requête POST sortante ici.
Donc, remarquez, le côté gauche dit porteur et le côté droit est la chaîne,
le jeton que je viens de copier à partir
du point où je me suis connecté, puis laissez-moi envoyer le message POST
maintenant et mon POST est maintenant réussi et ceci est posté dans ma base de données.
Maintenant, si vous voulez être sûr qu'il a été posté,
faisons un GET et quand vous faites un GET,
vous pouvez voir qu'en effet ce plat a été inséré dans ma base de données comme indiqué ici.
Donc, c'est ainsi que vous allez utiliser les jetons Web JSON dans votre application.
Ainsi, chaque fois que vous avez besoin d'effectuer une
opération POST, PUT ou DELETE sur l'un des points de terminaison,
vous seriez enfermant.
Donc, laissez-moi revenir à cette demande POST ici.
Dans l'en-tête, vous allez mettre
ce champ d'autorisation et puis cela serait inclus dans l'autorisation,
vous le commencerez avec le porteur, puis la chaîne de jeton,
après cet espace porteur,
un seul espace, puis la chaîne de jeton qui suit.
Donc, c'est ainsi que vos messages de requête
porteraient le jeton Web JSON dans l'en-tête du message de demande sortant.
Vous pouvez également inclure le jeton dans le corps du message de demande sortante.
Maintenant, pour cela, vous devrez configurer
votre serveur express en particulier le JWT supplémentaire dans le
fichier authenticate.js pour l'accepter
du corps, donc vous rappelez que nous avons vu que
le JWT supplémentaire prend en charge de nombreuses façons différentes d'extraire
le jeton Web JSON à partir du demande.
Donc, là, vous devez spécifier,
si vous allez l'inclure dans le corps,
vous devez spécifier cette information là.
Maintenant, les détails sur la façon de le faire, vous pouvez consulter
la documentation du module Passeport JWT pour comprendre comment cela est fait.
Dans ce cours, je vais simplement l'utiliser dans l'en-tête d'autorisation
comme je l'ai montré ici et cela fonctionne très bien pour la plupart des cas.
Maintenant, si vous développez une application Web,
une application Angular ou une application Ionic ou NativeScript,
vous devez être en mesure de configurer
cette application de sorte que le jeton Web JSON sera inclus dans l'en-tête d'autorisation.
Dans la dernière leçon de ce cours,
je vais vous montrer comment intégrer le client et le serveur,
le client que vous avez développé dans les cours précédents avec
le serveur que nous avons développé dans ce cours.
Avec cela, nous complétons cet exercice.
Dans cet exercice, nous avons vu comment nous
pouvons configurer notre application pour utiliser les jetons Web JSON,
et nous avons vu comment nous gérons l'authentification de l'utilisateur en utilisant le jeton Web JSON, en
utilisant le support du module Passport et du module Passport JWT,
et les modules JSON Web Token Node.
Avec cela, nous complétons cet exercice.
C' est le bon moment pour vous de faire un Git Commit avec le message Passport JWT.