1
00:00:00,000 --> 00:00:04,614
[MUSIC]

2
00:00:04,614 --> 00:00:09,792
Nous avions déjà développé un serveur API REST à part entière utilisant Express et

3
00:00:09,792 --> 00:00:12,026
MongoDB dans le cadre de ce cours.

4
00:00:12,026 --> 00:00:16,881
Pour que le serveur puisse communiquer de manière significative avec notre client,

5
00:00:16,881 --> 00:00:21,892
nous y apporterons quelques ajustements mineurs afin qu'il renvoie le bon type de données.

6
00:00:21,892 --> 00:00:26,063
Pour que notre implémentation client puisse fonctionner plus efficacement

7
00:00:26,063 --> 00:00:29,370
avec les données renvoyées par notre serveur.

8
00:00:29,370 --> 00:00:30,427
Donc, pour ce faire,

9
00:00:30,427 --> 00:00:35,724
nous allons travailler sur quelques ajustements à notre côté serveur dans cet exercice.

10
00:00:37,478 --> 00:00:43,220
Aller à notre serveur dans l'éditeur, avant de commencer à travailler sur le serveur,

11
00:00:43,220 --> 00:00:48,497
je suggère que vous téléchargez toutes les images que j'ai fournies

12
00:00:48,497 --> 00:00:53,260
sous forme de fichier zip dans les ressources d'exercice appelées images.zip.

13
00:00:53,260 --> 00:00:56,530
Décompressez le fichier, puis obtenez toutes les images à partir de là,

14
00:00:56,530 --> 00:01:03,440
puis copiez ces images dans le dossier des images publiques de notre serveur.

15
00:01:03,440 --> 00:01:08,980
Donc vous voyez qu'ici j'ai

16
00:01:08,980 --> 00:01:10,580
déjà copié toutes les images dans mon dossier d'images publiques ici.

17
00:01:10,580 --> 00:01:15,120
Parce que notre serveur est celui qui va servir toutes ces images pour

18
00:01:15,120 --> 00:01:17,460
notre application client.

19
00:01:17,460 --> 00:01:22,820
Ensuite, nous allons au cors et ajustons cette liste blanche, ici.

20
00:01:22,820 --> 00:01:27,919
Donc, pour notre application client Angular, si nous la démarrons

21
00:01:27,919 --> 00:01:33,571
avec la commande ng serve, elle s'exécute à localhost:4200.

22
00:01:33,571 --> 00:01:36,196
Donc, toutes les demandes venant de notre

23
00:01:36,196 --> 00:01:40,750
application Angular vers le serveur porteront cela comme leur origine là-bas.

24
00:01:40,750 --> 00:01:44,710
C' est pourquoi je vais ajouter cela dans ma liste blanche, afin

25
00:01:44,710 --> 00:01:50,310
que tous les problèmes cors soient résolus automatiquement.

26
00:01:50,310 --> 00:01:54,848
Donc, en allant dans ce fichier cors.js,

27
00:01:54,848 --> 00:01:59,698
dans ma liste blanche, ici, laissez-moi ajouter dans

28
00:01:59,698 --> 00:02:08,371
le http://localhost :, 4200.

29
00:02:08,371 --> 00:02:12,503
Et c'est l'origine à partir de laquelle tout mon client Angular sera à

30
00:02:12,503 --> 00:02:16,690
l'origine de la requête qui vient à ce serveur.

31
00:02:16,690 --> 00:02:22,020
Donc, mes cors ne causeront pas de problèmes pour mai client Angular.

32
00:02:22,020 --> 00:02:27,760
Ensuite, nous devons mettre à jour quelques-unes des routes pour gérer

33
00:02:27,760 --> 00:02:32,760
les paramètres de requête, ainsi que quelques autres ajustements mineurs.

34
00:02:32,760 --> 00:02:35,905
Laissez-moi commencer par les fichiers promoRouter.js.

35
00:02:35,905 --> 00:02:39,760
C' est donc simple de se mettre à jour.

36
00:02:39,760 --> 00:02:44,790
Donc, aller au fichier promoRouter.js, dans le fichier Promorouter, pour

37
00:02:44,790 --> 00:02:47,960
la demande get que nous obtenons ici,

38
00:02:47,960 --> 00:02:52,400
au lieu de faire des promotions.Find avec un JavaScript vide,

39
00:02:52,400 --> 00:02:57,256
ici je fournirais le req.query comme

40
00:02:57,256 --> 00:03:02,470
paramètre à cette promotions.Find ici.

41
00:03:02,470 --> 00:03:07,650
Même chose avec le LeaderRouter aussi, alors laissez-moi aller au fichier leaderRouter.js.

42
00:03:07,650 --> 00:03:09,786
Et dans le LeaderRouter aussi,

43
00:03:09,786 --> 00:03:14,642
ici où vous trouvez leaders.Find avec l'objet JavaScript vide.

44
00:03:14,642 --> 00:03:18,423
Au lieu de cela, remplacez-le par ce req.query, de sorte

45
00:03:18,423 --> 00:03:21,852
que les paramètres de requête soient transmis.

