﻿1
00:00:01,140 --> 00:00:03,050
‫Jonas : Continuons maintenant à écrire

2
00:00:03,050 --> 00:00:04,773
‫notre fonction protect middleware.

3
00:00:06,420 --> 00:00:08,910
‫Ainsi, dans la dernière leçon, nous avons lu

4
00:00:08,910 --> 00:00:10,990
‫le jeton à partir de

5
00:00:10,990 --> 00:00:14,080
‫l'en-tête d'autorisation, puis vérifié si le jeton existe réellement.

6
00:00:14,080 --> 00:00:15,023
‫Alors juste ici.

7
00:00:15,880 --> 00:00:19,890
‫Et ensuite, nous avons l'étape de vérification pour le jeton.

8
00:00:19,890 --> 00:00:21,880
‫Et j'espère que vous vous souvenez

9
00:00:21,880 --> 00:00:24,520
‫qu'à cette étape, nous vérifions si quelqu'un a manipulé

10
00:00:24,520 --> 00:00:27,500
‫les données ou aussi si le token a déjà expiré.

11
00:00:27,500 --> 00:00:31,840
‫Nous avons donc déjà utilisé, à partir du package de jetons Web JSON, la

12
00:00:31,840 --> 00:00:33,180
‫fonction assign function,

13
00:00:33,180 --> 00:00:35,623
‫et maintenant nous allons utiliser la fonction verify.

14
00:00:36,820 --> 00:00:39,333
‫Alors comme avant, jwt. vérifier, puis là-dedans,

15
00:00:43,000 --> 00:00:46,630
‫comme vous pouvez l'imaginer, nous passons le jeton pour que l'algorithme

16
00:00:46,630 --> 00:00:49,160
‫puisse lire la charge utile, puis se

17
00:00:49,160 --> 00:00:52,133
‫rappeler que cette étape a également besoin du secret.

18
00:00:53,250 --> 00:00:56,870
‫Donc en gros, afin de créer la signature de test.

19
00:00:56,870 --> 00:01:00,743
‫Ce secret est donc un processus. env. JWT_SECRET.

20
00:01:03,470 --> 00:01:04,610
‫Vous vous en souvenez ?

21
00:01:04,610 --> 00:01:05,860
‫Maintenant, comme troisième

22
00:01:05,860 --> 00:01:09,003
‫argument, cette fonction nécessite en fait une fonction de rappel.

23
00:01:10,090 --> 00:01:12,180
‫Ce rappel sera donc

24
00:01:12,180 --> 00:01:14,850
‫exécuté dès que la vérification sera terminée.

25
00:01:14,850 --> 00:01:16,840
‫Vous voyez donc que cette

26
00:01:16,840 --> 00:01:19,564
‫vérification ici est en fait une fonction asynchrone.

27
00:01:19,564 --> 00:01:22,540
‫Il vérifiera donc un jeton, puis après cela, une

28
00:01:22,540 --> 00:01:23,620
‫fois terminé,

29
00:01:23,620 --> 00:01:27,040
‫il appellera la fonction de rappel que nous pouvons spécifier.

30
00:01:27,040 --> 00:01:29,910
‫Maintenant, nous avons travaillé avec des promesses tout le

31
00:01:29,910 --> 00:01:33,159
‫temps, et je ne veux pas vraiment casser ce schéma ici.

32
00:01:33,159 --> 00:01:37,000
‫Et donc, nous allons en fait promettre cette fonction.

33
00:01:37,000 --> 00:01:40,370
‫Donc en gros, pour lui faire revenir une promesse.

34
00:01:40,370 --> 00:01:42,660
‫Et de cette façon, nous pouvons ensuite utiliser

35
00:01:42,660 --> 00:01:45,613
‫async wait comme n'importe quelle autre fonction async que nous avons utilisée.

36
00:01:46,820 --> 00:01:48,050
‫Donc, pour ce

37
00:01:48,050 --> 00:01:51,050
‫faire, Node a en fait une fonction de promesse intégrée.

38
00:01:51,050 --> 00:01:53,650
‫Tout ce que nous devons faire

39
00:01:53,650 --> 00:01:56,663
‫pour l'utiliser est d'exiger le module util intégré.

40
00:01:58,695 --> 00:02:00,895
‫Faisons-le tout en haut, en fait.

41
00:02:02,900 --> 00:02:07,900
‫Cela va donc créer un objet appelé util, require...

42
00:02:10,740 --> 00:02:13,400
‫D'accord, ça veut dire utilité.

43
00:02:13,400 --> 00:02:15,420
‫Ce n'est pas ce que je voulais.

44
00:02:15,420 --> 00:02:16,960
‫Cela signifie donc utilité.

45
00:02:16,960 --> 00:02:20,300
‫Et puis là-bas, nous allons utiliser la méthode de promisify.

46
00:02:20,300 --> 00:02:22,900
‫Mais comme nous n'allons utiliser que cette seule méthode, nous pouvons

47
00:02:22,900 --> 00:02:24,603
‫en fait le faire plus facilement.

48
00:02:25,578 --> 00:02:26,990
‫Ainsi, au lieu

49
00:02:26,990 --> 00:02:30,610
‫de faire cela, nous pouvons simplement déstructurer cet objet et prendre

50
00:02:30,610 --> 00:02:32,823
‫des promesses directement à partir de là.

51
00:02:35,388 --> 00:02:38,453
‫Encore une fois, il s'agit simplement d'utiliser la déstructuration ES6.

52
00:02:41,182 --> 00:02:43,230
‫D'accord, donc et maintenant c'est très facile à utiliser.

53
00:02:43,230 --> 00:02:46,127
‫Tout ce que nous avons à faire est d'appeler la promesse.

54
00:02:47,434 --> 00:02:51,463
‫Alors promettez, puis passez la fonction là-dedans.

55
00:02:53,500 --> 00:02:56,080
‫Et donc maintenant, tout cela ici est une fonction

56
00:02:56,080 --> 00:02:56,970
‫que nous

57
00:02:56,970 --> 00:02:59,190
‫devons appeler, qui retournera ensuite une promesse.

58
00:02:59,190 --> 00:03:01,810
‫Alors ici, nous appelons en fait la fonction.

59
00:03:01,810 --> 00:03:03,900
‫Et cela renverra alors une

60
00:03:03,900 --> 00:03:08,300
‫promesse, et nous pouvons donc l'attendre et stocker le résultat dans une variable.

61
00:03:08,300 --> 00:03:10,390
‫Ainsi, la valeur de résultat de la

62
00:03:10,390 --> 00:03:12,350
‫promesse sera en fait les

63
00:03:12,350 --> 00:03:15,823
‫données décodées, donc la charge utile décodée de ce jeton Web JSON.

64
00:03:17,600 --> 00:03:19,360
‫Alors laissez-moi l'appeler décodé ici.

65
00:03:19,360 --> 00:03:20,193
‫D'accord.

66
00:03:20,193 --> 00:03:23,490
‫Et nous pouvons attendre car nous avons déjà dit

67
00:03:23,490 --> 00:03:25,453
‫que c'est une fonction asynchrone.

68
00:03:27,670 --> 00:03:30,850
‫Et maintenant, juste pour voir que cela

69
00:03:30,850 --> 00:03:34,730
‫fonctionne réellement, enregistrons également ces données décodées sur la console.

70
00:03:34,730 --> 00:03:38,143
‫Et effectivement, on peut supprimer cette console. déconnectez-vous du jeton.

71
00:03:39,050 --> 00:03:40,400
‫Celui-là dont nous n'avons plus besoin.

72
00:03:42,140 --> 00:03:46,560
‫Essayons donc d'envoyer à nouveau cette demande, et oui, mais

73
00:03:46,560 --> 00:03:49,990
‫cette fois en activant cet en-tête d'autorisation

74
00:03:49,990 --> 00:03:54,850
‫afin que nous envoyions un jeton Web JSON avec la demande.

75
00:03:54,850 --> 00:03:55,940
‫Alors ça l'a envoyé.

76
00:03:55,940 --> 00:03:58,540
‫Et maintenant, en effet, nous avons accès aux

77
00:03:58,540 --> 00:04:02,070
‫données, et donc, nous avons maintenant accès à la route protégée.

78
00:04:02,070 --> 00:04:02,903
‫D'accord?

79
00:04:02,903 --> 00:04:06,203
‫Mais ce que je voulais voir, c'est cet objet décodé ici.

80
00:04:07,230 --> 00:04:09,910
‫Et donc ceci ici devrait être l'ID utilisateur.

81
00:04:09,910 --> 00:04:12,530
‫Jetons donc un coup d'œil à cela dans Postman.

82
00:04:12,530 --> 00:04:13,423
‫Donc 62a42.

83
00:04:15,520 --> 00:04:18,740
‫Et donc, en effet, eh bien, où avons-nous cela?

84
00:04:18,740 --> 00:04:20,193
‫Jetons un coup d'œil à Compass.

85
00:04:21,240 --> 00:04:24,813
‫Et en effet, l'ID de cet utilisateur est ce 62a42.

86
00:04:27,160 --> 00:04:29,347
‫Et cela signifie que nous avons en

87
00:04:29,347 --> 00:04:31,340
‫fait notre charge utile correcte ici.

