[MUSIC]
Nous avions déjà développé un serveur API REST à part entière utilisant Express et
MongoDB dans le cadre de ce cours.
Pour que le serveur puisse communiquer de manière significative avec notre client,
nous y apporterons quelques ajustements mineurs afin qu'il renvoie le bon type de données.
Pour que notre implémentation client puisse fonctionner plus efficacement
avec les données renvoyées par notre serveur.
Donc, pour ce faire,
nous allons travailler sur quelques ajustements à notre côté serveur dans cet exercice.
Aller à notre serveur dans l'éditeur, avant de commencer à travailler sur le serveur,
je suggère que vous téléchargez toutes les images que j'ai fournies
sous forme de fichier zip dans les ressources d'exercice appelées images.zip.
Décompressez le fichier, puis obtenez toutes les images à partir de là,
puis copiez ces images dans le dossier des images publiques de notre serveur.
Donc vous voyez qu'ici j'ai
déjà copié toutes les images dans mon dossier d'images publiques ici.
Parce que notre serveur est celui qui va servir toutes ces images pour
notre application client.
Ensuite, nous allons au cors et ajustons cette liste blanche, ici.
Donc, pour notre application client Angular, si nous la démarrons
avec la commande ng serve, elle s'exécute à localhost:4200.
Donc, toutes les demandes venant de notre
application Angular vers le serveur porteront cela comme leur origine là-bas.
C' est pourquoi je vais ajouter cela dans ma liste blanche, afin
que tous les problèmes cors soient résolus automatiquement.
Donc, en allant dans ce fichier cors.js,
dans ma liste blanche, ici, laissez-moi ajouter dans
le http://localhost :, 4200.
Et c'est l'origine à partir de laquelle tout mon client Angular sera à
l'origine de la requête qui vient à ce serveur.
Donc, mes cors ne causeront pas de problèmes pour mai client Angular.
Ensuite, nous devons mettre à jour quelques-unes des routes pour gérer
les paramètres de requête, ainsi que quelques autres ajustements mineurs.
Laissez-moi commencer par les fichiers promoRouter.js.
C' est donc simple de se mettre à jour.
Donc, aller au fichier promoRouter.js, dans le fichier Promorouter, pour
la demande get que nous obtenons ici,
au lieu de faire des promotions.Find avec un JavaScript vide,
ici je fournirais le req.query comme
paramètre à cette promotions.Find ici.
Même chose avec le LeaderRouter aussi, alors laissez-moi aller au fichier leaderRouter.js.
Et dans le LeaderRouter aussi,
ici où vous trouvez leaders.Find avec l'objet JavaScript vide.
Au lieu de cela, remplacez-le par ce req.query, de sorte
que les paramètres de requête soient transmis.
Donc, c'est là que nous allons passer dans la colonne vedette
à travers comme paramètre de requête.
Maintenant, après avoir ajusté ces deux, nous allons maintenant travailler sur l'itinéraire plat,
donc aller au fichier dishRouter.js, même dans le Dish.Router, la même mise à jour ici.
Donc, allez à ce plats.Find dans la méthode get ici, changez cela en req.query.
Donc, avec cela, ma mise à jour Dish.Router a été terminée.
Donc, nous avons maintenant mis à jour le PromorOuter, le ReaderRouter, et
le Dish.Router, puis nous allons passer à mettre à jour ce FavoriTerOuter.
Maintenant, vous auriez implémenté le routeur favori dans le cadre de votre
quatrième affectation.
Maintenant, dans le FavoriTerouter, vous verrez que pour
le FavoriTerouter je ne vous montre pas la partie restante parce que
vous auriez dû faire dans le cadre de votre mission.
Permettez-moi d'abord d'attirer votre attention sur la méthode get pour
le favoriTerouter.route (« /:dishid').
Maintenant, je vais utiliser cette méthode get
pour vérifier simplement que le plat spécifique avec
un DishiD est déjà un favori pour l'utilisateur.
Donc, au lieu de simplement dire l'opération GET non prise en charge,
je vais juste tirer parti de la présence de cette opération get.
Et puis nous dirons,
favorités.Findone.
Et je dirai,
utilisateur : req.user.id.
Donc, nous allons trouver les favoris pour cet utilisateur particulier.
Et puis nous dirons, .puis, favoris.
Et, attraper ((err),
suivant (err)).
Et puis de même ici, nous allons ajouter l'erreur ici.
Suivant (err)), ici.
Donc, à l'intérieur de ce .puis, quand nous obtenons les favoris,
alors nous allons vérifier, si ( ! favoris).
Donc, s'il n'y a pas de favoris pour cet utilisateur,
alors évidemment le plat que nous vérifions n'existe pas.
Donc nous reviendrons, Res.StatusCode, 200.
setHeader ('Content-Type
'' 'application/json').
Et puis nous reviendrons,
en disant, « existe » : faux.
Donc, ce que nous spécifions ici est que si le get est fait
à ce point de terminaison avec un disHID, ce drapeau existe ici
sera défini sur true si ce plat fait partie de mes favoris.
Si ce plat ne fait pas partie de mes favoris, je vais définir le drapeau existe sur false.
Donc, ici, vous voyez que puisque je n'ai pas de favoris,
il existe donc devrait être automatiquement faux à ce stade.
Donc, nous allons dire « existe » : false, puis nous allons retourner les favoris, ici.
Eh bien, évidemment dans ce cas,
les favoris seraient nuls à ce stade, sinon.
Donc, ce qui signifie que les favoris n'est pas nul, donc nous allons dire si,
(favorites.dishs.indexOf),
donc nous allons chercher req.params.
DisHid, donc on va fouiller ça.
.Dish.Array, pour voir si le plat existe là-dedans.
Et s'il n'existe pas, évidemment cela retournera un index négatif ici.
Donc, dans ce cas aussi, je reviendrai exactement le même que ici.
Donc, si elle renvoie un index négatif,
cela signifie que même si cet utilisateur particulier a un favori du centre.
Ce plat spécifique n'existe pas dans la liste de
son favori, donc c'est pourquoi il va revenir exister faux ici.
Maintenant, sinon cela signifie que le plat existe dans la liste des favoris.
Donc, dans ce cas, je vais retourner le code d'état 200 existe est vrai.
Ainsi, lorsque l'utilisateur effectue une opération get sur
ce point final avec le /favorite/dishid.
Où le disHID est fourni en tant que paramètre ici.
Comme le paramètre d'enregistrements ici,
nous allons vérifier si ce plat existe dans les favoris.
Si aucun des favoris n'existe pour cet utilisateur, nous retournerons un false existant.
De même, si les favoris existent,
mais que ce plat particulier n'existe pas dans les favoris, alors il retournera un faux.
Sinon, il retournera un vrai.
Donc, ce drapeau existe peut être utilisé par mon client
pour vérifier si ce plat fait partie de la liste des plats préférés pour cet utilisateur ou non.
Enfin, nous allons mettre à jour le fichier users.js.
Maintenant, dans le fichier users.js, nous devons ajouter
un autre champ router.options ici parce que
parfois une demande de poste comme vous l'avez vu avec la connexion,
nous allons d'abord envoyer les options pour vérifier, en particulier avec les voitures,
si la demande de poste sera autorisée.
C' est pourquoi ils vont vérifier les voitures, les voitures avec des options ici et là.
Nous allons simplement retourner
un message d'état de 200 en réponse à cela.
Donc, pour tout point de terminaison sous les utilisateurs si nous avons reçu
les options retournera simplement un état 200 ici.
Maintenant, la fonction de connexion que nous avions implémentée plus tôt.
Nous avons simplement fait passeport.authenticate ('local') ici et
ensuite nous vérifions les valeurs restantes ici.
Maintenant, ce passeport.authenticate ('local'), si l'utilisateur n'est pas
authentifié, il renvoie simplement un non autorisé dans le message de réponse.
Maintenant, cela peut ne pas être très significatif pour
le côté client d'afficher ces informations.
C' est pourquoi nous allons améliorer cette méthode de post-connexion du routeur afin
que l'authentification renvoie des informations plus significatives à cette partie.
Donc, pour ce faire, nous ne allons pas faire l'
authentification du passeport à l'intérieur ici.
Au lieu de cela, nous allons prendre, alors laissez-moi supprimer cela de là,
et puis vous verrez comment je vais mettre à jour le post du routeur ici.
Donc, nous verrons CarsWithOptions.
Et puis nous inclurons le req, res et le suivant ici.
Et à l'intérieur de la req, res, et
ensuite ici, passeport.authenticate,
Nous appellerons ceci avec 'local'.
Maintenant, quand nous appelons ceci avec local, si une
erreur d'authentification se produit, passeport.authenticate peut être fait pour retourner la valeur d'erreur,
et aussi il retournera l'utilisateur s'il n'y a pas d'erreur.
Et il pourrait paramètre appelé info,
qui transportera des informations supplémentaires qui pourraient être transmises à l'utilisateur.
Cette erreur sera renvoyée lorsqu'il y a une erreur authentique qui se produit dans
le possible de s'authentifier.
Mais si les informations de l'utilisateur sont envoyées à passeport.authenticate mais que
l'utilisateur n'existe pas, cela n'est pas compté comme une erreur.
Au lieu de cela, il sera compté comme l'utilisateur n'existe pas.
Et cette information est transmise dans l'objet info qui entre.
Ainsi, l'erreur sera renvoyée lorsqu'il y a une erreur authentique qui se produit pendant
le processus d'authentification.
Mais les informations, elles contiendront des informations si l'utilisateur n'existe pas et donc
le passeport.authenticate transmet un message indiquant que l'utilisateur n'
existe pas ou que le nom d'utilisateur est incorrect ou que le mot de passe est incorrect.
Et ainsi de suite, afin que l'information soit transmise, dans le message d'information.
Maintenant, nous verrons comment cela nous est utile quand nous regardons le côté client un
peu plus tard.
Donc, dans cette situation,
nous allons gérer cela comme suit.
Et pas seulement cela, quand nous appelons ce passeport authentifier,
nous devons également passer dans un (req, res,
suivant) que cette bande de trois paramètres.
C' est donc la structure.
Lorsque vous devez appeler passeport authentifier,
attendez-vous à ce qu'il vous transmette des informations comme celle-ci comme une méthode de rappel ici.
Donc, vous devez également fournir ce req, res prochain juste là aussi.
Maintenant, si cela se produit.
Donc, nous allons dire si (err).
Donc, s'il y a une erreur qui se produit,
nous dirons retourner suivant (err), puis laisser le
gestionnaire d'erreurs de notre routeur express s'occuper de cela.
Maintenant, nous allons considérer d'autres situations.
Si ( ! ), donc si nous avons atteint ce point, cela signifie que ce n'est
pas une erreur qui s'est produite mais peut-être que l'utilisateur n'a pas pu être trouvé.
Si l'utilisateur n'est pas trouvé, l'utilisateur ici sera défini sur null dans ce cas.
Donc, dans cette situation, si l'utilisateur n'existe pas,
alors nous devons être en mesure de transmettre des informations au côté serveur.
Donc, ce que nous allons faire est que nous allons passer cette information dans ce format,
donc je vais couper ceci d'ici,
puis coller ici et ensuite nous allons le modifier.
Si l'utilisateur est nul, alors nous enverrons un StatusCode
de 401, ce qui signifie non autorisé,
puis nous enverrons l'information succès, false.
Et puis nous ne transmettrons pas le jeton, nous remettrons le message d'état.
Donc, ici, nous allons dire connexion, échec.
Et puis la troisième information transmettra cette information, cet
objet que nous avons reçu ici comme la troisième partie de
ce message de réponse que nous renvoyons de notre serveur ici.
Donc, l'indicateur de succès sera réinitialisé à false.
Le statut sera défini Connexion infructueuse et les informations d'erreur
qui sont transmises dans l'information seront transmises.
Maintenant, notez que cette situation se produira si le nom d'utilisateur et
le mot de passe sont incorrects.
Et donc ce n'est pas une erreur, au sens de l'erreur, mais le fait que l'authentification n'a
pas pu trouver l'utilisateur ou le mot de passe de l'utilisateur est incorrect.
Donc, cette information sera encodée dans l'entrée qui entre, et de sorte
que je reviendrai comme une erreur du côté client.
Sinon, la partie est
gérée comme req.login.
Donc, si cela réussit,
passeport.authenticate ajoutera cette méthode appelée req.login à l'utilisateur.
Donc, à ce stade, nous allons juste passer dans l'objet utilisateur que nous avons obtenu.
Donc, ici, si nous avons atteint ce point,
cela signifie que l'objet utilisateur n'est pas nul et qu'
aucune erreur n'est survenue, donc cela signifie que
l'utilisateur peut être connecté et donc nous allons dire erreur.
Donc, il va essayer de se connecter à l'utilisateur.
Donc, nous dirons si err.
Et ensuite, nous transmettrons le même type d'erreur que nous avons fait ici.
Donc, dans ce cas, si l'erreur.
En cas d'erreur, nous transmettrons le code d'état 401 et
nous dirons que le succès est faux et que le statut est Connexion infructueuse.
Et puis les informations d'erreur que
nous allons passer cela car au lieu d'
informations que nous allons passer dans n'a pas pu se connecter à l'utilisateur.
C' est donc le message qui va revenir ici, si l'erreur se produit.
Sinon, nous serions en bas ici.
Et donc à ce stade, nous serions en mesure de générer le jeton.
Donc, si nous avons atteint ce point, cela signifie que l'utilisateur s'est
connecté avec succès et donc nous pouvons maintenant générer le jeton.
Donc, nous allons générer le jeton basé sur l'ID utilisateur
, puis nous allons retourner ce jeton à l'utilisateur.
Donc, ici, nous allons dire var jeton.
Et puis nous pouvons dire res.statusCode = 200, puis res.json (succès) est vrai,
ce qui signifie que l'utilisateur s'est connecté avec succès.
Et donc le statut serait Connexion réussie,
puis la troisième partie au lieu de l'erreur, je transmettrai le jeton à l'utilisateur.
Donc, nous allons dire jeton, jeton,
ce jeton que nous venons d'obtenir plus tôt, de sorte que jeton sera passé en
tant que propriété token du message de lumière rip.
Donc ici, notez que cet axe est défini sur true.
Donc, ce qui signifie que l'utilisateur s'est connecté avec succès.
Et donc l'utilisateur peut aller de l'avant à ce stade.
Et cela doit être fait dans le req.Login ici.
Donc, à ce stade, nous allons fermer le req.login.
Donc, notez que c'est à l'intérieur de ce req.Login ici.
Donc, là-dedans, nous allons passer ces trois en arrière.
Laissez-moi juste mettre trois lignes en retrait.
Et c'est ainsi que nous gérerions la connexion des utilisateurs.
Donc encore une fois, en examinant ce code une fois de plus.
Donc, nous allons faire la publication
du routeur, mais au lieu de faire l'authentification du passeport juste là, nous dirons req, res,
ensuite à l'intérieur ici, nous allons faire un passeport.authenticate pour le local.
Et cette authentification repassera, donc nous pouvons fournir une fonction de rappel à cela.
Et cette fonction de rappel retournera soit l'erreur, l'utilisateur, soit
les informations ici.
Et donc, si cela fait une erreur, nous allons juste permettre au gestionnaire d'erreurs express de
prendre soin de cela.
Si l'utilisateur est null, cela signifie que l'ouverture de session de l'utilisateur a échoué,
et la raison de cela sera dans l'info afin que cela revienne comme
l'erreur info dans le message de plan ici.
Si nous arrivons à ce point, l'utilisateur est vérifié avec succès.
Donc, nous allons nous connecter à l'utilisateur.
Donc, passeport.authenticate ajoutera dans cette méthode appelée Login
au message de demande, de sorte que nous pouvons appeler la connexion avec l'utilisateur et
si cela renvoie une erreur, alors nous retournerons l'erreur ici correctement.
Sinon, nous aurions atteint le point où l'utilisateur est
authentifié avec succès afin qu'il puisse générer le jeton web JSON ici et renvoyer le
jeton Web JSON à l'utilisateur pour confirmer que l'utilisateur est correctement connecté.
Voilà donc l'ensemble des étapes que nous allons utiliser ici.
Maintenant, la raison pour laquelle je fais une façon plus élaborée de le gérer est que je veux
distinguer entre la situation où une véritable erreur se produit pendant
le processus d'application, par opposition à la situation où le nom d'utilisateur est invalide,
ou le mot de passe est invalide.
Donc ces deux cas seront traités par cette situation où l'information
nous transportera l'information.
Donc, ce n'est pas une erreur perse mais c'est une situation où
l'utilisateur n'est pas un utilisateur valide ou le mot de passe de l'utilisateur n'est pas valide.
C' est ainsi qu'ils vont gérer le processus de connexion de l'utilisateur.
En outre, je vais ajouter une autre méthode ici appelée,
CheckJWToken.
Il est tout à fait possible que pendant que le client s'est connecté et a
obtenu le jeton Web JSON, quelque temps plus tard, le jeton Web JSON peut expirer.
Et donc si l'utilisateur essaie d'accéder du côté client avec un jeton expiré
au serveur, le serveur ne sera pas en mesure d'authentifier l'utilisateur.
Donc, à intervalles périodiques, nous pouvons souhaiter vérifier de façon croisée pour nous assurer que le
jeton web JSON est toujours valide.
Donc, c'est la raison pour laquelle j'inclus un autre point de terminaison appelé
CheckJWTToken, donc si vous faites un get to the checkJWTToken.
En incluant le jeton dans l'en-tête d'autorisation
, cet appel renvoie un vrai ou un faux pour vous indiquer
si le jeton Web JSON est toujours valide ou non.
Si ce n'est pas valide, le côté client peut initier une autre connexion pour
l'utilisateur pour obtenir un nouveau jeton web JSON, si nécessaire.
Donc, pour ce faire, nous dirons cors, corsWithOptions et,
req, res, ici, comme prévu.
Et ici, nous allons dire,
passeport.authenticate ('jwt',
Et, {session : false}).
Et cela reviendrait err, utilisateur, info.
Rappelez-vous comment nous avons utilisé l'authentificateur Passport plus tôt.
Donc la session JWT tombe ici.
Donc, plus tôt ici, nous disons, passeport.authenticate local.
C' est donc pour l'authentification locale.
C' est donc pour l'authentification du jeton web JSON.
Donc, quand nous appelons cela, alors, puisque cela va vérifier le jeton web JSON,
donc je vais dire, si (err), retournez suivant (err).
Et puis laissez le gestionnaire d'erreurs Express prendre soin de cette situation.
Et puis nous dirons, si ( ! ),
Si l'utilisateur n'existe pas, alors de la même manière, sinon.
Donc, ce qui signifie que si l'objet utilisateur a été trouvé à partir du jeton Web JSON
puis chargé sur req.user, cela signifie que l'utilisateur est un utilisateur valide.
Et donc peut être autorisé à aller de l'avant.
Sinon, nous allons dire que l'utilisateur n'existe pas.
Nous devons donc déduire que le jeton web JSON a expiré.
Donc, à ce stade, nous allons envoyer une res avec le code d'état de,
401, donc non autorisé.
setHeader (, 'Content-Type',
'application/json').
Et puis nous retournerons res,
.json, nous dirons, {status :,
'JWT invalide ! '.
Et puis nous allons retourner un drapeau appelé succès : false.
Et puis, Nous allons retourner les informations que nous
obtenons si l'utilisateur n'est pas authentifié comme l'erreur à ce stade.
Sinon, cela signifie que nous atteignons ce point lorsque l'utilisateur est un utilisateur valide.
Donc, dans ce cas, laissez-moi juste copier ce code ici,
nous allons envoyer un code d'état de 200,
puis le res.json enverra JWT,
valide ! , et le succès sera vrai.
Et la troisième partie, nous enverrons les informations de l'utilisateur.
Ainsi, lorsque ce point de terminaison est appelé
avec la méthode get, cela vérifiera si le jeton est valide ou non.
Si le jeton est valide, vous recevrez cette réponse.
Et à partir de l'indicateur de succès dans la réponse,
vous pouvez vérifier si le jeton Web JSON est valide ou non.
Et cela est utile du côté client.
Maintenant, ce passeport ici, passeport.authenticate ici,
devra être fourni avec req et res comme les deux paramètres ici.
C' est ainsi que nous appelons ce passeport.authenticate.
Notez que chaque fois que vous appelez passeport.authenticate et que vous
attendez cette fonction de rappel ici, vous devez ajouter ce point, req
, .res, à ce passeport.authenticate, puis revenir ici.
Donc, avec cela, nous avons tout mis à jour sur le côté serveur.
Donc, sauvegardons tous les changements sur le côté serveur.
Maintenant, notre serveur est prêt à
traiter les demandes entrantes de notre client Angular.
Avec cela, nous terminons cet exercice.
Dans cet exercice, nous avons maintenant préparé notre serveur Express pour
traiter les demandes entrantes de notre client Angular.
Dans le prochain exercice, nous allons examiner le client Angular plus en détail pour
comprendre comment il communique avec ce serveur supplémentaire.
C' est le bon moment pour vous de faire un commit Git avec le message, en
intégrant le client et le serveur.
[ MUSIQUE]