46
00:03:21,852 --> 00:03:26,430
Donc, c'est là que nous allons passer dans la colonne vedette

47
00:03:26,430 --> 00:03:29,487
à travers comme paramètre de requête.

48
00:03:29,487 --> 00:03:34,678
Maintenant, après avoir ajusté ces deux, nous allons maintenant travailler sur l'itinéraire plat,

49
00:03:34,678 --> 00:03:41,090
donc aller au fichier dishRouter.js, même dans le Dish.Router, la même mise à jour ici.

50
00:03:41,090 --> 00:03:48,920
Donc, allez à ce plats.Find dans la méthode get ici, changez cela en req.query.

51
00:03:48,920 --> 00:03:52,987
Donc, avec cela, ma mise à jour Dish.Router a été terminée.

52
00:03:52,987 --> 00:03:57,664
Donc, nous avons maintenant mis à jour le PromorOuter, le ReaderRouter, et

53
00:03:57,664 --> 00:04:02,784
le Dish.Router, puis nous allons passer à mettre à jour ce FavoriTerOuter.

54
00:04:02,784 --> 00:04:07,519
Maintenant, vous auriez implémenté le routeur favori dans le cadre de votre

55
00:04:07,519 --> 00:04:09,500
quatrième affectation.

56
00:04:09,500 --> 00:04:12,306
Maintenant, dans le FavoriTerouter, vous verrez que pour

57
00:04:12,306 --> 00:04:16,618
le FavoriTerouter je ne vous montre pas la partie restante parce que

58
00:04:16,618 --> 00:04:19,437
vous auriez dû faire dans le cadre de votre mission.

59
00:04:19,437 --> 00:04:22,925
Permettez-moi d'abord d'attirer votre attention sur la méthode get pour

60
00:04:22,925 --> 00:04:26,422
le favoriTerouter.route (« /:dishid').

61
00:04:26,422 --> 00:04:31,161
Maintenant, je vais utiliser cette méthode get

62
00:04:31,161 --> 00:04:35,653
pour vérifier simplement que le plat spécifique avec

63
00:04:35,653 --> 00:04:40,292
un DishiD est déjà un favori pour l'utilisateur.

64
00:04:40,292 --> 00:04:44,413
Donc, au lieu de simplement dire l'opération GET non prise en charge,

65
00:04:44,413 --> 00:04:48,879
je vais juste tirer parti de la présence de cette opération get.

66
00:04:48,879 --> 00:04:52,574
Et puis nous dirons,

67
00:04:52,574 --> 00:04:56,684
favorités.Findone.

68
00:04:56,684 --> 00:04:59,843
Et je dirai,

69
00:04:59,843 --> 00:05:04,952
utilisateur : req.user.id.

70
00:05:04,952 --> 00:05:10,194
Donc, nous allons trouver les favoris pour cet utilisateur particulier.

71
00:05:10,194 --> 00:05:20,166
Et puis nous dirons, .puis, favoris.

72
00:05:26,483 --> 00:05:32,913
Et, attraper ((err),

73
00:05:35,757 --> 00:05:40,160
suivant (err)).

74
00:05:40,160 --> 00:05:45,638
Et puis de même ici, nous allons ajouter l'erreur ici.

75
00:05:48,689 --> 00:05:50,239
Suivant (err)), ici.

76
00:05:50,239 --> 00:05:55,689
Donc, à l'intérieur de ce .puis, quand nous obtenons les favoris,

77
00:05:55,689 --> 00:06:00,290
alors nous allons vérifier, si ( ! favoris).

78
00:06:00,290 --> 00:06:04,500
Donc, s'il n'y a pas de favoris pour cet utilisateur,

79
00:06:04,500 --> 00:06:08,770
alors évidemment le plat que nous vérifions n'existe pas.

80
00:06:08,770 --> 00:06:18,604
Donc nous reviendrons, Res.StatusCode, 200.

81
00:06:22,232 --> 00:06:29,488
setHeader ('Content-Type

82
00:06:29,488 --> 00:06:34,436
'' 'application/json').

83
00:06:34,436 --> 00:06:36,237
Et puis nous reviendrons,

84
00:06:42,997 --> 00:06:51,490
en disant, « existe » : faux.

85
00:06:51,490 --> 00:06:56,891
Donc, ce que nous spécifions ici est que si le get est fait

86
00:06:56,891 --> 00:07:02,771
à ce point de terminaison avec un disHID, ce drapeau existe ici

87
00:07:02,771 --> 00:07:07,826
sera défini sur true si ce plat fait partie de mes favoris.

88
00:07:07,826 --> 00:07:13,008
Si ce plat ne fait pas partie de mes favoris, je vais définir le drapeau existe sur false.

89
00:07:13,008 --> 00:07:16,687
Donc, ici, vous voyez que puisque je n'ai pas de favoris,

90
00:07:16,687 --> 00:07:20,008
il existe donc devrait être automatiquement faux à ce stade.