88
00:04:31,340 --> 00:04:33,420
‫Donc, en gros, l'ID utilisateur correct.

89
00:04:33,420 --> 00:04:36,460
‫Nous avons alors également l'horodatage de la date de

90
00:04:36,460 --> 00:04:39,500
‫création et de la date d'expiration du jeton.

91
00:04:39,500 --> 00:04:40,700
‫Donc ça marche.

92
00:04:40,700 --> 00:04:43,710
‫Mais essayons maintenant de manipuler la charge utile de

93
00:04:43,710 --> 00:04:44,563
‫ce jeton.

94
00:04:47,088 --> 00:04:49,090
‫Alors copions-le ici à nouveau.

95
00:04:49,090 --> 00:04:52,443
‫Mais ensuite, je vais au débogueur JWT.

96
00:04:54,640 --> 00:04:57,023
‫Encore une fois, chez jwt. io.

97
00:05:00,290 --> 00:05:02,363
‫Alors enlevons ça.

98
00:05:03,310 --> 00:05:06,010
‫Et maintenant, ce que je vais faire, c'est modifier

99
00:05:06,010 --> 00:05:09,260
‫certaines données ici et cela changera ensuite le jeton encodé ici,

100
00:05:09,260 --> 00:05:11,010
‫que je pourrai ensuite copier.

101
00:05:12,420 --> 00:05:14,693
‫Remplaçons donc simplement, en fait,

102
00:05:15,580 --> 00:05:19,050
‫je vais simplement remplacer ces deux nombres ici par

103
00:05:19,050 --> 00:05:20,940
‫quelque chose de différent.

104
00:05:20,940 --> 00:05:23,590
‫Et donc, comme vous le voyez, cela a changé le jeton ici.

105
00:05:23,590 --> 00:05:26,040
‫Et maintenant, je vais essayer d'accéder à

106
00:05:26,040 --> 00:05:27,470
‫cette route protégée

107
00:05:27,470 --> 00:05:30,373
‫à l'aide de ce jeton Web JSON manipulé.

108
00:05:31,460 --> 00:05:33,133
‫D'accord, ça a du sens ?

109
00:05:34,100 --> 00:05:37,023
‫Donc juste pour voir si cela fonctionne correctement.

110
00:05:38,632 --> 00:05:39,970
‫Je copie donc

111
00:05:39,970 --> 00:05:42,660
‫celui-ci ici maintenant et colle cet autre différent.

112
00:05:42,660 --> 00:05:47,310
‫Et donc, si j'envoie maintenant cette demande, alors nous obtenons une erreur.

113
00:05:47,310 --> 00:05:48,250
‫Tellement bon.

114
00:05:48,250 --> 00:05:50,843
‫Ainsi, nous voyons que le nom de l'erreur est

115
00:05:51,840 --> 00:05:54,220
‫JsonWebTokenError, et nous avons une signature invalide.

116
00:05:54,220 --> 00:05:55,160
‫Tellement bon.

117
00:05:55,160 --> 00:05:57,650
‫C'est exactement ce que nous recherchions.

118
00:05:57,650 --> 00:06:00,210
‫C'est donc l'une des deux erreurs qui peuvent se produire.

119
00:06:00,210 --> 00:06:02,853
‫L'autre est que le jeton a déjà expiré.

120
00:06:04,359 --> 00:06:07,180
‫Donc celui-ci s'appelle JsonWebTokenError, et donc

121
00:06:07,180 --> 00:06:10,890
‫en fait, allons de l'avant et gérons cette erreur maintenant.

122
00:06:10,890 --> 00:06:12,240
‫Et la façon

123
00:06:12,240 --> 00:06:16,470
‫dont nous pourrions le faire est d'ajouter un bloc try-catch ici.

124
00:06:16,470 --> 00:06:17,460
‫Droit?

125
00:06:17,460 --> 00:06:19,600
‫Donc juste après avoir fait ce code,

126
00:06:19,600 --> 00:06:21,510
‫nous pourrions introduire un bloc

127
00:06:21,510 --> 00:06:24,260
‫try, puis dans le catch, nous créerions ensuite des

128
00:06:24,260 --> 00:06:26,290
‫erreurs qui seraient envoyées au client.

129
00:06:26,290 --> 00:06:28,070
‫Maintenant, au lieu de procéder ainsi,

130
00:06:28,070 --> 00:06:30,970
‫je souhaite en fait utiliser notre middleware global de gestion

131
00:06:30,970 --> 00:06:33,290
‫des erreurs afin de le faire pour nous.

132
00:06:33,290 --> 00:06:35,850
‫Nous n'aimons donc pas gérer les erreurs ici même

133
00:06:35,850 --> 00:06:37,220
‫dans notre fonction middleware.

134
00:06:37,220 --> 00:06:41,140
‫Au lieu de cela, nous le déléguons généralement au contrôleur d'erreur.

135
00:06:41,140 --> 00:06:43,940
‫Et donc, faisons exactement la même chose ici.

136
00:06:43,940 --> 00:06:46,710
‫Donc contrôleur d'erreur.

137
00:06:46,710 --> 00:06:48,600
‫Et puis c'est en fait exactement la

138
00:06:48,600 --> 00:06:50,930
‫même chose que nous avons avec nos autres erreurs ici.

139
00:06:50,930 --> 00:06:54,210
‫Ainsi par exemple, l'erreur de validation venant de Mongoose,

140
00:06:54,210 --> 00:06:55,670
‫donc d'une autre librairie.

141
00:06:55,670 --> 00:06:59,060
‫Et maintenant, cette erreur provient en fait d'une autre

142
00:06:59,060 --> 00:07:02,180
‫bibliothèque et elle a également son propre nom.

143
00:07:02,180 --> 00:07:03,470
‫Alors allons-y.

144
00:07:03,470 --> 00:07:04,820
‫Et c'est JsonWebTokenError.

145
00:07:06,900 --> 00:07:07,940
‫D'accord.

146
00:07:07,940 --> 00:07:09,923
‫Et donc, faisons très similaire ici.

147
00:07:11,850 --> 00:07:12,683
‫Donc si. name

148
00:07:15,477 --> 00:07:19,310
‫est celui-ci, alors error doit être égal à handle error.

149
00:07:19,310 --> 00:07:23,463
‫D'accord.

150
00:07:27,010 --> 00:07:27,843
‫Alors allons-y

151
00:07:27,843 --> 00:07:30,430
‫et créons cette fonction, en fait, quelque part ici.

152
00:07:30,430 --> 00:07:31,953
‫Et celui-ci est en fait extrêmement simple.

153
00:07:35,782 --> 00:07:37,810
‫Tout ce qu'il fait est de prendre une

154
00:07:37,810 --> 00:07:39,760
‫erreur, puis de renvoyer une nouvelle AppError.

155
00:07:39,760 --> 00:07:41,433
‫D'accord?

156
00:07:44,480 --> 00:07:45,320
‫Donc, dans

157
00:07:45,320 --> 00:07:48,950
‫cette fonction de flèche ES6, comme j'espère que vous le savez, nous pouvons

158
00:07:48,950 --> 00:07:50,790
‫écrire ces lignes simples où nous n'avons

159
00:07:50,790 --> 00:07:53,610
‫même pas à spécifier les accolades ni le mot-clé return.

160
00:07:53,610 --> 00:07:55,610
‫Cela retournera donc automatiquement

161
00:07:55,610 --> 00:07:58,670
‫et implicitement tout ce que nous mettons ici.

162
00:07:58,670 --> 00:08:00,123
‫Droit?

163
00:08:01,010 --> 00:08:01,843
‫Et donc,

164
00:08:01,843 --> 00:08:04,763
‫ce que nous voulons dire ici est simplement un jeton

165
00:08:05,980 --> 00:08:07,273
‫invalide, veuillez vous reconnecter.

166
00:08:09,580 --> 00:08:12,640
‫Et puis, le code d'erreur, comme avant,

167
00:08:12,640 --> 00:08:15,000
‫est un 401 pour Unauthorized.

168
00:08:15,000 --> 00:08:17,463
‫Maintenant, cela ne fonctionne, rappelez-vous, qu'en production.

169
00:08:19,497 --> 00:08:22,410
‫Et donc, si nous faisions cela à nouveau maintenant,

170
00:08:22,410 --> 00:08:24,883
‫nous obtiendrions exactement la même chose.

171
00:08:24,883 --> 00:08:27,730
‫Et donc, revenons en fait ici et

172
00:08:27,730 --> 00:08:29,890
‫exécutons cela en production.

173
00:08:29,890 --> 00:08:32,340
‫Alors npm run start:production.

174
00:08:32,340 --> 00:08:37,340
‫Ouais, juste comme ça.

175
00:08:39,470 --> 00:08:40,733
‫Donc, si nous essayons

176
00:08:41,650 --> 00:08:43,890
‫à nouveau maintenant, voyons si nous obtenons notre erreur.

177
00:08:43,890 --> 00:08:45,630
‫Et en effet, nous le faisons.

178
00:08:45,630 --> 00:08:47,840
‫Donc, si, en ce moment, un utilisateur en

179
00:08:47,840 --> 00:08:50,040
‫production essaie d'accéder à notre application avec