91
00:07:20,008 --> 00:07:26,780
Donc, nous allons dire « existe » : false, puis nous allons retourner les favoris, ici.

92
00:07:28,950 --> 00:07:31,237
Eh bien, évidemment dans ce cas,

93
00:07:31,237 --> 00:07:35,225
les favoris seraient nuls à ce stade, sinon.

94
00:07:39,097 --> 00:07:42,779
Donc, ce qui signifie que les favoris n'est pas nul, donc nous allons dire si,

95
00:07:45,218 --> 00:07:52,688
(favorites.dishs.indexOf),

96
00:07:52,688 --> 00:07:58,011
donc nous allons chercher req.params.

97
00:08:00,046 --> 00:08:02,620
DisHid, donc on va fouiller ça.

98
00:08:02,620 --> 00:08:09,632
.Dish.Array, pour voir si le plat existe là-dedans.

99
00:08:09,632 --> 00:08:15,410
Et s'il n'existe pas, évidemment cela retournera un index négatif ici.

100
00:08:15,410 --> 00:08:20,200
Donc, dans ce cas aussi, je reviendrai exactement le même que ici.

101
00:08:20,200 --> 00:08:22,291
Donc, si elle renvoie un index négatif,

102
00:08:22,291 --> 00:08:26,990
cela signifie que même si cet utilisateur particulier a un favori du centre.

103
00:08:26,990 --> 00:08:31,464
Ce plat spécifique n'existe pas dans la liste de

104
00:08:31,464 --> 00:08:36,987
son favori, donc c'est pourquoi il va revenir exister faux ici.

105
00:08:36,987 --> 00:08:45,119
Maintenant, sinon cela signifie que le plat existe dans la liste des favoris.

106
00:08:45,119 --> 00:08:51,352
Donc, dans ce cas, je vais retourner le code d'état 200 existe est vrai.

107
00:08:51,352 --> 00:08:57,144
Ainsi, lorsque l'utilisateur effectue une opération get sur

108
00:08:57,144 --> 00:09:02,408
ce point final avec le /favorite/dishid.

109
00:09:02,408 --> 00:09:07,265
Où le disHID est fourni en tant que paramètre ici.

110
00:09:07,265 --> 00:09:09,821
Comme le paramètre d'enregistrements ici,

111
00:09:09,821 --> 00:09:15,226
nous allons vérifier si ce plat existe dans les favoris.

112
00:09:15,226 --> 00:09:19,983
Si aucun des favoris n'existe pour cet utilisateur, nous retournerons un false existant.

113
00:09:19,983 --> 00:09:22,138
De même, si les favoris existent,

114
00:09:22,138 --> 00:09:27,000
mais que ce plat particulier n'existe pas dans les favoris, alors il retournera un faux.

115
00:09:27,000 --> 00:09:28,705
Sinon, il retournera un vrai.

116
00:09:28,705 --> 00:09:33,890
Donc, ce drapeau existe peut être utilisé par mon client

117
00:09:33,890 --> 00:09:41,997
pour vérifier si ce plat fait partie de la liste des plats préférés pour cet utilisateur ou non.

118
00:09:41,997 --> 00:09:48,624
Enfin, nous allons mettre à jour le fichier users.js.

119
00:09:48,624 --> 00:09:53,284
Maintenant, dans le fichier users.js, nous devons ajouter

120
00:09:53,284 --> 00:09:58,204
un autre champ router.options ici parce que

121
00:09:58,204 --> 00:10:03,769
parfois une demande de poste comme vous l'avez vu avec la connexion,

122
00:10:03,769 --> 00:10:10,760
nous allons d'abord envoyer les options pour vérifier, en particulier avec les voitures,

123
00:10:10,760 --> 00:10:16,140
si la demande de poste sera autorisée.

124
00:10:16,140 --> 00:10:23,156
C' est pourquoi ils vont vérifier les voitures, les voitures avec des options ici et là.

125
00:10:26,156 --> 00:10:27,915
Nous allons simplement retourner

126
00:10:34,203 --> 00:10:39,938
un message d'état de 200 en réponse à cela.

127
00:10:39,938 --> 00:10:44,624
Donc, pour tout point de terminaison sous les utilisateurs si nous avons reçu

128
00:10:44,624 --> 00:10:50,183
les options retournera simplement un état 200 ici.

129
00:10:50,183 --> 00:10:57,417
Maintenant, la fonction de connexion que nous avions implémentée plus tôt.

130
00:10:57,417 --> 00:11:02,782
Nous avons simplement fait passeport.authenticate ('local') ici et

131
00:11:02,782 --> 00:11:06,600
ensuite nous vérifions les valeurs restantes ici.

132
00:11:06,600 --> 00:11:11,006
Maintenant, ce passeport.authenticate ('local'), si l'utilisateur n'est pas

133
00:11:11,006 --> 00:11:15,221
authentifié, il renvoie simplement un non autorisé dans le message de réponse.

134
00:11:15,221 --> 00:11:18,212
Maintenant, cela peut ne pas être très significatif pour

135
00:11:18,212 --> 00:11:21,868
le côté client d'afficher ces informations.

136
00:11:21,868 --> 00:11:27,245
C' est pourquoi nous allons améliorer cette méthode de post-connexion du routeur afin

137
00:11:27,245 --> 00:11:35,158
que l'authentification renvoie des informations plus significatives à cette partie.

138
00:11:35,158 --> 00:11:39,831
Donc, pour ce faire, nous ne allons pas faire l'

139
00:11:39,831 --> 00:11:43,120
authentification du passeport à l'intérieur ici.

140
00:11:43,120 --> 00:11:47,180
Au lieu de cela, nous allons prendre, alors laissez-moi supprimer cela de là,

141
00:11:47,180 --> 00:11:52,410
et puis vous verrez comment je vais mettre à jour le post du routeur ici.

142
00:11:52,410 --> 00:11:56,520
Donc, nous verrons CarsWithOptions.

143
00:11:56,520 --> 00:12:03,806
Et puis nous inclurons le req, res et le suivant ici.

144
00:12:03,806 --> 00:12:08,216
Et à l'intérieur de la req, res, et

145
00:12:08,216 --> 00:12:14,227
ensuite ici, passeport.authenticate,

146
00:12:17,271 --> 00:12:22,035
Nous appellerons ceci avec 'local'.

147
00:12:22,035 --> 00:12:27,041
Maintenant, quand nous appelons ceci avec local, si une

148
00:12:27,041 --> 00:12:34,607
erreur d'authentification se produit, passeport.authenticate peut être fait pour retourner la valeur d'erreur,

149
00:12:34,607 --> 00:12:39,519
et aussi il retournera l'utilisateur s'il n'y a pas d'erreur.

150
00:12:39,519 --> 00:12:42,283
Et il pourrait paramètre appelé info,

151
00:12:42,283 --> 00:12:47,643
qui transportera des informations supplémentaires qui pourraient être transmises à l'utilisateur.

152
00:12:47,643 --> 00:12:51,714
Cette erreur sera renvoyée lorsqu'il y a une erreur authentique qui se produit dans

153
00:12:51,714 --> 00:12:53,590
le possible de s'authentifier.

154
00:12:53,590 --> 00:12:58,995
Mais si les informations de l'utilisateur sont envoyées à passeport.authenticate mais que

155
00:12:58,995 --> 00:13:03,945
l'utilisateur n'existe pas, cela n'est pas compté comme une erreur.

156
00:13:03,945 --> 00:13:07,828
Au lieu de cela, il sera compté comme l'utilisateur n'existe pas.

157
00:13:07,828 --> 00:13:12,825
Et cette information est transmise dans l'objet info qui entre.

158
00:13:12,825 --> 00:13:16,793
Ainsi, l'erreur sera renvoyée lorsqu'il y a une erreur authentique qui se produit pendant

159
00:13:16,793 --> 00:13:18,405
le processus d'authentification.

160
00:13:18,405 --> 00:13:23,995
Mais les informations, elles contiendront des informations si l'utilisateur n'existe pas et donc

161
00:13:23,995 --> 00:13:30,102
le passeport.authenticate transmet un message indiquant que l'utilisateur n'

162
00:13:30,102 --> 00:13:35,780
existe pas ou que le nom d'utilisateur est incorrect ou que le mot de passe est incorrect.

163
00:13:35,780 --> 00:13:40,415
Et ainsi de suite, afin que l'information soit transmise, dans le message d'information.

164
00:13:40,415 --> 00:13:44,569
Maintenant, nous verrons comment cela nous est utile quand nous regardons le côté client un

165
00:13:44,569 --> 00:13:45,990
peu plus tard.

166
00:13:45,990 --> 00:13:48,070
Donc, dans cette situation,

167
00:13:49,530 --> 00:13:55,110
nous allons gérer cela comme suit.

168
00:13:55,110 --> 00:14:00,510
Et pas seulement cela, quand nous appelons ce passeport authentifier,

169
00:14:00,510 --> 00:14:04,976
nous devons également passer dans un (req, res,

170
00:14:04,976 --> 00:14:08,550
suivant) que cette bande de trois paramètres.

171
00:14:08,550 --> 00:14:10,320
C' est donc la structure.

172
00:14:10,320 --> 00:14:13,558
Lorsque vous devez appeler passeport authentifier,

173
00:14:13,558 --> 00:14:18,798
attendez-vous à ce qu'il vous transmette des informations comme celle-ci comme une méthode de rappel ici.

174
00:14:18,798 --> 00:14:24,072
Donc, vous devez également fournir ce req, res prochain juste là aussi.

175
00:14:24,072 --> 00:14:25,720
Maintenant, si cela se produit.

176
00:14:25,720 --> 00:14:30,206
Donc, nous allons dire si (err).

177
00:14:30,206 --> 00:14:34,163
Donc, s'il y a une erreur qui se produit,

178
00:14:34,163 --> 00:14:39,781
nous dirons retourner suivant (err), puis laisser le

179
00:14:39,781 --> 00:14:45,028
gestionnaire d'erreurs de notre routeur express s'occuper de cela.