180
00:08:50,040 --> 00:08:52,930
‫un jeton invalide, eh bien, il n'obtient que ce message d'erreur.

181
00:08:52,930 --> 00:08:55,890
‫D'accord?

182
00:08:55,890 --> 00:08:57,120
‫C'est donc la première erreur que nous pouvons obtenir.

183
00:08:57,120 --> 00:08:59,920
‫Mais un autre est que l'utilisateur essaie

184
00:08:59,920 --> 00:09:01,560
‫d'accéder à l'application

185
00:09:01,560 --> 00:09:03,500
‫avec un jeton déjà expiré.

186
00:09:03,500 --> 00:09:06,147
‫Et donc, essayons maintenant de créer cette erreur.

187
00:09:06,147 --> 00:09:08,733
‫Et pour ce faire, je vais

188
00:09:09,683 --> 00:09:13,080
‫changer le temps qu'il faut pour que le jeton expire.

189
00:09:13,080 --> 00:09:14,943
‫Donc en ce moment, nous avons 90 jours.

190
00:09:17,811 --> 00:09:19,190
‫Mettons ça à, genre, cinq secondes.

191
00:09:19,190 --> 00:09:22,183
‫D'accord.

192
00:09:23,078 --> 00:09:23,911
‫Donnez-lui une sauvegarde.

193
00:09:23,911 --> 00:09:24,870
‫Et maintenant, essayez de vous connecter à nouveau.

194
00:09:24,870 --> 00:09:26,823
‫Alors gardons en fait celui-ci ici aussi.

195
00:09:28,090 --> 00:09:30,943
‫Donc, dans les utilisateurs, puis connectez-vous.

196
00:09:32,920 --> 00:09:37,043
‫Nous pouvons donc nous connecter, et cela nous donnera alors un

197
00:09:39,060 --> 00:09:43,100
‫nouveau jeton, mais ce jeton n'est valable que cinq secondes.

198
00:09:43,100 --> 00:09:46,100
‫Et donc, ces cinq secondes auraient dû s'écouler à ce stade.

199
00:09:46,100 --> 00:09:49,550
‫Je vais donc maintenant copier ce jeton et essayer d'accéder à notre

200
00:09:49,550 --> 00:09:51,690
‫route protégée à l'aide de ce jeton.

201
00:09:51,690 --> 00:09:55,713
‫Alors collez-le ici.

202
00:09:58,529 --> 00:09:59,362
‫Et maintenant, voyons ce que nous obtenons.

203
00:09:59,362 --> 00:10:01,630
‫Et en fait, pour une raison quelconque, cela a fonctionné.

204
00:10:01,630 --> 00:10:04,280
‫Jetons donc à nouveau un coup d'œil à notre débogueur JWT.

205
00:10:04,280 --> 00:10:08,593
‫Et il est dit, créé le 2 mai, mais

206
00:10:11,620 --> 00:10:14,160
‫n'expire que le 31 juillet.

207
00:10:14,160 --> 00:10:16,720
‫Donc quelque chose s'est mal passé dans cette création de jeton, je suppose.

208
00:10:16,720 --> 00:10:21,023
‫Et donc, changeons cela ici encore.

209
00:10:22,140 --> 00:10:23,810
‫Et je vais juste en mettre cinq ici.

210
00:10:23,810 --> 00:10:25,993
‫Et donc, ce cinq devrait alors

211
00:10:27,270 --> 00:10:30,340
‫rester cinq millisecondes, ou je peux même, comme, mettre 5000,

212
00:10:30,340 --> 00:10:32,630
‫ce qui devrait alors être cinq secondes.

213
00:10:32,630 --> 00:10:34,733
‫D'accord.

214
00:10:37,680 --> 00:10:38,890
‫Alors permettez-moi de l'enregistrer à nouveau afin de redémarrer le serveur.

215
00:10:38,890 --> 00:10:42,363
‫Essayez à nouveau.

216
00:10:43,240 --> 00:10:44,570
‫Alors reconnectez-vous ici.

217
00:10:44,570 --> 00:10:46,113
‫D'accord.

218
00:10:47,680 --> 00:10:48,600
‫Alors maintenant, tout ce

219
00:10:48,600 --> 00:10:52,930
‫que nous avons à faire est d'attendre cinq secondes, et ce temps devrait déjà s'être écoulé à ce stade.

220
00:10:52,930 --> 00:10:56,933
‫Collez-le ici à nouveau.

221
00:11:00,230 --> 00:11:01,500
‫Et allons-y.

222
00:11:01,500 --> 00:11:03,560
‫Et effectivement, nous obtenons une erreur.

223
00:11:03,560 --> 00:11:05,860
‫Rappelez-vous maintenant qu'il s'agit essentiellement de

224
00:11:05,860 --> 00:11:09,850
‫l'erreur standard que nous obtenons au cas où nous ne gérons

225
00:11:09,850 --> 00:11:13,230
‫pas correctement cette erreur dans notre gestion des erreurs.

226
00:11:13,230 --> 00:11:14,700
‫Droit?

227
00:11:14,700 --> 00:11:15,750
‫Jetons donc un œil à l'erreur.

228
00:11:15,750 --> 00:11:18,840
‫Et en fait, nous l'avons ici dans la console.

229
00:11:18,840 --> 00:11:21,350
‫Voyons donc d'où cela vient.

230
00:11:21,350 --> 00:11:24,620
‫Et oui, ça vient de cet endroit.

231
00:11:24,620 --> 00:11:26,673
‫C'est donc le cas où nous avons une erreur inconnue.

232
00:11:27,760 --> 00:11:31,690
‫Rappelez-vous, donc une erreur qui n'est pas marquée comme

233
00:11:31,690 --> 00:11:34,090
‫une erreur opérationnelle, et donc nous

234
00:11:34,090 --> 00:11:35,640
‫voulons la consigner.

235
00:11:35,640 --> 00:11:37,543
‫Nous l'enregistrons donc ici, puis nous

236
00:11:38,500 --> 00:11:39,650
‫envoyons ce message d'erreur

237
00:11:39,650 --> 00:11:42,150
‫générique au client, donc celui que nous venons de

238
00:11:42,150 --> 00:11:43,270
‫voir dans Postman.

239
00:11:43,270 --> 00:11:45,610
‫Mais ici, nous avons en fait les détails de cette erreur.

240
00:11:45,610 --> 00:11:48,100
‫Et donc, celui-ci porte le nom de TokenExpiredError.

241
00:11:48,100 --> 00:11:51,480
‫D'accord.

242
00:11:51,480 --> 00:11:52,313
‫Et donc, gérons maintenant celui-ci également.

243
00:11:52,313 --> 00:11:55,360
‫Alors je le copie maintenant, puis je crée juste

244
00:11:55,360 --> 00:11:57,171
‫un autre if ici.

245
00:11:57,171 --> 00:12:02,171
‫Donc si l'erreur. name est égal à celui-ci, eh

246
00:12:02,300 --> 00:12:07,300
‫bien, disons, handleJWTExpiredError

247
00:12:08,980 --> 00:12:10,343
‫avec

248
00:12:12,711 --> 00:12:14,461
‫la flèche.

249
00:12:18,640 --> 00:12:20,233
‫Copions-le et mettons-le ici.

250
00:12:22,568 --> 00:12:25,750
‫Et donc ceci, bien sûr, est très similaire à celui d'avant.

251
00:12:33,186 --> 00:12:37,770
‫Votre jeton a expiré.

252
00:12:37,770 --> 00:12:40,493
‫Veuillez vous reconnecter.

253
00:12:43,940 --> 00:12:45,193
‫Et encore, avec un code d'erreur 401.

254
00:12:48,670 --> 00:12:51,423
‫Bon, essayons encore.

255
00:12:52,360 --> 00:12:54,270
‫Et donc, c'est exactement le message d'erreur

256
00:12:54,270 --> 00:12:56,043
‫que nous devrions maintenant voir ici.

257
00:12:56,043 --> 00:12:58,023
‫D'accord.

258
00:12:59,430 --> 00:13:00,263
‫Et en effet, il l'est.

259
00:13:00,263 --> 00:13:01,263
‫Super.

260
00:13:02,480 --> 00:13:03,520
‫Finissons le processus ici

261
00:13:03,520 --> 00:13:04,980
‫et démarrons-le en mode développeur, bien sûr.

262
00:13:04,980 --> 00:13:07,560
‫Alors npm start,

263
00:13:07,560 --> 00:13:10,213
‫et tout va bien.

264
00:13:11,700 --> 00:13:13,740
‫Alors celui-ci, nous n'en avons plus besoin, alors fermons-le.

265
00:13:13,740 --> 00:13:17,460
‫Ou en fait, corrigeons cette petite erreur ici, car en effet, nous

266
00:13:17,460 --> 00:13:19,880
‫n'utilisons pas du tout cette erreur ici.

267
00:13:19,880 --> 00:13:23,113
‫Alors débarrassons-nous en.

268
00:13:24,170 --> 00:13:25,423
‫Et puis ici-bas, nous n'avons pas besoin de le transmettre là-bas.

269
00:13:29,260 --> 00:13:32,063
‫Frais.