180
00:14:45,028 --> 00:14:48,365
Maintenant, nous allons considérer d'autres situations.

181
00:14:48,365 --> 00:14:53,484
Si ( ! ), donc si nous avons atteint ce point, cela signifie que ce n'est

182
00:14:53,484 --> 00:14:59,232
pas une erreur qui s'est produite mais peut-être que l'utilisateur n'a pas pu être trouvé.

183
00:14:59,232 --> 00:15:04,860
Si l'utilisateur n'est pas trouvé, l'utilisateur ici sera défini sur null dans ce cas.

184
00:15:04,860 --> 00:15:10,088
Donc, dans cette situation, si l'utilisateur n'existe pas,

185
00:15:10,088 --> 00:15:17,068
alors nous devons être en mesure de transmettre des informations au côté serveur.

186
00:15:17,068 --> 00:15:22,895
Donc, ce que nous allons faire est que nous allons passer cette information dans ce format,

187
00:15:22,895 --> 00:15:26,576
donc je vais couper ceci d'ici,

188
00:15:26,576 --> 00:15:30,491
puis coller ici et ensuite nous allons le modifier.

189
00:15:30,491 --> 00:15:36,748
Si l'utilisateur est nul, alors nous enverrons un StatusCode

190
00:15:36,748 --> 00:15:41,509
de 401, ce qui signifie non autorisé,

191
00:15:41,509 --> 00:15:47,640
puis nous enverrons l'information succès, false.

192
00:15:47,640 --> 00:15:54,340
Et puis nous ne transmettrons pas le jeton, nous remettrons le message d'état.

193
00:15:54,340 --> 00:16:02,501
Donc, ici, nous allons dire connexion, échec.

194
00:16:02,501 --> 00:16:07,870
Et puis la troisième information transmettra cette information, cet

195
00:16:07,870 --> 00:16:13,238
objet que nous avons reçu ici comme la troisième partie de

196
00:16:13,238 --> 00:16:19,231
ce message de réponse que nous renvoyons de notre serveur ici.

197
00:16:19,231 --> 00:16:22,496
Donc, l'indicateur de succès sera réinitialisé à false.

198
00:16:22,496 --> 00:16:27,145
Le statut sera défini Connexion infructueuse et les informations d'erreur

199
00:16:27,145 --> 00:16:30,235
qui sont transmises dans l'information seront transmises.

200
00:16:30,235 --> 00:16:34,788
Maintenant, notez que cette situation se produira si le nom d'utilisateur et

201
00:16:34,788 --> 00:16:36,789
le mot de passe sont incorrects.

202
00:16:36,789 --> 00:16:42,516
Et donc ce n'est pas une erreur, au sens de l'erreur, mais le fait que l'authentification n'a

203
00:16:42,516 --> 00:16:47,505
pas pu trouver l'utilisateur ou le mot de passe de l'utilisateur est incorrect.

204
00:16:47,505 --> 00:16:51,545
Donc, cette information sera encodée dans l'entrée qui entre, et de sorte

205
00:16:51,545 --> 00:16:58,227
que je reviendrai comme une erreur du côté client.

206
00:16:58,227 --> 00:17:02,633
Sinon, la partie est

207
00:17:02,633 --> 00:17:08,810
gérée comme req.login.

208
00:17:08,810 --> 00:17:10,700
Donc, si cela réussit,

209
00:17:10,700 --> 00:17:16,200
passeport.authenticate ajoutera cette méthode appelée req.login à l'utilisateur.

210
00:17:16,200 --> 00:17:21,400
Donc, à ce stade, nous allons juste passer dans l'objet utilisateur que nous avons obtenu.

211
00:17:21,400 --> 00:17:26,398
Donc, ici, si nous avons atteint ce point,

212
00:17:26,398 --> 00:17:32,572
cela signifie que l'objet utilisateur n'est pas nul et qu'

213
00:17:32,572 --> 00:17:37,717
aucune erreur n'est survenue, donc cela signifie que

214
00:17:37,717 --> 00:17:43,304
l'utilisateur peut être connecté et donc nous allons dire erreur.

215
00:17:43,304 --> 00:17:44,995
Donc, il va essayer de se connecter à l'utilisateur.

216
00:17:44,995 --> 00:17:47,231
Donc, nous dirons si err.

217
00:17:51,210 --> 00:17:58,260
Et ensuite, nous transmettrons le même type d'erreur que nous avons fait ici.

218
00:17:59,450 --> 00:18:02,317
Donc, dans ce cas, si l'erreur.

219
00:18:06,077 --> 00:18:11,757
En cas d'erreur, nous transmettrons le code d'état 401 et

220
00:18:11,757 --> 00:18:18,970
nous dirons que le succès est faux et que le statut est Connexion infructueuse.

221
00:18:18,970 --> 00:18:24,359
Et puis les informations d'erreur que

222
00:18:24,359 --> 00:18:29,539
nous allons passer cela car au lieu d'

223
00:18:29,539 --> 00:18:36,810
informations que nous allons passer dans n'a pas pu se connecter à l'utilisateur.

224
00:18:36,810 --> 00:18:42,580
C' est donc le message qui va revenir ici, si l'erreur se produit.

225
00:18:42,580 --> 00:18:46,195
Sinon, nous serions en bas ici.

226
00:18:46,195 --> 00:18:53,157
Et donc à ce stade, nous serions en mesure de générer le jeton.

227
00:18:53,157 --> 00:18:57,594
Donc, si nous avons atteint ce point, cela signifie que l'utilisateur s'est

228
00:18:57,594 --> 00:19:01,892
connecté avec succès et donc nous pouvons maintenant générer le jeton.

229
00:19:01,892 --> 00:19:07,009
Donc, nous allons générer le jeton basé sur l'ID utilisateur

230
00:19:07,009 --> 00:19:11,794
, puis nous allons retourner ce jeton à l'utilisateur.

231
00:19:11,794 --> 00:19:15,462
Donc, ici, nous allons dire var jeton.

232
00:19:15,462 --> 00:19:22,789
Et puis nous pouvons dire res.statusCode = 200, puis res.json (succès) est vrai,

233
00:19:22,789 --> 00:19:26,999
ce qui signifie que l'utilisateur s'est connecté avec succès.

234
00:19:26,999 --> 00:19:31,842
Et donc le statut serait Connexion réussie,

235
00:19:31,842 --> 00:19:39,900
puis la troisième partie au lieu de l'erreur, je transmettrai le jeton à l'utilisateur.

236
00:19:39,900 --> 00:19:45,590
Donc, nous allons dire jeton, jeton,

237
00:19:45,590 --> 00:19:50,390
ce jeton que nous venons d'obtenir plus tôt, de sorte que jeton sera passé en

238
00:19:50,390 --> 00:19:54,600
tant que propriété token du message de lumière rip.

239
00:19:54,600 --> 00:19:57,910
Donc ici, notez que cet axe est défini sur true.

240
00:19:57,910 --> 00:20:01,890
Donc, ce qui signifie que l'utilisateur s'est connecté avec succès.

241
00:20:01,890 --> 00:20:05,660
Et donc l'utilisateur peut aller de l'avant à ce stade.

242
00:20:05,660 --> 00:20:13,667
Et cela doit être fait dans le req.Login ici.

243
00:20:13,667 --> 00:20:20,640
Donc, à ce stade, nous allons fermer le req.login.

244
00:20:20,640 --> 00:20:27,570
Donc, notez que c'est à l'intérieur de ce req.Login ici.

245
00:20:27,570 --> 00:20:30,830
Donc, là-dedans, nous allons passer ces trois en arrière.

246
00:20:30,830 --> 00:20:33,800
Laissez-moi juste mettre trois lignes en retrait.

247
00:20:35,830 --> 00:20:42,490
Et c'est ainsi que nous gérerions la connexion des utilisateurs.

248
00:20:42,490 --> 00:20:45,850
Donc encore une fois, en examinant ce code une fois de plus.

249
00:20:45,850 --> 00:20:47,740
Donc, nous allons faire la publication

250
00:20:47,740 --> 00:20:52,490
du routeur, mais au lieu de faire l'authentification du passeport juste là, nous dirons req, res,

251
00:20:52,490 --> 00:20:57,970
ensuite à l'intérieur ici, nous allons faire un passeport.authenticate pour le local.

252
00:20:57,970 --> 00:21:02,930
Et cette authentification repassera, donc nous pouvons fournir une fonction de rappel à cela.

253
00:21:02,930 --> 00:21:06,810
Et cette fonction de rappel retournera soit l'erreur, l'utilisateur, soit

254
00:21:06,810 --> 00:21:08,370
les informations ici.

255
00:21:08,370 --> 00:21:13,220
Et donc, si cela fait une erreur, nous allons juste permettre au gestionnaire d'erreurs express de

256
00:21:13,220 --> 00:21:14,560
prendre soin de cela.

257
00:21:14,560 --> 00:21:20,580
Si l'utilisateur est null, cela signifie que l'ouverture de session de l'utilisateur a échoué,

258
00:21:20,580 --> 00:21:25,090
et la raison de cela sera dans l'info afin que cela revienne comme

259
00:21:25,090 --> 00:21:30,660
l'erreur info dans le message de plan ici.

260
00:21:30,660 --> 00:21:37,190
Si nous arrivons à ce point, l'utilisateur est vérifié avec succès.

261
00:21:37,190 --> 00:21:38,898
Donc, nous allons nous connecter à l'utilisateur.

262
00:21:38,898 --> 00:21:43,850
Donc, passeport.authenticate ajoutera dans cette méthode appelée Login

263
00:21:43,850 --> 00:21:51,090
au message de demande, de sorte que nous pouvons appeler la connexion avec l'utilisateur et

264
00:21:51,090 --> 00:21:56,760
si cela renvoie une erreur, alors nous retournerons l'erreur ici correctement.

265
00:21:56,760 --> 00:22:01,400
Sinon, nous aurions atteint le point où l'utilisateur est