270
00:13:39,290 --> 00:13:40,123
‫Bien entendu, nous devons également revenir à 90 jours.

271
00:13:41,060 --> 00:13:44,423
‫D'accord.

272
00:13:47,200 --> 00:13:48,040
‫Et

273
00:13:48,040 --> 00:13:51,560
‫donc, juste pour être vraiment sûr, reconnectons-nous ici,

274
00:13:51,560 --> 00:13:52,803
‫copions le

275
00:13:53,830 --> 00:13:55,513
‫jeton et mettons-le ici.

276
00:13:56,680 --> 00:13:59,050
‫Maintenant, ce processus ici de copier le jeton,

277
00:13:59,050 --> 00:14:01,750
‫puis de le coller ici dans cet en-tête peut

278
00:14:01,750 --> 00:14:04,190
‫sembler un peu étrange, et en fait, nous allons

279
00:14:04,190 --> 00:14:05,640
‫corriger cela dans l'une

280
00:14:05,640 --> 00:14:07,230
‫des futures vidéos afin que,

281
00:14:07,230 --> 00:14:09,030
‫fondamentalement, ce processus se produise automatiquement.

282
00:14:09,030 --> 00:14:12,070
‫Mais maintenant, ce qui est important, c'est qu'il est réellement

283
00:14:12,070 --> 00:14:13,970
‫de retour au travail maintenant.

284
00:14:13,970 --> 00:14:16,750
‫Nous pouvons donc effectivement nous débarrasser de cette console. connectez-vous ici et passez

285
00:14:16,750 --> 00:14:21,027
‫à l'étape suivante.

286
00:14:21,027 --> 00:14:24,250
‫Et nous pourrions en fait nous arrêter ici maintenant si nous le voulions.

287
00:14:24,250 --> 00:14:27,010
‫Et encore une fois, la plupart des

288
00:14:27,010 --> 00:14:30,130
‫tutoriels que vous allez découvrir s'arrêteraient en fait ici.

289
00:14:30,130 --> 00:14:32,420
‫Mais ce n'est pas encore assez sûr pour l'instant.

290
00:14:32,420 --> 00:14:35,210
‫Ainsi, par exemple, que se passe-t-il si l'utilisateur

291
00:14:35,210 --> 00:14:37,550
‫a été supprimé entre-temps ?

292
00:14:37,550 --> 00:14:39,840
‫Donc, le jeton existera toujours, mais si l'utilisateur

293
00:14:39,840 --> 00:14:41,800
‫n'existe plus, alors nous ne

294
00:14:41,800 --> 00:14:43,900
‫voulons pas le connecter, n'est-ce pas ?

295
00:14:43,900 --> 00:14:47,780
‫Ou pire encore, que se passe-t-il si l'utilisateur a effectivement

296
00:14:47,780 --> 00:14:50,070
‫changé son mot de passe après

297
00:14:50,070 --> 00:14:52,130
‫l'émission du token ?

298
00:14:52,130 --> 00:14:54,360
‫Eh bien, cela ne devrait pas non plus fonctionner, n'est-ce pas ?

299
00:14:54,360 --> 00:14:56,950
‫Par exemple, imaginez que quelqu'un

300
00:14:56,950 --> 00:15:00,750
‫a volé le jeton Web JSON à un utilisateur.

301
00:15:00,750 --> 00:15:01,870
‫Mais ensuite, afin de

302
00:15:01,870 --> 00:15:04,380
‫se protéger contre cela, l'utilisateur change son mot de passe.

303
00:15:04,380 --> 00:15:06,770
‫Et donc, bien sûr, cet ancien jeton émis avant

304
00:15:06,770 --> 00:15:09,270
‫le changement de mot de passe ne devrait plus être valide.

305
00:15:09,270 --> 00:15:12,940
‫Il ne devrait donc pas être accepté d'accéder aux routes protégées.

306
00:15:12,940 --> 00:15:16,906
‫Et donc, c'est le genre de choses que nous allons mettre en

307
00:15:16,906 --> 00:15:19,550
‫œuvre ici dans les étapes trois et quatre.

308
00:15:19,550 --> 00:15:22,060
‫La première chose à faire est donc de vérifier si

309
00:15:22,060 --> 00:15:23,120
‫l'utilisateur existe toujours.

310
00:15:23,120 --> 00:15:26,060
‫Et donc, celui-là devrait être le plus facile.

311
00:15:26,060 --> 00:15:28,690
‫Alors disons simplement, Utilisateur. findById.

312
00:15:28,690 --> 00:15:32,463
‫Et donc, c'est maintenant pourquoi nous avons

313
00:15:36,568 --> 00:15:38,440
‫en fait l'ID dans la charge

314
00:15:38,440 --> 00:15:40,540
‫utile, car nous pouvons maintenant utiliser cet ID

315
00:15:40,540 --> 00:15:42,767
‫et interroger l'utilisateur en utilisant uniquement cet ID.

316
00:15:42,767 --> 00:15:46,530
‫Donc décodé. identifiant.

317
00:15:46,530 --> 00:15:49,390
‫D'accord?

318
00:15:49,390 --> 00:15:50,223
‫Cela devrait donc trouver le nouvel utilisateur.

319
00:15:50,223 --> 00:15:53,110
‫Et bien sûr, nous devons attendre cela,

320
00:15:53,110 --> 00:15:55,860
‫puis le stocker dans une variable.

321
00:15:55,860 --> 00:15:59,560
‫Je l'appelle le freshUser.

322
00:15:59,560 --> 00:16:01,480
‫D'accord?

323
00:16:03,148 --> 00:16:03,981
‫Parce que ce n'est pas vraiment un nouvel utilisateur.

324
00:16:03,981 --> 00:16:05,460
‫C'est seulement lorsque nous en créons un.

325
00:16:05,460 --> 00:16:07,300
‫Mais ce n'est pas vraiment nouveau, c'est vraiment

326
00:16:07,300 --> 00:16:09,030
‫juste l'utilisateur basé sur l'ID décodé.

327
00:16:09,030 --> 00:16:12,980
‫D'accord?

328
00:16:12,980 --> 00:16:13,870
‫Et nous

329
00:16:13,870 --> 00:16:16,833
‫pouvons le faire pour être sûr à 100% que l'ID

330
00:16:16,833 --> 00:16:18,990
‫est réellement correct, car si nous l'avons

331
00:16:18,990 --> 00:16:22,460
‫fait jusqu'à ce point du code ici, cela signifie que le processus

332
00:16:22,460 --> 00:16:25,110
‫de vérification que nous avons précédemment, ici, a réussi.

333
00:16:25,110 --> 00:16:28,200
‫Sinon, cela aurait provoqué une erreur qui

334
00:16:28,200 --> 00:16:30,220
‫aurait alors empêché la fonction

335
00:16:30,220 --> 00:16:31,490
‫de continuer.

336
00:16:31,490 --> 00:16:33,410
‫Et donc, encore une fois,

337
00:16:33,410 --> 00:16:36,660
‫ce processus de vérification ici est en charge de la vérification

338
00:16:36,660 --> 00:16:38,620
‫si personne n'a modifié l'ID qui se

339
00:16:38,620 --> 00:16:40,900
‫trouve dans la charge utile de ce jeton.

340
00:16:40,900 --> 00:16:43,033
‫Et donc, à cause de cela,

341
00:16:43,970 --> 00:16:46,970
‫nous pouvons être sûrs à 100% que l'utilisateur pour lequel

342
00:16:46,970 --> 00:16:50,600
‫nous avons émis le JWT est exactement celui dont l'ID est maintenant à

343
00:16:50,600 --> 00:16:52,790
‫l'intérieur de la charge utile décodée, donc celui-ci.

344
00:16:52,790 --> 00:16:56,810
‫D'accord?

345
00:16:56,810 --> 00:16:57,690
‫Le processus de vérification est donc vraiment essentiel.

346
00:16:57,690 --> 00:17:00,440
‫C'est vraiment ce qui fait tout ce travail.

347
00:17:00,440 --> 00:17:02,440
‫Quoi qu'il en soit, maintenant ce que nous devons faire est

348
00:17:04,730 --> 00:17:06,410
‫de vérifier s'il y a réellement un freshUser.

349
00:17:06,410 --> 00:17:09,570
‫Et sinon, eh bien, bien sûr, nous allons

350
00:17:09,570 --> 00:17:11,570
‫retourner une nouvelle erreur.

351
00:17:11,570 --> 00:17:13,844
‫Donc, s'il n'y a pas de

352
00:17:13,844 --> 00:17:16,577
‫freshUser, revenez de ce middleware et appelez

353
00:17:19,880 --> 00:17:22,100
‫le suivant avec une erreur.

354
00:17:22,100 --> 00:17:24,083
‫C'est donc un modèle que nous avons vu

355
00:17:24,920 --> 00:17:27,100
‫maintes et maintes fois à ce stade, n'est-ce pas ?

356
00:17:27,100 --> 00:17:29,403
‫Le jeton n'existe donc

357
00:17:30,350 --> 00:17:31,490
‫plus.

358
00:17:35,470 --> 00:17:39,173
‫Et en fait, c'est l'inverse.

359
00:17:40,810 --> 00:17:42,750
‫Donc effectivement, l'utilisateur

360
00:17:42,750 --> 00:17:45,200
‫appartenant au token n'existe plus.

361
00:17:47,170 --> 00:17:48,680
‫Droit?

362
00:17:48,680 --> 00:17:49,513
‫Et puis, la 401.

363
00:17:49,513 --> 00:17:51,297
‫D'accord.

364
00:17:53,780 --> 00:17:54,920
‫Alors testons cela encore une fois.

365
00:17:54,920 --> 00:17:57,860
‫Et créons en fait un nouvel utilisateur pour cela.

366
00:17:57,860 --> 00:18:00,843
‫Alors testez simplement avec le même mot de passe afin que nous

367
00:18:02,620 --> 00:18:04,880
‫utilisions toujours le même ici juste pour rendre

368
00:18:04,880 --> 00:18:06,590
‫nos tests un peu plus faciles.

369
00:18:06,590 --> 00:18:09,160
‫Et je sais que tous ces tests ici font que

370
00:18:09,160 --> 00:18:11,070
‫la vidéo prend vraiment beaucoup de temps,

371
00:18:11,070 --> 00:18:14,440
‫mais bien sûr, il est vraiment important que nous testions tout ce que

372
00:18:14,440 --> 00:18:15,900
‫nous faisons, en particulier

373
00:18:15,900 --> 00:18:17,950
‫dans un sujet aussi important que l'authentification.

374
00:18:17,950 --> 00:18:21,713
‫J'utilise donc maintenant ce JWT ici, donc je le colle

375
00:18:23,071 --> 00:18:27,780
‫ici, mais bien sûr, avant d'envoyer la demande, je vais continuer et

376
00:18:27,780 --> 00:18:30,630
‫supprimer cet utilisateur tout de suite.

377
00:18:30,630 --> 00:18:33,573
‫D'accord?

378
00:18:34,650 --> 00:18:35,690
‫Encore une fois, supposons

379
00:18:35,690 --> 00:18:37,690
‫que quelqu'un ait créé un utilisateur puis s'est connecté,

380
00:18:37,690 --> 00:18:40,020
‫et disons qu'après un certain temps, l'utilisateur a été supprimé.

381
00:18:40,020 --> 00:18:43,500
‫Mais entre-temps, quelqu'un aurait pu avoir accès à ce JWT

382
00:18:43,500 --> 00:18:44,333
‫et

383
00:18:44,333 --> 00:18:47,410
‫pourrait maintenant essayer de se connecter en tant

384
00:18:47,410 --> 00:18:50,030
‫qu'utilisateur qui était, en fait, déjà supprimé.

385
00:18:50,030 --> 00:18:52,580
‫Et donc, encore une fois, nous ne devrions pas laisser cela se produire.

386
00:18:52,580 --> 00:18:55,520
‫Alors permettez-moi de supprimer cet utilisateur ici maintenant.

387
00:18:55,520 --> 00:18:57,713
‫Et voilà.

388
00:18:59,010 --> 00:18:59,943
‫Et donc, testons-le maintenant.

389
00:19:01,720 --> 00:19:03,630
‫Et encore une fois, gardez à l'esprit

390
00:19:03,630 --> 00:19:07,060
‫que l'utilisateur appartenant à l'ID qui se trouve dans cette charge utile n'est plus là.

391
00:19:07,060 --> 00:19:10,690
‫Voyons donc.

392
00:19:10,690 --> 00:19:12,040
‫Et en effet, nous obtenons ce message d'erreur que nous venons de créer.

393
00:19:12,040 --> 00:19:16,313
‫Donc celui-là fonctionne aussi.

394
00:19:17,520 --> 00:19:20,200
‫Et passons au dernier.

395
00:19:20,200 --> 00:19:22,400
‫Donc, étape numéro quatre, vérifiez si l'utilisateur a récemment

396
00:19:22,400 --> 00:19:23,830
‫changé son mot de passe.

397
00:19:23,830 --> 00:19:27,070
‫Donc, en gros, après l'émission du jeton.

398
00:19:27,070 --> 00:19:30,100
‫Et pour implémenter ce test, nous allons en fait créer

399
00:19:30,100 --> 00:19:31,550
‫une autre méthode d'instance.

400
00:19:31,550 --> 00:19:34,260
‫Donc en gros, une méthode qui

401
00:19:34,260 --> 00:19:37,030
‫va être disponible sur tous les documents.

402
00:19:37,030 --> 00:19:38,330
‫Les documents sont donc des instances d'un modèle.

403
00:19:38,330 --> 00:19:41,410
‫D'accord?

404
00:19:41,410 --> 00:19:42,243
‫Et nous le faisons

405
00:19:42,243 --> 00:19:44,490
‫parce que nous avons besoin de beaucoup de code pour cette vérification.

406
00:19:44,490 --> 00:19:46,540
‫Et donc, en fait, ce

407
00:19:46,540 --> 00:19:50,040
‫code appartient au modèle User et pas vraiment au contrôleur.

408
00:19:50,040 --> 00:19:51,970
‫D'accord?

409
00:19:51,970 --> 00:19:52,803
‫Et donc, faisons cela

410
00:19:52,803 --> 00:19:55,050
‫comme nous l'avons fait avant pour vérifier le mot de passe.

411
00:19:55,050 --> 00:19:57,270
‫Donc, dans le modèle utilisateur, nous avons déjà

412
00:19:57,270 --> 00:19:59,840
‫implémenté cette méthode d'instance statique correctPassword, vous vous souvenez ?

413
00:19:59,840 --> 00:20:04,710
‫Et donc, créons-en maintenant un autre.

414
00:20:04,710 --> 00:20:06,903
‫Donc userSchema. méthodes. mot de passe modifiéAprès.

415
00:20:08,339 --> 00:20:13,339
‫Donc, fonction, et dans

416
00:20:22,390 --> 00:20:24,550
‫cette fonction, nous passerons l'horodatage JWT.

417
00:20:24,550 --> 00:20:27,530
‫Donc, fondamentalement, cet horodatage qui indique quand le

418
00:20:27,530 --> 00:20:29,630
‫jeton a été émis.

419
00:20:29,630 --> 00:20:32,190
‫Appelons donc cela JWTTimestamp.

420
00:20:32,190 --> 00:20:34,437
‫D'accord.

421
00:20:40,310 --> 00:20:41,143
‫Et par défaut, nous retournerons false à partir de cette méthode.

422
00:20:41,143 --> 00:20:44,600
‫Et cela signifiera alors que l'utilisateur n'a pas changé

423
00:20:44,600 --> 00:20:45,720
‫son mot

424
00:20:45,720 --> 00:20:48,320
‫de passe après l'émission du token.

425
00:20:48,320 --> 00:20:50,410
‫D'accord?

426
00:20:50,410 --> 00:20:51,860
‫Mettons donc cela ici, renvoyons false, essentiellement par défaut.

427
00:20:51,860 --> 00:20:56,860
‫D'accord.

428
00:20:58,470 --> 00:20:59,303
‫Mais alors,

429
00:20:59,303 --> 00:21:02,987
‫nous avons aussi if this, et rappelons-nous que dans une méthode d'instance,

430
00:21:02,987 --> 00:21:05,827
‫le mot-clé this pointe toujours vers le document actuel.

431
00:21:05,827 --> 00:21:09,477
‫Et donc, ici, nous avons accès aux propriétés.

432
00:21:09,477 --> 00:21:13,210
‫Maintenant, nous devons en fait créer un champ dans notre schéma pour la

433
00:21:13,210 --> 00:21:16,280
‫date à laquelle le mot de passe a été modifié.

434
00:21:16,280 --> 00:21:18,750
‫Donc on n'a pas encore ça.

435
00:21:18,750 --> 00:21:20,050
‫Ajoutons-le donc rapidement ici.

436
00:21:21,200 --> 00:21:23,713
‫Donc passwordChangedAt, et le type de

437
00:21:25,980 --> 00:21:27,813
‫celui-ci sera une date.

438
00:21:31,320 --> 00:21:34,520
‫Maintenant, cette propriété passwordChangedAt ici sera

439
00:21:34,520 --> 00:21:37,890
‫toujours modifiée, bien sûr, lorsque quelqu'un changera

440
00:21:37,890 --> 00:21:40,160
‫le mot de passe.

441
00:21:40,160 --> 00:21:42,910
‫Donc pour le moment, nous n'avons cette logique nulle part, et

442
00:21:42,910 --> 00:21:45,270
‫donc nulle part nous ne définissons réellement cette propriété.

443
00:21:45,270 --> 00:21:48,743
‫Et donc, la plupart des documents, donc la

444
00:21:49,630 --> 00:21:53,230
‫plupart des utilisateurs, n'auront tout simplement pas cette propriété dans

445
00:21:53,230 --> 00:21:56,720
‫leurs données, donc dans leur objet, n'est-ce pas ?

446
00:21:56,720 --> 00:21:58,600
‫Et donc, bien sûr, nous devons tester cela.

447
00:21:58,600 --> 00:22:01,363
‫D'accord?

448
00:22:03,430 --> 00:22:04,610
‫Donc, si la

449
00:22:04,610 --> 00:22:07,740
‫propriété passwordChangedAt existe, alors seulement nous voulons réellement faire la comparaison.