266
00:22:01,400 --> 00:22:06,560
authentifié avec succès afin qu'il puisse générer le jeton web JSON ici et renvoyer le

267
00:22:06,560 --> 00:22:12,020
jeton Web JSON à l'utilisateur pour confirmer que l'utilisateur est correctement connecté.

268
00:22:12,020 --> 00:22:15,190
Voilà donc l'ensemble des étapes que nous allons utiliser ici.

269
00:22:15,190 --> 00:22:19,910
Maintenant, la raison pour laquelle je fais une façon plus élaborée de le gérer est que je veux

270
00:22:19,910 --> 00:22:24,760
distinguer entre la situation où une véritable erreur se produit pendant

271
00:22:24,760 --> 00:22:30,700
le processus d'application, par opposition à la situation où le nom d'utilisateur est invalide,

272
00:22:30,700 --> 00:22:32,830
ou le mot de passe est invalide.

273
00:22:32,830 --> 00:22:37,713
Donc ces deux cas seront traités par cette situation où l'information

274
00:22:37,713 --> 00:22:40,129
nous transportera l'information.

275
00:22:40,129 --> 00:22:44,551
Donc, ce n'est pas une erreur perse mais c'est une situation où

276
00:22:44,551 --> 00:22:49,440
l'utilisateur n'est pas un utilisateur valide ou le mot de passe de l'utilisateur n'est pas valide.

277
00:22:49,440 --> 00:22:54,880
C' est ainsi qu'ils vont gérer le processus de connexion de l'utilisateur.

278
00:22:54,880 --> 00:22:59,666
En outre, je vais ajouter une autre méthode ici appelée,

279
00:23:05,730 --> 00:23:08,832
CheckJWToken.

280
00:23:08,832 --> 00:23:12,831
Il est tout à fait possible que pendant que le client s'est connecté et a

281
00:23:12,831 --> 00:23:18,229
obtenu le jeton Web JSON, quelque temps plus tard, le jeton Web JSON peut expirer.

282
00:23:18,229 --> 00:23:23,776
Et donc si l'utilisateur essaie d'accéder du côté client avec un jeton expiré

283
00:23:23,776 --> 00:23:29,159
au serveur, le serveur ne sera pas en mesure d'authentifier l'utilisateur.

284
00:23:29,159 --> 00:23:34,024
Donc, à intervalles périodiques, nous pouvons souhaiter vérifier de façon croisée pour nous assurer que le

285
00:23:34,024 --> 00:23:35,733
jeton web JSON est toujours valide.

286
00:23:35,733 --> 00:23:41,180
Donc, c'est la raison pour laquelle j'inclus un autre point de terminaison appelé

287
00:23:41,180 --> 00:23:46,131
CheckJWTToken, donc si vous faites un get to the checkJWTToken.

288
00:23:46,131 --> 00:23:50,927
En incluant le jeton dans l'en-tête d'autorisation

289
00:23:50,927 --> 00:23:55,926
, cet appel renvoie un vrai ou un faux pour vous indiquer

290
00:23:55,926 --> 00:24:00,125
si le jeton Web JSON est toujours valide ou non.

291
00:24:00,125 --> 00:24:04,430
Si ce n'est pas valide, le côté client peut initier une autre connexion pour

292
00:24:04,430 --> 00:24:09,710
l'utilisateur pour obtenir un nouveau jeton web JSON, si nécessaire.

293
00:24:09,710 --> 00:24:15,470
Donc, pour ce faire, nous dirons cors, corsWithOptions et,

294
00:24:19,500 --> 00:24:23,760
req, res, ici, comme prévu.

295
00:24:25,510 --> 00:24:28,029
Et ici, nous allons dire,

296
00:24:31,852 --> 00:24:40,983
passeport.authenticate ('jwt',

297
00:24:42,356 --> 00:24:49,886
Et, {session : false}).

298
00:24:54,050 --> 00:24:59,322
Et cela reviendrait err, utilisateur, info.

299
00:25:03,010 --> 00:25:07,005
Rappelez-vous comment nous avons utilisé l'authentificateur Passport plus tôt.

300
00:25:07,005 --> 00:25:11,050
Donc la session JWT tombe ici.

301
00:25:11,050 --> 00:25:14,759
Donc, plus tôt ici, nous disons, passeport.authenticate local.

302
00:25:14,759 --> 00:25:17,039
C' est donc pour l'authentification locale.

303
00:25:17,039 --> 00:25:21,038
C' est donc pour l'authentification du jeton web JSON.

304
00:25:21,038 --> 00:25:26,303
Donc, quand nous appelons cela, alors, puisque cela va vérifier le jeton web JSON,

305
00:25:26,303 --> 00:25:33,820
donc je vais dire, si (err), retournez suivant (err).

306
00:25:33,820 --> 00:25:38,540
Et puis laissez le gestionnaire d'erreurs Express prendre soin de cette situation.

307
00:25:38,540 --> 00:25:42,895
Et puis nous dirons, si ( ! ),