450
00:22:07,740 --> 00:22:11,510
‫D'accord?

451
00:22:11,510 --> 00:22:12,343
‫Mais sinon,

452
00:22:12,343 --> 00:22:16,010
‫donc si passwordChanged n'existe pas, alors cela signifie que l'utilisateur n'a jamais

453
00:22:16,010 --> 00:22:17,640
‫réellement changé le mot de

454
00:22:17,640 --> 00:22:20,020
‫passe, et donc nous pouvons simplement retourner false.

455
00:22:20,020 --> 00:22:23,171
‫Encore une fois, c'est notre valeur par défaut, ce

456
00:22:23,171 --> 00:22:25,560
‫qui signifie que l'utilisateur n'a pas

457
00:22:25,560 --> 00:22:28,190
‫modifié le mot de passe après cet horodatage.

458
00:22:28,190 --> 00:22:30,540
‫D'accord.

459
00:22:30,540 --> 00:22:31,373
‫Et

460
00:22:31,373 --> 00:22:35,760
‫maintenant, juste pour commencer, connectons ceci à la console. passwordChangedAt, et bien sûr, le JWTTimestamp également, juste pour que

461
00:22:35,760 --> 00:22:37,933
‫nous puissions

462
00:22:39,370 --> 00:22:42,010
‫voir comment nous pourrions les comparer.

463
00:22:42,010 --> 00:22:44,950
‫D'accord.

464
00:22:44,950 --> 00:22:45,783
‫Et maintenant, nous

465
00:22:47,560 --> 00:22:49,690
‫devons réellement créer un utilisateur qui possède cette propriété, d'accord ?

466
00:22:49,690 --> 00:22:52,720
‫Et encore une fois, plus loin dans la section, lorsque

467
00:22:52,720 --> 00:22:54,260
‫nous implémenterons la logique pour

468
00:22:54,260 --> 00:22:57,280
‫changer le mot de passe, nous définirons ensuite cette propriété.

469
00:22:57,280 --> 00:22:59,760
‫D'accord?

470
00:22:59,760 --> 00:23:00,593
‫Mais maintenant,

471
00:23:00,593 --> 00:23:04,140
‫nous allons le définir artificiellement ici lorsque nous créerons un nouvel utilisateur.

472
00:23:04,140 --> 00:23:06,260
‫D'accord?

473
00:23:06,260 --> 00:23:07,093
‫Mettons donc ça ici.

474
00:23:08,690 --> 00:23:10,130
‫Et ici, n'importe quelle date, en fait, servira.

475
00:23:10,130 --> 00:23:12,810
‫Disons donc le 30 avril 2019 ici.

476
00:23:12,810 --> 00:23:17,810
‫Et cela devrait ensuite être analysé correctement dans MongoDB.

477
00:23:18,430 --> 00:23:21,313
‫Essayons ça, voyons si ça marche.

478
00:23:22,460 --> 00:23:24,293
‫Et cela n'a pas fonctionné.

479
00:23:25,210 --> 00:23:26,520
‫Donc, il ne pouvait pas vraiment analyser la date, disons.

480
00:23:26,520 --> 00:23:29,913
‫Et en fait, je dois commencer par l'année

481
00:23:30,980 --> 00:23:33,710
‫puis le jour à la fin.

482
00:23:33,710 --> 00:23:36,400
‫Donc 2019 puis 30 avril.

483
00:23:36,400 --> 00:23:41,050
‫Essayez à nouveau.

484
00:23:41,050 --> 00:23:42,103
‫Et donc vous voyez que maintenant cela fonctionne réellement.

485
00:23:43,190 --> 00:23:45,300
‫Nous avons donc cette date analysée ici.

486
00:23:45,300 --> 00:23:48,210
‫D'accord?

487
00:23:48,210 --> 00:23:49,350
‫Maintenant, afin de voir

488
00:23:49,350 --> 00:23:51,910
‫réellement le résultat de cela, nous devons bien sûr appeler cette méthode.

489
00:23:51,910 --> 00:23:55,040
‫D'accord?

490
00:23:55,040 --> 00:23:56,560
‫C'est donc ce que nous allons faire ici à l'étape quatre.

491
00:23:56,560 --> 00:23:59,033
‫D'accord?

492
00:24:00,010 --> 00:24:01,110
‫Et donc, rappelez-vous

493
00:24:01,110 --> 00:24:04,630
‫que nous pouvons appeler cette méthode d'instance sur un document utilisateur.

494
00:24:04,630 --> 00:24:06,200
‫Tellement fraisUtilisateur. ChangePasswordAfter, puis cet

495
00:24:06,200 --> 00:24:09,197
‫horodatage.

496
00:24:14,837 --> 00:24:17,370
‫C'est donc à décodé. iat, donc émis à, essentiellement.

497
00:24:17,370 --> 00:24:22,370
‫D'accord.

498
00:24:25,450 --> 00:24:26,350
‫Voyons donc simplement le résultat de cela.

499
00:24:26,350 --> 00:24:29,130
‫Et donc, bien sûr, cela devrait maintenant, pas

500
00:24:29,130 --> 00:24:32,953
‫ici, donc cela devrait maintenant enregistrer ces deux valeurs dans la console.

501
00:24:33,870 --> 00:24:37,123
‫D'accord.

502
00:24:39,320 --> 00:24:40,153
‫Maintenant, bien

503
00:24:40,153 --> 00:24:43,170
‫sûr, je dois me connecter avec exactement cet utilisateur, donc avec

504
00:24:43,170 --> 00:24:44,223
‫test, alors c'est parti.

505
00:24:47,780 --> 00:24:48,853
‫Connexion.

506
00:24:50,250 --> 00:24:51,173
‫Copiez à nouveau ce jeton ici.

507
00:24:53,090 --> 00:24:56,200
‫Et encore une fois, nous allons

508
00:24:56,200 --> 00:24:59,580
‫automatiser cela dans la prochaine vidéo, en fait.

509
00:24:59,580 --> 00:25:01,233
‫D'accord.

510
00:25:02,740 --> 00:25:03,700
‫Collez-le ici.

511
00:25:03,700 --> 00:25:04,673
‫Et maintenant, nous obtenons en fait ce bogue ici.

512
00:25:05,670 --> 00:25:08,312
‫J'ai donc mal orthographié ce nom de fonction ici.

513
00:25:08,312 --> 00:25:13,312
‫Eh bien, copions-le simplement.

514
00:25:13,670 --> 00:25:14,920
‫Essayez à nouveau.

515
00:25:16,410 --> 00:25:17,403
‫Oh mec.

516
00:25:18,780 --> 00:25:20,150
‫Qu'est-ce qui ne va pas maintenant ?

517
00:25:20,150 --> 00:25:21,823
‫Et je vois que j'ai simplement oublié ce journal ici.

518
00:25:25,420 --> 00:25:27,633
‫Donc encore une erreur stupide.

519
00:25:28,752 --> 00:25:30,090
‫J'ai probablement vu celui-là venir.

520
00:25:30,090 --> 00:25:32,320
‫Mais maintenant, nous y allons.

521
00:25:32,320 --> 00:25:33,550
‫Tout a donc bien

522
00:25:33,550 --> 00:25:35,120
‫fonctionné, et tout ce que nous

523
00:25:35,120 --> 00:25:37,450
‫voulions vraiment voir pour l'instant, ce sont ces deux résultats.

524
00:25:37,450 --> 00:25:39,560
‫Donc, nous avons essentiellement celui-ci ici ce

525
00:25:39,560 --> 00:25:43,110
‫format de date, puis l'autre dans cet horodatage en millisecondes ou en

526
00:25:43,110 --> 00:25:43,943
‫deuxième ici.

527
00:25:43,943 --> 00:25:47,600
‫Et donc, nous devons maintenant convertir ce

528
00:25:47,600 --> 00:25:51,670
‫mot de passeChangedAt également en un horodatage comme celui-ci.

529
00:25:51,670 --> 00:25:54,240
‫D'accord?

530
00:25:54,240 --> 00:25:55,073
‫Et donc, pour cela, créons une nouvelle variable.

531
00:25:55,073 --> 00:25:57,853
‫Donc changé l'horodatage.

532
00:25:59,560 --> 00:26:01,330
‫Et nous pouvons l'utiliser. mot de passeChangedAt. obtenir du temps.

533
00:26:03,800 --> 00:26:06,100
‫D'accord?

534
00:26:12,730 --> 00:26:13,563
‫Et donc,

535
00:26:13,563 --> 00:26:16,913
‫c'est l'une des nombreuses fonctions de date que JavaScript nous donne.

536
00:26:16,913 --> 00:26:18,563
‫D'accord.

537
00:26:19,450 --> 00:26:20,960
‫Et maintenant, comparons rapidement ces deux-là

538
00:26:20,960 --> 00:26:23,760
‫parce que nous ne sommes pas encore tout à fait prêts, en fait.

539
00:26:23,760 --> 00:26:26,253
‫Alors envoyez-le juste pour voir les résultats ici.

540
00:26:28,770 --> 00:26:31,930
‫Et donc ce que nous voyons ici essentiellement, c'est

541
00:26:31,930 --> 00:26:33,610
‫que celui-ci ici est

542
00:26:33,610 --> 00:26:36,580
‫maintenant, essentiellement, en secondes, et celui-ci en millisecondes.

543
00:26:36,580 --> 00:26:38,210
‫C'est donc 1000 fois plus.

544
00:26:38,210 --> 00:26:40,540
‫Et donc, nous savons que nous devons diviser

545
00:26:40,540 --> 00:26:43,340
‫cela par 1000, puis analyser tout cela comme un entier.

546
00:26:45,630 --> 00:26:48,583
‫Et pour cela, nous utilisons parseInt.

547
00:26:50,550 --> 00:26:52,820
‫Donc, une autre fonction JavaScript disponible pour les nombres.

548
00:26:52,820 --> 00:26:57,180
‫Et puis nous devons également spécifier la base.

549
00:26:57,180 --> 00:27:00,320
‫Il s'agit donc d'un nombre en base 10.

550
00:27:00,320 --> 00:27:02,920
‫D'accord?

551
00:27:02,920 --> 00:27:03,970
‫Et maintenant, voyons encore une fois le résultat.

552
00:27:03,970 --> 00:27:07,373
‫Et maintenant, cela semble beaucoup plus convivial.

553
00:27:10,120 --> 00:27:13,360
‫D'accord.

554
00:27:13,360 --> 00:27:14,193
‫Et donc, retournons maintenant notre résultat.

555
00:27:14,193 --> 00:27:17,040
‫Et encore une fois, gardez à l'esprit que faux signifie pas changé.

556
00:27:17,040 --> 00:27:22,040
‫D'accord?

557
00:27:24,500 --> 00:27:25,520
‫Et non

558
00:27:25,520 --> 00:27:30,207
‫modifié signifie essentiellement que le jour ou l'heure à laquelle le jeton a été

559
00:27:32,300 --> 00:27:34,240
‫émis est inférieur à l'horodatage modifié.

560
00:27:34,240 --> 00:27:37,893
‫D'accord?

561
00:27:40,280 --> 00:27:41,113
‫Donc, à titre d'exemple ici,

562
00:27:44,330 --> 00:27:45,830
‫disons que le jeton a été émis à l'instant 100.

563
00:27:45,830 --> 00:27:49,327
‫Mais ensuite, nous avons changé le mot de passe, disons, au temps 200.

564
00:27:50,460 --> 00:27:53,843
‫D'accord?

565
00:27:55,240 --> 00:27:56,073
‫Et donc, nous

566
00:27:56,073 --> 00:27:57,609
‫avons changé le mot de passe

567
00:27:57,609 --> 00:27:59,840
‫après l'émission du jeton, et donc, c'est maintenant vrai.

568
00:27:59,840 --> 00:28:01,940
‫D'accord?

569
00:28:01,940 --> 00:28:03,379
‫Et c'est exactement ce sur quoi nous

570
00:28:03,379 --> 00:28:04,810
‫voulons revenir ici, car faux

571
00:28:04,810 --> 00:28:06,910
‫signifie pas changé, et donc vrai, bien sûr, signifie changé.

572
00:28:06,910 --> 00:28:09,200
‫Et donc, c'est exactement ce que nous avons ici.

573
00:28:09,200 --> 00:28:11,980
‫Mais maintenant, disons que le mot de passe a été

574
00:28:11,980 --> 00:28:13,410
‫modifié pour la dernière

575
00:28:13,410 --> 00:28:15,810
‫fois à 200, mais ce n'est qu'après cela

576
00:28:15,810 --> 00:28:18,640
‫que nous avons émis le jeton, disons, à l'instant 300.

577
00:28:18,640 --> 00:28:21,260
‫Et donc, 300, moins de 200 ?

578
00:28:21,260 --> 00:28:23,660
‫Non, c'est faux.

579
00:28:23,660 --> 00:28:25,160
‫Et donc, nous retournons false, ce qui signifie encore une fois non modifié.

580
00:28:25,160 --> 00:28:29,200
‫Et donc, c'est pourquoi nous utilisons ce signe moins ici.

581
00:28:29,200 --> 00:28:32,720
‫D'accord?

582
00:28:32,720 --> 00:28:33,553
‫Revenons à notre contrôleur et utilisons-le réellement.

583
00:28:36,800 --> 00:28:41,800
‫Donc, si le mot de passe a réellement été modifié, eh bien,

584
00:28:45,480 --> 00:28:49,910
‫dans ce cas, nous voulons en fait une erreur.

585
00:28:49,910 --> 00:28:53,030
‫Alors revenez ensuite, encore une fois, une nouvelle AppError.

586
00:28:53,030 --> 00:28:57,623
‫Récemment...

587
00:29:02,970 --> 00:29:04,220
‫Veuillez vous reconnecter.

588
00:29:11,790 --> 00:29:13,620
‫D'accord.

589
00:29:13,620 --> 00:29:15,030
‫Et encore une fois, codez 401.

590
00:29:15,030 --> 00:29:18,363
‫D'accord.

591
00:29:19,770 --> 00:29:20,820
‫Encore une fois, cela

592
00:29:20,820 --> 00:29:23,220
‫retournera vrai si l'utilisateur a réellement changé son mot de passe.

593
00:29:23,220 --> 00:29:25,790
‫Et donc, si tout cela ici est vrai,

594
00:29:25,790 --> 00:29:28,540
‫eh bien, c'est exactement dans ce cas que nous

595
00:29:28,540 --> 00:29:30,600
‫voulons que cette erreur se produise.

596
00:29:30,600 --> 00:29:33,220
‫D'accord?

597
00:29:33,220 --> 00:29:34,820
‫C'était donc en fait la dernière étape.

598
00:29:34,820 --> 00:29:37,510
‫D'accord.

599
00:29:37,510 --> 00:29:38,952
‫Donc, fondamentalement, si le code peut aller jusqu'à

600
00:29:38,952 --> 00:29:41,030
‫la fin de ce code ici, alors seulement, la prochaine sera exécutée.

601
00:29:41,030 --> 00:29:45,410
‫Et puis, avec next, nous passons au gestionnaire de

602
00:29:45,410 --> 00:29:49,100
‫route suivant, ce qui signifie effectivement accorder l'accès

603
00:29:49,100 --> 00:29:51,470
‫à cette route protégée.

604
00:29:51,470 --> 00:29:52,783
‫Mettons ça ici.

605
00:29:53,750 --> 00:29:55,740
‫Accordez l'accès à la route protégée.

606
00:29:55,740 --> 00:30:00,740
‫D'accord?

607
00:30:02,340 --> 00:30:03,597
‫Parce que c'est vraiment tout ce que fait ensuite.

608
00:30:03,597 --> 00:30:05,310
‫Next nous amène au middleware

609
00:30:05,310 --> 00:30:08,070
‫suivant, qui est donc généralement le gestionnaire de route

610
00:30:08,070 --> 00:30:10,880
‫lui-même, donc celui qui renvoie les données qui étaient protégées.

611
00:30:10,880 --> 00:30:14,550
‫D'accord.

612
00:30:14,550 --> 00:30:15,383
‫Juste une dernière chose

613
00:30:15,383 --> 00:30:18,540
‫que nous voulons faire ici est de mettre en fait toutes les données utilisateur sur la demande.

614
00:30:18,540 --> 00:30:22,930
‫Nous pouvons donc simplement dire, req, donc demande, . user sera égal à

615
00:30:22,930 --> 00:30:27,100
‫freshUser.

616
00:30:27,100 --> 00:30:30,510
‫D'accord.

617
00:30:30,510 --> 00:30:31,343
‫Et encore une

618
00:30:31,343 --> 00:30:32,430
‫fois, bien sûr, le

619
00:30:32,430 --> 00:30:34,930
‫code n'atteint jamais ce point ici que si tout est correct.

620
00:30:34,930 --> 00:30:37,470
‫D'accord?

621
00:30:37,470 --> 00:30:38,303
‫Et donc, ceci

622
00:30:38,303 --> 00:30:40,710
‫ici pourrait alors être utile à un moment donné dans le futur.

623
00:30:40,710 --> 00:30:42,110
‫Super.

624
00:30:43,150 --> 00:30:43,983
‫Testons simplement cela une fois de plus.

625
00:30:43,983 --> 00:30:46,450
‫Et fondamentalement, ce changement est dans le passé maintenant.

626
00:30:46,450 --> 00:30:51,450
‫Et donc, ce jeton que nous avons ici, ou en

627
00:30:51,820 --> 00:30:53,840
‫fait, j'aurais pu

628
00:30:53,840 --> 00:30:56,890
‫réutiliser celui-ci au lieu de le réenregistrer.

629
00:30:56,890 --> 00:30:58,520
‫Mais de toute façon, ce jeton a

630
00:30:58,520 --> 00:31:00,500
‫été émis après le changement de mot de passe.

631
00:31:00,500 --> 00:31:02,344
‫Et donc, ce jeton devrait maintenant fonctionner.

632
00:31:02,344 --> 00:31:04,920
‫Alors reconnectons-nous et

633
00:31:04,920 --> 00:31:07,500
‫essayons avec ce jeton.