308
00:25:47,340 --> 00:25:53,395
Si l'utilisateur n'existe pas, alors de la même manière, sinon.

309
00:25:53,395 --> 00:25:58,850
Donc, ce qui signifie que si l'objet utilisateur a été trouvé à partir du jeton Web JSON

310
00:25:58,850 --> 00:26:04,764
puis chargé sur req.user, cela signifie que l'utilisateur est un utilisateur valide.

311
00:26:04,764 --> 00:26:06,990
Et donc peut être autorisé à aller de l'avant.

312
00:26:06,990 --> 00:26:13,770
Sinon, nous allons dire que l'utilisateur n'existe pas.

313
00:26:13,770 --> 00:26:18,480
Nous devons donc déduire que le jeton web JSON a expiré.

314
00:26:18,480 --> 00:26:24,495
Donc, à ce stade, nous allons envoyer une res avec le code d'état de,

315
00:26:29,070 --> 00:26:31,580
401, donc non autorisé.

316
00:26:33,847 --> 00:26:40,570
setHeader (, 'Content-Type',

317
00:26:42,865 --> 00:26:45,940
'application/json').

318
00:26:45,940 --> 00:26:52,243
Et puis nous retournerons res,

319
00:26:54,894 --> 00:27:00,970
.json, nous dirons, {status :,

320
00:27:04,165 --> 00:27:07,131
'JWT invalide ! '.

321
00:27:07,131 --> 00:27:15,242
Et puis nous allons retourner un drapeau appelé succès : false.

322
00:27:15,242 --> 00:27:20,624
Et puis, Nous allons retourner les informations que nous

323
00:27:20,624 --> 00:27:26,890
obtenons si l'utilisateur n'est pas authentifié comme l'erreur à ce stade.

324
00:27:30,450 --> 00:27:36,219
Sinon, cela signifie que nous atteignons ce point lorsque l'utilisateur est un utilisateur valide.

325
00:27:36,219 --> 00:27:40,921
Donc, dans ce cas, laissez-moi juste copier ce code ici,

326
00:27:40,921 --> 00:27:45,392
nous allons envoyer un code d'état de 200,

327
00:27:45,392 --> 00:27:48,727
puis le res.json enverra JWT,

328
00:27:51,140 --> 00:27:55,050
valide ! , et le succès sera vrai.

329
00:27:56,550 --> 00:28:03,290
Et la troisième partie, nous enverrons les informations de l'utilisateur.

330
00:28:03,290 --> 00:28:07,776
Ainsi, lorsque ce point de terminaison est appelé

331
00:28:07,776 --> 00:28:12,710
avec la méthode get, cela vérifiera si le jeton est valide ou non.

332
00:28:12,710 --> 00:28:15,580
Si le jeton est valide, vous recevrez cette réponse.

333
00:28:15,580 --> 00:28:17,311
Et à partir de l'indicateur de succès dans la réponse,

334
00:28:17,311 --> 00:28:20,050
vous pouvez vérifier si le jeton Web JSON est valide ou non.

335
00:28:20,050 --> 00:28:24,010
Et cela est utile du côté client.

336
00:28:24,010 --> 00:28:30,012
Maintenant, ce passeport ici, passeport.authenticate ici,

337
00:28:30,012 --> 00:28:37,720
devra être fourni avec req et res comme les deux paramètres ici.

338
00:28:37,720 --> 00:28:41,320
C' est ainsi que nous appelons ce passeport.authenticate.

339
00:28:41,320 --> 00:28:45,060
Notez que chaque fois que vous appelez passeport.authenticate et que vous

340
00:28:45,060 --> 00:28:49,917
attendez cette fonction de rappel ici, vous devez ajouter ce point, req

341
00:28:49,917 --> 00:28:53,973
, .res, à ce passeport.authenticate, puis revenir ici.

342
00:28:53,973 --> 00:28:57,915
Donc, avec cela, nous avons tout mis à jour sur le côté serveur.

343
00:28:57,915 --> 00:29:01,900
Donc, sauvegardons tous les changements sur le côté serveur.

344
00:29:01,900 --> 00:29:05,400
Maintenant, notre serveur est prêt à

345
00:29:05,400 --> 00:29:10,680
traiter les demandes entrantes de notre client Angular.

346
00:29:10,680 --> 00:29:13,120
Avec cela, nous terminons cet exercice.

347
00:29:13,120 --> 00:29:18,010
Dans cet exercice, nous avons maintenant préparé notre serveur Express pour

348
00:29:18,010 --> 00:29:22,930
traiter les demandes entrantes de notre client Angular.

349
00:29:22,930 --> 00:29:26,890
Dans le prochain exercice, nous allons examiner le client Angular plus en détail pour

350
00:29:26,890 --> 00:29:32,350
comprendre comment il communique avec ce serveur supplémentaire.

351
00:29:32,350 --> 00:29:37,881
C' est le bon moment pour vous de faire un commit Git avec le message, en

352
00:29:37,881 --> 00:29:40,932
intégrant le client et le serveur.

353
00:29:40,932 --> 00:29:44,825
[ MUSIQUE]