634
00:31:10,900 --> 00:31:13,203
‫Et en effet, nous avons accès.

635
00:31:18,020 --> 00:31:20,030
‫Passons maintenant à Compass pour modifier cette date.

636
00:31:20,030 --> 00:31:22,853
‫D'accord.

637
00:31:24,511 --> 00:31:26,010
‫Mettons-le un mois plus tard.

638
00:31:26,010 --> 00:31:27,657
‫Et donc, ce sera en fait

639
00:31:27,657 --> 00:31:30,780
‫dans le futur, donc du moins, dans mon futur quand j'enregistrerai cette vidéo.

640
00:31:30,780 --> 00:31:34,150
‫Bien sûr, vous le ferez plus tard.

641
00:31:34,150 --> 00:31:36,640
‫Et donc, pour tester cela, veuillez mettre cela dans votre futur.

642
00:31:36,640 --> 00:31:40,373
‫Donc dans le futur de la date où vous

643
00:31:41,420 --> 00:31:43,060
‫regardez cette vidéo.

644
00:31:43,060 --> 00:31:44,710
‫Donc, si je retourne

645
00:31:45,960 --> 00:31:50,960
‫maintenant à Postman et me reconnecte, d'accord, donc si je me reconnecte maintenant et

646
00:31:53,860 --> 00:31:56,430
‫essaie d'accéder à cette route, eh bien,

647
00:31:56,430 --> 00:31:58,710
‫ce jeton sera émis, essentiellement, après

648
00:31:58,710 --> 00:32:01,420
‫que le mot de passe ait été modifié.

649
00:32:01,420 --> 00:32:03,553
‫Ou en fait avant que le mot de passe n'ait été modifié.

650
00:32:08,680 --> 00:32:10,590
‫Alors, désolé pour cette confusion.

651
00:32:10,590 --> 00:32:12,610
‫Le mot de passe a donc été changé

652
00:32:12,610 --> 00:32:15,800
‫le 30 mai, mais ce token a été émis le 2 mai, et donc, avant.

653
00:32:15,800 --> 00:32:19,650
‫Donc, en gros, c'est maintenant comme si l'utilisateur avait changé son mot

654
00:32:19,650 --> 00:32:21,950
‫de passe après l'émission du jeton.

655
00:32:21,950 --> 00:32:25,880
‫Et donc, c'est exactement la situation où nous ne voulons pas donner accès

656
00:32:25,880 --> 00:32:27,341
‫à la route protégée.

657
00:32:27,341 --> 00:32:31,070
‫Et donc, cela devrait maintenant refléter cela.

658
00:32:31,070 --> 00:32:35,170
‫Et en effet, l'utilisateur a récemment changé de

659
00:32:35,170 --> 00:32:38,740
‫mot de passe, veuillez vous reconnecter.

660
00:32:38,740 --> 00:32:40,280
‫Super.

661
00:32:40,280 --> 00:32:41,240
‫Donc ça marche maintenant.

662
00:32:41,240 --> 00:32:42,953
‫Ainsi, notre middleware de protection est maintenant complètement implémenté.

663
00:32:43,870 --> 00:32:48,000
‫Débarrassons-nous simplement de cette console. connectez-vous ici.

664
00:32:48,000 --> 00:32:51,620
‫Je n'ai plus besoin de celui-là.

665
00:32:51,620 --> 00:32:53,820
‫Et bien.

666
00:32:53,820 --> 00:32:55,800
‫Alors récapitulons rapidement, et cette vidéo dure

667
00:32:55,800 --> 00:32:57,230
‫très longtemps, un peu

668
00:32:57,230 --> 00:32:59,520
‫plus longtemps que ce à quoi je m'attendais.

669
00:32:59,520 --> 00:33:01,330
‫Mais il est vraiment

670
00:33:01,330 --> 00:33:03,820
‫important de comprendre et d'expliquer comment

671
00:33:03,820 --> 00:33:06,700
‫tout cela fonctionne et pourquoi c'est important.

672
00:33:06,700 --> 00:33:07,810
‫Et donc, je préfère ça que de faire cette vidéo beaucoup plus courte.

673
00:33:07,810 --> 00:33:12,710
‫Bien sûr, je pourrais juste écrire le code, mais alors vous ne comprendriez pas vraiment

674
00:33:12,710 --> 00:33:14,127
‫ce qui se passe.

675
00:33:14,127 --> 00:33:17,330
‫Donc cette partie nous l'avons déjà compris.

676
00:33:17,330 --> 00:33:19,410
‫Ensuite, cette partie, je crois aussi,

677
00:33:19,410 --> 00:33:21,680
‫c'est donc là que la vérification se produit,

678
00:33:21,680 --> 00:33:24,060
‫donc essentiellement pour voir si la charge utile du

679
00:33:24,060 --> 00:33:26,570
‫jeton n'a pas été manipulée par un tiers malveillant.

680
00:33:26,570 --> 00:33:30,900
‫D'accord?

681
00:33:30,900 --> 00:33:31,733
‫Et puisque nous

682
00:33:31,733 --> 00:33:33,730
‫atteignons ensuite ce code ici, cela signifie que personne

683
00:33:33,730 --> 00:33:36,790
‫n'a modifié le jeton Web JSON et, par conséquent, nous pouvons obtenir un nouvel utilisateur.

684
00:33:36,790 --> 00:33:39,350
‫Donc, fondamentalement, nous pouvons obtenir l'utilisateur

685
00:33:39,350 --> 00:33:41,690
‫actuel, appelons-le en fait currentUser.

686
00:33:41,690 --> 00:33:43,650
‫Pourquoi pas?

687
00:33:43,650 --> 00:33:44,483
‫Alors ici, ici et aussi ici.

688
00:33:45,450 --> 00:33:47,993
‫D'accord?

689
00:33:49,670 --> 00:33:50,503
‫Nous pouvons donc obtenir le

690
00:33:50,503 --> 00:33:53,020
‫currentUser à partir de cet ID qui vient d'être décodé à partir de la charge utile.

691
00:33:53,020 --> 00:33:55,023
‫Maintenant, si l'utilisateur actuel n'existe pas, c'est

692
00:33:56,100 --> 00:33:58,260
‫donc ce que nous testons ici, eh bien,

693
00:33:58,260 --> 00:34:00,660
‫dans ce cas, nous ne voulons pas donner accès

694
00:34:00,660 --> 00:34:01,990
‫à la route

695
00:34:01,990 --> 00:34:04,290
‫et créer à la place cette nouvelle erreur.

696
00:34:04,290 --> 00:34:06,343
‫Mais si l'utilisateur existe, eh bien, nous

697
00:34:07,400 --> 00:34:08,870
‫arrivons au point numéro

698
00:34:08,870 --> 00:34:12,030
‫quatre, où nous vérifions ensuite si un changement de mot de

699
00:34:12,030 --> 00:34:15,060
‫passe s'est produit après l'émission du jeton, n'est-ce pas ?

700
00:34:15,060 --> 00:34:18,060
‫Et si c'est le cas, encore une fois, nous créons une nouvelle erreur.

701
00:34:18,060 --> 00:34:21,200
‫Et si ce n'est pas le cas, eh bien, nous

702
00:34:21,200 --> 00:34:22,720
‫allons jusqu'à la fin

703
00:34:22,720 --> 00:34:24,460
‫de la fonction middleware, où

704
00:34:24,460 --> 00:34:26,750
‫nous attribuons ensuite le currentUser à la requête. user afin que nous puissions ensuite l'utiliser

705
00:34:26,750 --> 00:34:30,640
‫dans une prochaine fonction middleware.

706
00:34:30,640 --> 00:34:33,860
‫D'accord?

707
00:34:33,860 --> 00:34:34,693
‫Car rappelez-vous,

708
00:34:34,693 --> 00:34:37,030
‫cet objet de requête, c'est celui qui voyage,

709
00:34:37,030 --> 00:34:38,950
‫en gros, de middleware en middleware.

710
00:34:38,950 --> 00:34:40,660
‫Et donc, si nous voulons transmettre

711
00:34:40,660 --> 00:34:42,330
‫des données d'un middleware au

712
00:34:42,330 --> 00:34:44,600
‫suivant, nous pouvons simplement mettre des éléments sur l'objet

713
00:34:44,600 --> 00:34:47,860
‫de requête, et ces données seront ensuite disponibles à un moment ultérieur.

714
00:34:47,860 --> 00:34:51,220
‫D'accord.

715
00:34:51,220 --> 00:34:52,053
‫Alors c'est tout.

716
00:34:52,053 --> 00:34:52,886
‫Il s'agit

717
00:34:52,886 --> 00:34:54,560
‫essentiellement d'un algorithme de protection de

718
00:34:54,560 --> 00:34:58,300
‫route très sophistiqué et très complet, mais je pense qu'il est vraiment important de

719
00:34:58,300 --> 00:34:59,740
‫le faire aussi bien que possible.

720
00:34:59,740 --> 00:35:02,820
‫Quoi qu'il en soit, je suis content de voir que vous êtes

721
00:35:02,820 --> 00:35:04,990
‫arrivé à la fin de cette grosse vidéo,

722
00:35:04,990 --> 00:35:07,050
‫et je vous verrai dans la prochaine.

