1
00:00:03,890 --> 00:00:11,670
Maintenant que nous avons compris l'authentification basée sur les jetons en utilisant les jetons Web JSON,

2
00:00:11,670 --> 00:00:16,035
et également compris les avantages de l'utilisation de cette approche.

3
00:00:16,035 --> 00:00:22,185
Le fait que nous construisons maintenant un serveur basé sur l'API Rest,

4
00:00:22,185 --> 00:00:24,420
dans ce cours, signifie que

5
00:00:24,420 --> 00:00:27,585
l'authentification basée sur le jeton Web JSON

6
00:00:27,585 --> 00:00:31,410
est le plus adapté pour ce serveur que nous construisons.

7
00:00:31,410 --> 00:00:40,585
Donc, mettons à jour notre serveur API Rest pour utiliser les jetons Web JSON dans cet exercice.

8
00:00:40,585 --> 00:00:45,755
Pour commencer à mettre à jour le serveur sur votre terminal,

9
00:00:45,755 --> 00:00:51,935
installons d'abord le jeton Web JSON et le module passeport JWT Node.

10
00:00:51,935 --> 00:00:56,445
Ainsi, à l'invite de type npm, installez,

11
00:00:56,445 --> 00:01:05,640
passeport JWT JSON Web Token et moins enregistrer.

12
00:01:05,640 --> 00:01:15,435
Comme vous pouvez le voir, j'utilise JSON Web Token 8.3.0 et passeport JWT 4.0.0 dans ce cours.

13
00:01:15,435 --> 00:01:23,180
Maintenant que nous avons terminé l'installation, continuons à mettre à jour notre serveur express.

14
00:01:23,180 --> 00:01:25,700
Aller maintenant à notre code,

15
00:01:25,700 --> 00:01:30,289
ajoutons un fichier nommé

16
00:01:30,289 --> 00:01:36,335
conflict.js dans le dossier racine de notre projet.

17
00:01:36,335 --> 00:01:39,455
Maintenant, ce fichier conflict.js, je vais l'utiliser

18
00:01:39,455 --> 00:01:43,220
pour stocker des informations de configuration pour notre serveur.

19
00:01:43,220 --> 00:01:49,790
Maintenant, c'est une façon de centraliser toute la configuration de notre serveur.

20
00:01:49,790 --> 00:01:53,600
Dans ce fichier conflict.js,

21
00:01:53,600 --> 00:01:59,825
permettez-moi d'exporter un objet JSON ici.

22
00:01:59,825 --> 00:02:02,490
Donc, nous allons dire, SecretKey,

23
00:02:08,510 --> 00:02:11,550
et c'est là que

24
00:02:19,450 --> 00:02:28,705
je vais spécifier la clé secrète que je vais utiliser pour signer mon jeton Web JSON,

25
00:02:28,705 --> 00:02:36,700
et aussi me laisser spécifier une URL Mongo ici,

26
00:02:36,700 --> 00:02:41,275
qui sera l'URL de

27
00:02:41,275 --> 00:02:51,710
mon serveur MongoDB localhost 27017.

28
00:02:52,200 --> 00:02:55,060
Une fois que nous avons terminé cela,

29
00:02:55,060 --> 00:02:59,260
alors nous allons aller au fichier authenticate.js,

30
00:02:59,260 --> 00:03:01,780
et dans le fichier authenticate.js, nous allons

31
00:03:01,780 --> 00:03:10,700
maintenant créer la stratégie JWT.

32
00:03:11,250 --> 00:03:16,175
C' est la stratégie de jeton web JSON qui est fournie par

33
00:03:16,175 --> 00:03:25,830
notre module de nœud JWT passeport que nous venons d'inclure et donc nous dirons, la

34
00:03:26,300 --> 00:03:32,895
stratégie de générativité passeport generativity.strategy.

35
00:03:32,895 --> 00:03:35,370
Cela nous fournira

36
00:03:35,370 --> 00:03:40,550
une stratégie basée sur JSON Web Token pour configurer notre module de passeport,

37
00:03:40,550 --> 00:03:46,820
puis extraire JWT, que je

38
00:03:46,820 --> 00:03:53,745
vais également obtenir de passeport JWT.

39
00:03:53,745 --> 00:03:55,935
Nous aurons besoin de passeport JWT,

40
00:03:55,935 --> 00:03:59,565
puis nous dirons « Extraire JWT ».

41
00:03:59,565 --> 00:04:02,655
Ensuite, nous allons importer

42
00:04:02,655 --> 00:04:10,240
le module JSON Web Token

43
00:04:10,240 --> 00:04:12,265
que nous venons d'installer.

44
00:04:12,265 --> 00:04:15,340
Une fois que nous les avons importés,

45
00:04:15,340 --> 00:04:18,370
continuons et commençons à configurer quelques choses.

46
00:04:18,370 --> 00:04:26,205
Avec ceux-ci, permettez-moi d'importer la configuration que j'ai

47
00:04:26,205 --> 00:04:35,840
créée le fichier config.js que je viens d'ajouter à mon projet.

48
00:04:35,840 --> 00:04:40,100
Une fois que j'ai terminé cela, laissez-moi aller de l'avant et

49
00:04:40,100 --> 00:04:45,650
introduire quelques fonctions supplémentaires que j'exporterai d'ici.

50
00:04:45,650 --> 00:04:49,200
Nous dirons, Exports.getToken,

51
00:04:55,160 --> 00:05:02,840
cette fonction lorsque nous fournissons un paramètre là que j'appellerai simplement l'utilisateur,

52
00:05:02,840 --> 00:05:06,335
qui sera un objet JSON,

53
00:05:06,335 --> 00:05:10,145
cela créera le jeton et le donnera pour nous.

54
00:05:10,145 --> 00:05:16,685
Pour créer le jeton, nous utiliserons le module jsonwebtoken que nous venons d'importer.

55
00:05:16,685 --> 00:05:22,140
Donc, ici, nous allons dire retour JWT.sign,

56
00:05:23,750 --> 00:05:31,355
cela nous aide à créer le jeton Web JSON et ainsi à l'intérieur qu'il

57
00:05:31,355 --> 00:05:34,430
me permettra de fournir la charge utile et

58
00:05:34,430 --> 00:05:38,825
la charge utile ici vient comme le paramètre ici appelé utilisateur,

59
00:05:38,825 --> 00:05:42,620
puis le deuxième paramètre est

60
00:05:42,620 --> 00:05:51,050
la clé secrète ou privée que je reçois de config. clé secrète,

61
00:05:51,050 --> 00:05:55,260
que je viens de configurer un peu plus tôt.

62
00:05:55,630 --> 00:06:02,835
Nous pouvons fournir des options supplémentaires ici.

63
00:06:02,835 --> 00:06:07,055
Une option que je vais fournir à ceci est...

64
00:06:07,055 --> 00:06:09,410
Ok, laissez-moi passer à la ligne suivante ici,

65
00:06:09,410 --> 00:06:14,160
l'option que je vais fournir est ExpiResin.

66
00:06:14,530 --> 00:06:20,945
Le ExpiResin vous dira combien de temps le jsonwebtoken sera

67
00:06:20,945 --> 00:06:27,185
valide donc dans ce cas, je dis 3,600, ce qui signifie 3,600 secondes ou environ une heure.

68
00:06:27,185 --> 00:06:32,825
Une heure plus tard, vous devrez renouveler le jsonwebtoken.

69
00:06:32,825 --> 00:06:36,790
Une heure est assez longue pour que nous puissions tester notre application.

70
00:06:36,790 --> 00:06:40,370
Vous pouvez définir ce paramètre pour être beaucoup plus long si vous le souhaitez.

71
00:06:40,370 --> 00:06:45,110
Dans une application réelle, vous pouvez définir cela pour être une valeur beaucoup plus longue peut-être

72
00:06:45,110 --> 00:06:50,075
quelques jours et vous attendre à ce que l'utilisateur se réauthentifie tous les quelques jours.

73
00:06:50,075 --> 00:06:52,670
Maintenant, nous allons également configurer

74
00:06:52,670 --> 00:06:58,025
la stratégie basée sur jsonwebtoken pour notre application de passeport.

75
00:06:58,025 --> 00:07:02,900
Donc, permettez-moi de déclarer une variable appelée opts,

76
00:07:02,900 --> 00:07:12,140
ce qui n'est rien d'autre que les options que je vais spécifier pour ma stratégie basée sur JWT.

77
00:07:12,140 --> 00:07:18,905
Donc, nous dirons opts JWTFromRequest.

78
00:07:18,905 --> 00:07:22,925
Maintenant, cette option spécifie

79
00:07:22,925 --> 00:07:28,580
comment le jsonwebtoken doit être extrait du message de demande entrante.

80
00:07:28,580 --> 00:07:33,755
C' est là que nous allons utiliser l'extrait JWT.

81
00:07:33,755 --> 00:07:39,290
Cet extrait JWT prend en charge diverses méthodes

82
00:07:39,290 --> 00:07:44,970
pour extraire des informations à partir de l'en-tête.

83
00:07:44,970 --> 00:07:49,580
Il dira de AuthHeader de AuthHeader comme jeton porteur,

84
00:07:49,580 --> 00:07:51,510
à partir de l'en-tête quel schéma et ainsi de suite.

85
00:07:51,510 --> 00:07:54,380
Si vous lisez la documentation, il

86
00:07:54,380 --> 00:07:58,040
vous dira différentes façons d'extraire le jsonwebtoken.

87
00:07:58,040 --> 00:08:00,770
Vous pouvez passer le jeton dans le corps

88
00:08:00,770 --> 00:08:04,970
du message de demande entrante et ensuite vous pouvez l'extraire à partir de là,

89
00:08:04,970 --> 00:08:08,255
vous pouvez également utiliser des extracteurs personnalisés et ainsi de suite.

90
00:08:08,255 --> 00:08:14,180
Dans ce cours, je vais utiliser la méthode la plus simple appelée

91
00:08:14,180 --> 00:08:20,745
à partir de l'en-tête d'authentification comme jeton de porteur.

92
00:08:20,745 --> 00:08:22,220
Nous sommes déjà familiers avec

93
00:08:22,220 --> 00:08:25,055
l'en-tête d'authentification parce que nous l'avons utilisé avec

94
00:08:25,055 --> 00:08:30,440
l'authentification de base et l'authentification basée sur les cookies plus tôt.

95
00:08:30,440 --> 00:08:32,180
Donc, je vais juste utiliser

96
00:08:32,180 --> 00:08:38,350
ce même champ d'en-tête dans le message de requête pour porter le jsonwebtoken.

97
00:08:38,350 --> 00:08:45,270
Donc, je vais dire opts comme jeton porteur jsonwebtoken.

98
00:08:45,270 --> 00:08:51,160
Le suivant, nous dirons Opts.SecretorKey,

99
00:08:56,980 --> 00:09:02,795
c'est le deuxième paramètre qui m'aide à

100
00:09:02,795 --> 00:09:11,670
fournir la clé secrète que je vais utiliser dans ma stratégie pour la connexion.

101
00:09:11,670 --> 00:09:15,875
Donc, c'est l'autre option que je vais spécifier ici.

102
00:09:15,875 --> 00:09:18,065
Une fois que je spécifie ces deux,

103
00:09:18,065 --> 00:09:26,390
permettez-moi d'exporter la stratégie Passport

104
00:09:26,390 --> 00:09:30,680
que je vais configurer ici pour dire ExportJWTPassport,

105
00:09:30,680 --> 00:09:34,355
puis nous dirons passeport.use.

106
00:09:34,355 --> 00:09:37,940
Rappelez-vous la façon dont vous avez spécifié la stratégie locale plus tôt.

107
00:09:37,940 --> 00:09:42,035
Ici, nous spécifions la stratégie basée sur JWT,

108
00:09:42,035 --> 00:09:47,895
puis nous allons créer une nouvelle stratégie JWT,

109
00:09:47,895 --> 00:09:51,320
rappelons que nous venons d'importer la stratégie JWT

110
00:09:51,320 --> 00:09:56,615
ici, c'est ce que nous allons utiliser pour créer une nouvelle stratégie.

111
00:09:56,615 --> 00:10:01,235
Cette stratégie JWT prend

112
00:10:01,235 --> 00:10:07,675
l'objet options que je viens de créer comme premier paramètre.

113
00:10:07,675 --> 00:10:14,210
Les options de stratégie et la seconde est la fonction de vérification que je dois fournir,

114
00:10:14,210 --> 00:10:18,050
et donc la fonction de vérification que je vais fournir dans la ligne suivante ici,

115
00:10:18,050 --> 00:10:28,545
nous allons dire FunctionJWT_PayLoad.

116
00:10:28,545 --> 00:10:33,900
Fait. Donc, lorsque cette fonction est appelée,

117
00:10:33,900 --> 00:10:39,270
le fait est le rappel qui est fourni par passeport.

118
00:10:39,270 --> 00:10:44,270
Ainsi, chaque fois que vous avez un passeport que vous configurez avec une nouvelle stratégie,

119
00:10:44,270 --> 00:10:46,750
vous devez fournir le deuxième paramètre fait.

120
00:10:46,750 --> 00:10:48,460
Grâce à ce paramètre fait,

121
00:10:48,460 --> 00:10:52,235
vous transmettrez des informations au passeport qu'il

122
00:10:52,235 --> 00:10:57,780
utilisera ensuite pour charger des choses sur le message de demande.

123
00:10:57,780 --> 00:11:00,710
Ainsi, lorsque passeport analyse le message de demande,

124
00:11:00,710 --> 00:11:04,110
il utilisera la stratégie, puis extraire des informations,

125
00:11:04,110 --> 00:11:09,540
puis la chargera sur notre message de demande.

126
00:11:09,540 --> 00:11:13,905
Donc, puisque cela se trouve être une fonction,

127
00:11:13,905 --> 00:11:19,795
je vais juste utiliser une fonction de flèche ici,

128
00:11:19,795 --> 00:11:22,160
j'ai aimé les fonctions de flèche.

129
00:11:22,160 --> 00:11:25,650
Donc, laissez-moi créer cela comme une fonction de flèche ici,

130
00:11:25,650 --> 00:11:28,345
et à l'intérieur de cette fonction,

131
00:11:28,345 --> 00:11:30,465
nous allons définir la fonction.

132
00:11:30,465 --> 00:11:32,970
Alors, que faisons-nous à l'intérieur de la fonction ?

133
00:11:32,970 --> 00:11:37,420
Laissez-moi faire un console.log de

134
00:11:38,370 --> 00:11:44,020
charge utile JWT et puis

135
00:11:44,660 --> 00:11:49,995
laissez-moi juste déconnecter l'option qui vient ici,

136
00:11:49,995 --> 00:11:51,770
l'option de charge utile JWT venir ici,

137
00:11:51,770 --> 00:11:55,420
afin que vous puissiez voir ce qui est à l'intérieur de la charge utile JWT.

138
00:11:55,420 --> 00:12:04,250
Ensuite, nous allons chercher un utilisateur en disant user.findone,

139
00:12:04,250 --> 00:12:14,020
et puis je sais que dans le jwt.payload,

140
00:12:14,020 --> 00:12:17,210
il y a un champ ID qui entre.

141
00:12:17,210 --> 00:12:21,360
Donc, c'est ce que je vais affecter comme champ ID ici.

142
00:12:21,360 --> 00:12:26,040
Donc, je dirai, user.findone et le second

143
00:12:26,040 --> 00:12:36,190
est une fonction de rappel.

144
00:12:36,870 --> 00:12:45,295
Comme vous vous rendez compte, cette méthode utilisateur Mongoose et vous essayez de trouver.

145
00:12:45,295 --> 00:12:54,665
Donc, nous dirons si erreur alors, retour fait.

146
00:12:54,665 --> 00:12:57,945
Qu' est-ce que cela a fait ? Ceci fait est le rappel que

147
00:12:57,945 --> 00:13:02,155
passeport passera dans votre stratégie ici.

148
00:13:02,155 --> 00:13:04,965
Donc, nous allons appeler cette fonction faite.

149
00:13:04,965 --> 00:13:11,200
Cela fait dans le passeport prend trois paramètres.

150
00:13:12,890 --> 00:13:20,400
Donc, vous pouvez voir les trois éléments d'information que cela fait attend il dit, erreur : any.

151
00:13:20,400 --> 00:13:24,525
Donc, si vous avez une erreur, vous la transmettrez comme premier paramètre.

152
00:13:24,525 --> 00:13:26,495
Le deuxième paramètre, l'utilisateur ? ,

153
00:13:26,495 --> 00:13:28,245
Si un utilisateur existe,

154
00:13:28,245 --> 00:13:33,770
alors la valeur de l'utilisateur sera transmise, puis si des informations ?  :, any.

155
00:13:33,770 --> 00:13:37,100
Donc, ces deux paramètres sont facultatifs et donc,

156
00:13:37,100 --> 00:13:38,690
si vous transmettez des informations,

157
00:13:38,690 --> 00:13:42,145
alors cela sera utilisé dans l'application.

158
00:13:42,145 --> 00:13:44,650
Si je transmets false comme deuxième paramètre,

159
00:13:44,650 --> 00:13:47,515
cela signifie que l'utilisateur n'existe pas ou cela.

160
00:13:47,515 --> 00:13:50,810
Donc, il interprétera que l'utilisateur n'existe pas.

161
00:13:50,810 --> 00:13:52,335
Donc, je pourrais dire, erreur,

162
00:13:52,335 --> 00:13:54,900
faux, parce que c'est une erreur.

163
00:13:54,900 --> 00:13:58,080
Donc, je ne vais pas passer une valeur utilisateur là,

164
00:13:58,080 --> 00:14:00,660
je vais juste passer faux.

165
00:14:00,660 --> 00:14:06,040
Là, le suivant,

166
00:14:06,040 --> 00:14:11,510
nous pouvons dire, sinon si (utilisateur).

167
00:14:11,510 --> 00:14:15,860
Donc, si l'utilisateur n'est pas nul,

168
00:14:15,860 --> 00:14:18,960
nous dirons retour fait (null). Il

169
00:14:19,230 --> 00:14:22,210
n'y a pas d'erreur donc, le premier paramètre sera

170
00:14:22,210 --> 00:14:25,080
nul et le second paramètre est l'utilisateur,

171
00:14:25,080 --> 00:14:29,895
mais nous venons de recevoir du MongoDB.

172
00:14:29,895 --> 00:14:35,445
Sinon, nous reviendrons

173
00:14:35,445 --> 00:14:41,395
fait avec null, false.

174
00:14:41,395 --> 00:14:43,650
Donc, dans le dernier cas,

175
00:14:43,650 --> 00:14:45,100
nous n'avons pas pu trouver l'utilisateur,

176
00:14:45,100 --> 00:14:47,120
donc nous allons passer faux.

177
00:14:47,120 --> 00:14:50,200
Donc, on va le gérer comme ça.

178
00:14:50,200 --> 00:14:53,345
Si vous le souhaitez, vous pouvez créer un nouveau compte d'utilisateur à ce stade,

179
00:14:53,345 --> 00:14:58,365
mais je vais garder cela simple juste pour que ce soit facile pour nous à comprendre.

180
00:14:58,365 --> 00:15:00,810
Donc, nous allons juste dire, nul, faux. Ça fait six.

181
00:15:00,810 --> 00:15:07,475
Donc, c'est la stratégie de passeport JSONWebToken que je viens de configurer ici.

182
00:15:07,475 --> 00:15:11,420
Aussi, permettez-moi d'exporter

183
00:15:11,420 --> 00:15:19,450
une fonction de plus à partir d'ici appelée verifyUser.

184
00:15:19,450 --> 00:15:21,110
Maintenant, cette fonction VerifyUser,

185
00:15:21,110 --> 00:15:24,935
je vais l'utiliser pour vérifier un utilisateur entrant.

186
00:15:24,935 --> 00:15:28,810
Donc, c'est là que j'utiliserai passeport.authenticate.

187
00:15:28,890 --> 00:15:36,440
Donc, le passeport.authenticate, la stratégie est la stratégie jwt que je viens de configurer,

188
00:15:36,440 --> 00:15:39,490
la stratégie JsonWebToken que je viens de configurer.

189
00:15:39,490 --> 00:15:41,625
Puis, la deuxième partie,

190
00:15:41,625 --> 00:15:46,305
je dirais, session : faux.

191
00:15:46,305 --> 00:15:47,740
Donc, cela signifie que,

192
00:15:47,740 --> 00:15:51,305
nous ne créerons pas de sessions dans ce cas.

193
00:15:51,305 --> 00:15:58,215
Comme vous vous souvenez, une application inverse,

194
00:15:58,215 --> 00:16:00,530
nous utilisons l'authentification basée sur des jetons.

195
00:16:00,530 --> 00:16:02,435
Donc, nous ne créerons pas de sessions.

196
00:16:02,435 --> 00:16:07,690
Donc, c'est pourquoi j'ai défini cette session d'option sur false ici

197
00:16:07,690 --> 00:16:11,795
, et bien sûr, la première a spécifié la stratégie que je vais utiliser.

198
00:16:11,795 --> 00:16:14,050
Donc, pour vérifier un utilisateur,

199
00:16:14,050 --> 00:16:15,930
j'utiliserai la stratégie JWT.

200
00:16:15,930 --> 00:16:18,110
Comment fonctionne la stratégie des JWT ?

201
00:16:18,110 --> 00:16:20,540
Dans la requête entrante,

202
00:16:21,040 --> 00:16:26,845
le jeton sera inclus dans l'en-tête d'authentification comme nous l'avons vu ici.

203
00:16:26,845 --> 00:16:29,950
Nous avons dit en-tête d'authentification comme jeton de porteur.

204
00:16:29,950 --> 00:16:33,530
Si cela est inclus, cela sera extrait et qui sera

205
00:16:33,530 --> 00:16:38,210
utilisé pour authentifier l'utilisateur en fonction du jeton.

206
00:16:38,210 --> 00:16:47,770
Correction mineure ici, cela devrait être user.findone_id est égal à jwt_payload. _id,

207
00:16:47,770 --> 00:16:56,475
car c'est la valeur id qui se trouve dans la charge utile de mon JSONWebToken.

208
00:16:56,475 --> 00:17:01,615
Donc, nous cherchons l'utilisateur avec cet ID donné.

209
00:17:01,615 --> 00:17:06,170
Donc, une fois que nous avons terminé cela, alors maintenant,

210
00:17:06,170 --> 00:17:11,790
la deuxième partie que nous devons faire est que nous devons créer le jeton quelque part.

211
00:17:11,790 --> 00:17:14,005
Maintenant, où créons-nous le jeton ?

212
00:17:14,005 --> 00:17:20,290
Donc, c'est là que quelque chose que nous faisons dans le fichier users.js est très utile pour nous.

213
00:17:20,290 --> 00:17:22,270
Dans le fichier users.js,

214
00:17:22,270 --> 00:17:27,180
rappelez-vous que vous avez déjà ce point de terminaison appelé login.

215
00:17:27,180 --> 00:17:28,700
Dans le point de terminaison de connexion,

216
00:17:28,700 --> 00:17:33,410
vous utilisiez le nom d'utilisateur et le mot de passe pour authentifier l'utilisateur.

217
00:17:33,410 --> 00:17:38,030
Ainsi, même avec le JSONWebToken pour émettre le JSONWebToken,

218
00:17:38,030 --> 00:17:41,959
vous devez d'abord authentifier l'utilisateur en utilisant l'une des autres stratégies,

219
00:17:41,959 --> 00:17:44,630
et si vous allez d'abord utiliser la stratégie locale,

220
00:17:44,630 --> 00:17:49,715
nous authentifierons l'utilisateur en utilisant le nom d'utilisateur et le mot de passe.

221
00:17:49,715 --> 00:17:53,415
Une fois que l'utilisateur est authentifié avec le nom d'utilisateur et le mot de

222
00:17:53,415 --> 00:17:55,885
passe, nous émettrons le jeton à l'utilisateur en disant :

223
00:17:55,885 --> 00:17:57,330
« Ok, vous êtes un utilisateur valide,

224
00:17:57,330 --> 00:17:58,630
je vais vous donner le jeton ».

225
00:17:58,630 --> 00:18:02,390
Toutes les requêtes suivantes porteront simplement le jeton

226
00:18:02,390 --> 00:18:06,860
dans l'en-tête du message de demande entrante.

227
00:18:06,860 --> 00:18:10,415
Donc, plus tôt, nous avions l'habitude de créer des sessions.

228
00:18:10,415 --> 00:18:11,840
Lorsque l'utilisateur est authentifié,

229
00:18:11,840 --> 00:18:13,935
nous n'utiliserons plus de sessions.

230
00:18:13,935 --> 00:18:17,640
Au lieu de cela, lorsque l'utilisateur est authentifié à l'aide de la stratégie locale,

231
00:18:17,640 --> 00:18:20,110
nous émettons un jeton à l'utilisateur.

232
00:18:20,110 --> 00:18:25,955
Donc, à l'intérieur de cette méthode router.post que nous avons fait sur ce point de terminaison /login,

233
00:18:25,955 --> 00:18:31,730
je vais créer un jeton et transmettre ce jeton à l'utilisateur.

234
00:18:31,730 --> 00:18:36,980
Donc, ici, nous allons dire un router.post.

235
00:18:38,550 --> 00:18:40,785
Laissez-moi créer un jeton.

236
00:18:40,785 --> 00:18:42,630
Pour créer un jeton,

237
00:18:42,630 --> 00:18:50,150
nous avons cette fonction dans le module d'authentification appelé Authenticate.GetToken.

238
00:18:51,250 --> 00:18:54,325
Donc, rappelez-vous, que nous avons déjà,

239
00:18:54,325 --> 00:18:57,050
pour faire usage de cela bien sûr,

240
00:18:57,050 --> 00:18:59,210
même avant que nous commencions là,

241
00:18:59,210 --> 00:19:02,750
je dois importer l'authentification.

242
00:19:05,940 --> 00:19:17,720
Module ici. Donc, nous allons dire Authenticate require. /authentifier.

243
00:19:18,000 --> 00:19:26,740
Donc, alors, quand dans votre code ici,

244
00:19:26,740 --> 00:19:29,270
nous pouvons maintenant dire Authenticate.getToken,

245
00:19:31,530 --> 00:19:37,585
et le getToken prend le paramètre ici.

246
00:19:37,585 --> 00:19:41,875
Maintenant, rappelez-vous, revenant au fichier authenticate.js.

247
00:19:41,875 --> 00:19:46,665
Le fichier authenticate.js prend ici un paramètre

248
00:19:46,665 --> 00:19:53,105
qui sera utilisé comme charge utile lorsque vous créez le JSONWebToken.

249
00:19:53,105 --> 00:19:55,785
Donc, dans le fichier users.js,

250
00:19:55,785 --> 00:19:59,230
je vais créer un jeton en donnant une charge utile,

251
00:19:59,230 --> 00:20:02,890
qui ne contient que l'ID de l'utilisateur.

252
00:20:02,890 --> 00:20:06,070
Donc, nous allons dire id : req.user. _id.

253
00:20:06,740 --> 00:20:11,940
C'est suffisant pour créer le JSONWebToken.

254
00:20:11,940 --> 00:20:15,315
Nous ne voulons pas inclure d'autres informations de l'utilisateur.

255
00:20:15,315 --> 00:20:18,690
Si vous choisissez, vous pouvez inclure d'autres parties des informations de l'utilisateur,

256
00:20:18,690 --> 00:20:21,715
mais je suggère que garder le JsonWebToken petit.

257
00:20:21,715 --> 00:20:25,700
L' ID utilisateur est suffisant car si vous avez besoin de rechercher l'utilisateur,

258
00:20:25,700 --> 00:20:32,840
l'ID utilisateur est suffisant pour rechercher l'utilisateur dans MongoDB.

259
00:20:32,840 --> 00:20:39,230
Donc, je vais juste encoder seulement l'ID de l'utilisateur ici.

260
00:20:39,230 --> 00:20:44,930
Maintenant, vous savez que req.user serait déjà présent,

261
00:20:44,930 --> 00:20:50,530
car lorsque passeport.authenticate ('local') authentifie l'utilisateur avec succès,

262
00:20:50,530 --> 00:20:54,650
cela va charger la propriété utilisateur sur le message de requête.

263
00:20:54,650 --> 00:20:57,300
Donc, c'est pour ça que je suis capable de faire ça ici.

264
00:20:57,300 --> 00:21:01,830
Donc, c'est ce que je vais utiliser pour créer le jeton.

265
00:21:01,900 --> 00:21:05,120
Maintenant, une fois le jeton créé,

266
00:21:05,120 --> 00:21:09,720
je veux transmettre ce jeton à l'utilisateur.

267
00:21:09,720 --> 00:21:15,715
Donc, dans l'objet rest.json que je fournis ici,

268
00:21:15,715 --> 00:21:21,755
je porte déjà le drapeau vrai succès et aussi,

269
00:21:21,755 --> 00:21:23,855
un message d'état ici.

270
00:21:23,855 --> 00:21:28,270
Permettez-moi d'ajouter le jeton

271
00:21:28,270 --> 00:21:34,880
comme l'une des propriétés dans le message de réponse ici.

272
00:21:36,480 --> 00:21:39,475
Donc, le jeton que je viens de créer,

273
00:21:39,475 --> 00:21:47,595
je vais le passer comme deuxième propriété à l'intérieur de cette chaîne Json ici.

274
00:21:47,595 --> 00:21:55,370
Donc maintenant, lorsque mon client reçoit cette chaîne Json dans le corps du message de réponse,

275
00:21:55,370 --> 00:21:59,870
il peut entrer et extraire le jeton de là.

276
00:22:00,140 --> 00:22:05,500
C' est ça. Donc, nous avons maintenant mis à jour le fichier users.js,

277
00:22:05,500 --> 00:22:08,630
et vous pouvez maintenant voir comment le jeton sera

278
00:22:08,630 --> 00:22:12,690
créé et renvoyé à l'utilisateur lorsque l'utilisateur est authentifié avec succès.

279
00:22:12,690 --> 00:22:16,330
Maintenant, ce schéma peut également être utilisé

280
00:22:16,330 --> 00:22:21,250
lorsque vous utilisez une authentification tierce comme basée sur OAuth 2.0,

281
00:22:21,250 --> 00:22:23,525
que nous allons examiner dans le module suivant.

282
00:22:23,525 --> 00:22:25,695
Maintenant, la procédure sera similaire.

283
00:22:25,695 --> 00:22:28,880
Vous allez créer un jeton lorsque l'utilisateur est authentifié par

284
00:22:28,880 --> 00:22:32,560
le fournisseur d'authentification tiers ou OAuth,

285
00:22:32,560 --> 00:22:35,640
puis vous transmettrez le jeton à l'utilisateur,

286
00:22:35,640 --> 00:22:39,010
dans une approche similaire à celle que vous voyez ici.

287
00:22:39,010 --> 00:22:41,285
Maintenant, une fois que nous avons fait cela,

288
00:22:41,285 --> 00:22:44,255
alors nous allons au fichier app.js.

289
00:22:44,255 --> 00:22:53,660
Dans le fichier app.js, parce que nous avons inclus un fichier de configuration ici.

290
00:22:53,660 --> 00:22:59,005
Donc, laissez-moi exiger le fichier de configuration ici,

291
00:22:59,005 --> 00:23:06,465
puis l'URL que j'utilise ici au lieu de coder cette URL,

292
00:23:06,465 --> 00:23:11,345
je dirai Config.Mongourl.

293
00:23:11,345 --> 00:23:16,680
Donc, maintenant, vous voyez comment mon fichier config.js peut être utilisé comme

294
00:23:16,680 --> 00:23:23,520
un endroit centralisé où je peux préparer la configuration pour mon application.

295
00:23:23,520 --> 00:23:29,200
C' est ça. Donc, ce qui se passe maintenant, c'est que lorsque l'utilisateur

296
00:23:29,200 --> 00:23:35,010
s'authentifie sur le point de terminaison /login et que l'utilisateur est authentifié avec succès,

297
00:23:35,010 --> 00:23:40,840
le jeton sera créé par le serveur et renvoyé au client ou à l'utilisateur.

298
00:23:40,840 --> 00:23:43,765
Ainsi, le client inclura le jeton dans

299
00:23:43,765 --> 00:23:47,765
chaque demande entrante suivante dans l'en-tête d'autorisation.

300
00:23:47,765 --> 00:23:50,590
Maintenant, comment inclue-t-il l'en-tête d'autorisation ?

301
00:23:50,590 --> 00:23:54,220
Revenons à authentic.js et ici,

302
00:23:54,220 --> 00:24:01,625
vous voyez que nous avons dit extractJWt.FromAuthHeaderAsBearerToken ici.

303
00:24:01,625 --> 00:24:06,290
Ainsi, cela sera inclus dans l'en-tête d'authentification en tant que jeton de porteur.

304
00:24:06,290 --> 00:24:08,385
Je vais vous montrer comment cela est fait,

305
00:24:08,385 --> 00:24:15,535
puis nous utilisons le facteur pour inclure le jeton porteur dans l'en-tête d'authentification.

306
00:24:15,535 --> 00:24:17,690
Maintenant, quand cela arrive,

307
00:24:17,690 --> 00:24:21,060
alors vous vous rappelez que juste en bas ici,

308
00:24:21,060 --> 00:24:25,095
vous avez configuré cette méthode ici appelée VerifyUser,

309
00:24:25,095 --> 00:24:30,635
qui fait appel à l'authentification du passeport avec JWT.

310
00:24:30,635 --> 00:24:34,460
Donc, celui-ci utilise le jeton qui

311
00:24:34,460 --> 00:24:38,620
vient dans l'en-tête d'authentification, puis vérifie l'utilisateur.

312
00:24:38,620 --> 00:24:41,980
Donc, chaque fois que je veux vérifier l'authenticité de l'utilisateur,

313
00:24:41,980 --> 00:24:43,855
je peux simplement appeler check user,

314
00:24:43,855 --> 00:24:49,115
et cela va lancer l'appel au passeport.authenticate et vérifier le sser.

315
00:24:49,115 --> 00:24:50,315
Si cela réussit,

316
00:24:50,315 --> 00:24:51,800
cela me permettra de poursuivre.

317
00:24:51,800 --> 00:24:55,620
Cette procédure est très similaire à ce que vous avez fait dans le

318
00:24:55,620 --> 00:25:01,610
fichier users.js où vous appelez le même passeport.authenticate ('local').

319
00:25:01,720 --> 00:25:04,320
Donc, si cela réussit,

320
00:25:04,320 --> 00:25:05,885
alors vous allez de l'avant.

321
00:25:05,885 --> 00:25:10,930
Si elle échoue, la fonction d'authentification renvoie le message d'erreur

322
00:25:10,930 --> 00:25:16,050
au client indiquant que l'utilisateur n'est pas autorisé.

323
00:25:16,050 --> 00:25:18,345
Donc, c'est déjà pris en charge.

324
00:25:18,345 --> 00:25:23,020
Donc maintenant, que nous avons inclus ceci dans mon fichier authenticate.js,

325
00:25:23,020 --> 00:25:26,050
n'importe quel endroit que je veux vérifier l'utilisateur,

326
00:25:26,050 --> 00:25:27,480
je peux simplement appeler

327
00:25:27,480 --> 00:25:31,210
cette fonction VerifyUser que

328
00:25:31,210 --> 00:25:34,320
j'ai spécifiée ici ou l'exportation que j'ai spécifiée ici,

329
00:25:34,320 --> 00:25:37,220
que nous allons appeler passeport.authenticate en utilisant

330
00:25:37,220 --> 00:25:40,540
la stratégie JWT pour authentifier l'utilisateur.

331
00:25:40,540 --> 00:25:42,440
Maintenant, comment on utilise ça ?

332
00:25:42,440 --> 00:25:47,785
Maintenant, ce que nous allons faire, c'est nous allons aller dans chacun de nos routeurs,

333
00:25:47,785 --> 00:25:56,945
et contrôler les options sur toutes les routes que nous voulons contrôler.

334
00:25:56,945 --> 00:26:00,300
Donc, revenant au fichier app.js, maintenant,

335
00:26:00,300 --> 00:26:07,925
que nous n'utilisons pas de sessions, je vais supprimer cette session d'ici,

336
00:26:07,925 --> 00:26:10,150
parce que nous n'utilisons plus de sessions.

337
00:26:10,150 --> 00:26:14,990
De même, je vais supprimer ce passeport.session d'ici aussi.

338
00:26:14,990 --> 00:26:17,580
Ce n'est pas non plus nécessaire.

339
00:26:17,580 --> 00:26:20,430
En outre, cette authentification, voir plus tôt,

340
00:26:20,430 --> 00:26:21,940
lorsque j'ai configuré cette authentification,

341
00:26:21,940 --> 00:26:25,490
cette authentification a été appliquée à chaque requête entrante unique.

342
00:26:25,490 --> 00:26:28,705
Maintenant, je vais changer mon application, de

343
00:26:28,705 --> 00:26:35,055
sorte que je ne demanderai l'authentification que sur certaines routes et pas sur toutes les routes.

344
00:26:35,055 --> 00:26:39,665
Donc, laissez-moi supprimer complètement cette authentification de app.js.

345
00:26:39,665 --> 00:26:41,995
Donc, maintenant, lorsque la requête arrive,

346
00:26:41,995 --> 00:26:45,850
si elle est sur /point de terminaison,

347
00:26:45,850 --> 00:26:47,080
l'index sera servi.

348
00:26:47,080 --> 00:26:52,040
S' il est sur le point de terminaison /users, il vous permettra de naviguer vers

349
00:26:52,040 --> 00:26:57,815
les différentes routes qui sont montées sur les /users dans le fichier users.js

350
00:26:57,815 --> 00:27:00,900
, puis par la suite, les autres.

351
00:27:00,900 --> 00:27:03,420
Ce que je vais faire maintenant, c'est que je vais laisser

352
00:27:03,420 --> 00:27:07,250
le dossier public ouvert pour que tout le monde puisse y accéder.

353
00:27:07,250 --> 00:27:09,145
Maintenant, dans de nombreuses applications,

354
00:27:09,145 --> 00:27:10,665
cela peut être très bien.

355
00:27:10,665 --> 00:27:13,045
Donc, je vais laisser ça ouvert.

356
00:27:13,045 --> 00:27:14,825
Maintenant, sur les plats, les

357
00:27:14,825 --> 00:27:17,920
promotions, et le point de terminaison des leaders,

358
00:27:17,920 --> 00:27:20,875
Toutes les demandes get.

359
00:27:20,875 --> 00:27:28,205
Je laisserai ces réponses sans nécessiter d'authentification.

360
00:27:28,205 --> 00:27:30,200
Pourquoi voudrais-je faire ça ?

361
00:27:30,200 --> 00:27:33,190
Si un utilisateur fait une demande get,

362
00:27:33,190 --> 00:27:35,455
il veut juste récupérer des informations.

363
00:27:35,455 --> 00:27:40,490
Donc, par exemple, du côté client si j'implémente une application Web en utilisant Angular

364
00:27:40,490 --> 00:27:49,920
ou une application cliente en utilisant

365
00:27:49,920 --> 00:27:54,310
un script ionique ou natif, alors peut-être que je veux implémenter mon application de telle sorte que la page principale affiche déjà des informations,

366
00:27:54,310 --> 00:27:57,715
les informations génétiques que vous voulez mettre à la disposition de toute personne qui

367
00:27:57,715 --> 00:28:01,590
visite votre site Web ou qui ouvre votre application.

368
00:28:01,590 --> 00:28:04,360
Ainsi, les informations de base peuvent être affichées là.

369
00:28:04,360 --> 00:28:08,060
Mais si vous voulez changer quoi que ce soit,

370
00:28:08,060 --> 00:28:12,110
vous vous attendez à ce que l'utilisateur soit authentifié.

371
00:28:12,110 --> 00:28:16,255
Ainsi, vous autorisez les opérations POST, les opérations de mise

372
00:28:16,255 --> 00:28:21,110
et les opérations de suppression à effectuer uniquement par des utilisateurs authentifiés.

373
00:28:21,110 --> 00:28:23,605
De même, pour les commentaires par exemple,

374
00:28:23,605 --> 00:28:30,280
vous pouvez dire que les commentaires ne peuvent être publiés ou modifiés que par des utilisateurs authentifiés.

375
00:28:30,280 --> 00:28:34,570
Ainsi, vous pouvez restreindre uniquement certaines routes pour les utilisateurs authentifiés,

376
00:28:34,570 --> 00:28:37,940
l'autre route que vous pouvez laisser ouverte. Comment on fait ça ?

377
00:28:37,940 --> 00:28:41,180
Maintenant, c'est là que l'utilisateur de vérification que nous

378
00:28:41,180 --> 00:28:45,055
avons exporté à partir du fichier authenticate.js est utile.

379
00:28:45,055 --> 00:28:49,460
Maintenant, au lieu de contrôler tous les points de fin,

380
00:28:49,460 --> 00:28:53,190
toutes les différentes opérations sur les plats, promotions

381
00:28:53,190 --> 00:28:54,740
et leaders en points,

382
00:28:54,740 --> 00:28:58,240
nous n'ouvrirons que les opérations get pour n'importe qui

383
00:28:58,240 --> 00:29:00,830
, mais les

384
00:29:00,830 --> 00:29:04,995
opérations post, put et delete seront limitées aux utilisateurs authentifiés.

385
00:29:04,995 --> 00:29:10,350
Dans l'affectation, vous allez ajouter une catégorie supplémentaire d'utilisateurs appelés utilisateurs admin.

386
00:29:10,350 --> 00:29:15,320
Maintenant, vous limiteriez certaines opérations à effectuer uniquement par les utilisateurs admin.

387
00:29:15,320 --> 00:29:18,460
Ainsi, par exemple, la modification des plats

388
00:29:18,460 --> 00:29:22,530
ou la suppression des informations de vaisselle de la base de données,

389
00:29:22,530 --> 00:29:24,600
sera limitée uniquement aux utilisateurs administrateurs.

390
00:29:24,600 --> 00:29:30,000
Mais les utilisateurs de base peuvent poster des commentaires,

391
00:29:30,000 --> 00:29:32,470
modifier les commentaires qu'ils ont postés,

392
00:29:32,470 --> 00:29:35,450
et peut-être même enregistrer certains plats préférés.

393
00:29:35,450 --> 00:29:38,520
Nous ferons cette partie dans le quatrième module.

394
00:29:38,520 --> 00:29:42,735
Maintenant, comment contrôlons-nous des itinéraires spécifiques ?

395
00:29:42,735 --> 00:29:46,210
C' est donc là que nous devons aller dans chacun des routeurs

396
00:29:46,210 --> 00:29:50,365
, puis importer des contrôles sur des routes spécifiques.

397
00:29:50,365 --> 00:29:53,945
Alors, commençons par la route de la vaisselle.

398
00:29:53,945 --> 00:29:55,770
Donc, pour la route des plats,

399
00:29:55,770 --> 00:29:59,950
vous vous souviendrez que cela est contrôlé dans le fichier dishRouter.js.

400
00:29:59,950 --> 00:30:02,515
Donc, en allant à dishRouter.js,

401
00:30:02,515 --> 00:30:07,450
nous allons d'abord importer l'authentification ici.

402
00:30:07,450 --> 00:30:13,400
Donc, nous allons dire, const authenticate

403
00:30:17,010 --> 00:30:24,700
require../authenticate parce que ce

404
00:30:24,700 --> 00:30:29,110
fichier authenticator.js est dans le dossier de niveau supérieur.

405
00:30:29,110 --> 00:30:32,105
Alors, rappelez-vous../authentifiez-vous ici.

406
00:30:32,105 --> 00:30:34,505
Donc, une fois que vous importez l'authentification,

407
00:30:34,505 --> 00:30:37,965
pour la route du routeur plat pour cette route

408
00:30:37,965 --> 00:30:42,560
, l'opération get, je vais autoriser sans aucun problème.

409
00:30:42,560 --> 00:30:44,820
Donc, c'est ouvert.

410
00:30:44,820 --> 00:30:47,025
Donc, je n'imposerai aucune restriction.

411
00:30:47,025 --> 00:30:51,750
A partir du post, si nous voulons appliquer plusieurs middleware,

412
00:30:51,750 --> 00:30:56,035
nous pouvons simplement ajouter le principal à l'intérieur de celui-ci derrière l'autre.

413
00:30:56,035 --> 00:30:58,050
Maintenant, quand le post est appelé, en ce

414
00:30:58,050 --> 00:31:02,295
moment, vous exécutez simplement cette fonction ici.

415
00:31:02,295 --> 00:31:04,150
Maintenant, juste avant cela,

416
00:31:04,150 --> 00:31:12,400
je peux aller et dire, Authenticate.VerifyUser, là.

417
00:31:12,400 --> 00:31:13,805
Alors, qu'est-ce que ça fait ?

418
00:31:13,805 --> 00:31:17,210
Cela dit que si une demande de poste arrive,

419
00:31:17,210 --> 00:31:20,940
j'exécuterais d'abord ce middleware, que

420
00:31:20,940 --> 00:31:24,805
j'ai exporté à partir du fichier authentic.js,

421
00:31:24,805 --> 00:31:26,100
j'applique d'abord cela,

422
00:31:26,100 --> 00:31:32,075
ce qui équivaut à dire passeport authentifier JWT et vous vérifiez l'utilisateur.

423
00:31:32,075 --> 00:31:34,655
Ensuite, si cela réussit,

424
00:31:34,655 --> 00:31:38,890
alors je passerai à faire le reste.

425
00:31:38,890 --> 00:31:42,955
Si l'authentification échoue à ce stade

426
00:31:42,955 --> 00:31:46,290
, Passport Authenticate

427
00:31:46,290 --> 00:31:49,395
répondra au client avec le message d'erreur approprié.

428
00:31:49,395 --> 00:31:51,640
Donc, cela est déjà géré par passeport authentifier,

429
00:31:51,640 --> 00:31:54,350
donc je n'ai pas à m'inquiéter quoi que ce soit au-delà de ce point.

430
00:31:54,350 --> 00:31:58,300
Si j'ai traversé ce middleware et puis j'arrive à

431
00:31:58,300 --> 00:32:02,990
exécuter la fonction suivante, cela signifie que mon authentification a réussi,

432
00:32:02,990 --> 00:32:05,560
donc je suis capable de poursuivre à partir de ce point.

433
00:32:05,560 --> 00:32:11,760
Donc, cela agit comme la barrière pour cette méthode de post.

434
00:32:11,760 --> 00:32:14,860
Maintenant, en utilisant le même argument,

435
00:32:14,860 --> 00:32:21,435
je peux simplement appliquer ce middleware particulier à toutes les autres méthodes.

436
00:32:21,435 --> 00:32:23,845
Je peux le faire à la vente.

437
00:32:23,845 --> 00:32:26,030
Bien que dans ce cas,

438
00:32:26,030 --> 00:32:28,640
mettre ne va pas faire quoi que ce soit.

439
00:32:28,640 --> 00:32:30,110
Mais en tout cas,

440
00:32:30,110 --> 00:32:33,980
je vais simplement par souci d'uniformité,

441
00:32:33,980 --> 00:32:38,490
je vais appliquer l'utilisateur de vérification à mettre également et bien sûr,

442
00:32:38,490 --> 00:32:41,315
pour supprimer aussi, je vais appliquer mettre.

443
00:32:41,315 --> 00:32:44,805
De même, en descendant à /dishid,

444
00:32:44,805 --> 00:32:48,915
je vais permettre que cela fonctionne sans aucun problème.

445
00:32:48,915 --> 00:32:52,470
Poster, je vais appliquer l'utilisateur de vérification.

446
00:32:52,470 --> 00:32:59,600
Mettez aussi je vais appliquer l'utilisateur de vérification et pour supprimer aussi même.

447
00:32:59,600 --> 00:33:09,105
Pour les /dishid/comments, je vais laisser le get open,

448
00:33:09,105 --> 00:33:14,030
c'est correct pour tout le monde de récupérer des commentaires sur un plat spécifique.

449
00:33:14,030 --> 00:33:17,140
Poster, je vais fermer ceci,

450
00:33:17,140 --> 00:33:21,995
donc seuls les utilisateurs vérifiés peuvent poster des commentaires.

451
00:33:21,995 --> 00:33:27,710
Mettez aussi je fermerai cela et supprimerai aussi.

452
00:33:29,280 --> 00:33:33,035
Vous devez aller un peu plus loin et dire,

453
00:33:33,035 --> 00:33:38,230
« Seuls les utilisateurs qui ont posté le commentaire peuvent supprimer leurs propres messages. »

454
00:33:38,230 --> 00:33:40,310
Mais nous le ferons dans le prochain module.

455
00:33:40,310 --> 00:33:41,840
Pour le moment, je vais dire,

456
00:33:41,840 --> 00:33:44,415
« Ok, un utilisateur vérifié peut supprimer n'importe quel commentaire. »

457
00:33:44,415 --> 00:33:46,715
Ce n'est bien sûr pas vrai,

458
00:33:46,715 --> 00:33:48,850
nous pouvons mettre un contrôle supplémentaire,

459
00:33:48,850 --> 00:33:52,145
mais nous le ferons dans le prochain module de ce cours.

460
00:33:52,145 --> 00:33:54,405
Donc, pour supprimer aussi j'applique la même chose.

461
00:33:54,405 --> 00:33:58,060
Encore une fois, pour le routeur de plat commentaires/commentaires Id,

462
00:33:58,060 --> 00:34:00,300
obtenez je vais le laisser ouvert.

463
00:34:00,300 --> 00:34:04,485
Post, je vais le laisser fermé.

464
00:34:04,485 --> 00:34:12,640
Mettez aussi fermez-le et puis pour supprimer aussi je fermerai cela.

465
00:34:12,640 --> 00:34:14,970
Supprimer bien sûr, comme je

466
00:34:14,970 --> 00:34:19,180
l'ai dit, l'opération de suppression devrait être autorisée seulement un utilisateur qui

467
00:34:19,180 --> 00:34:24,150
a créé le commentaire devrait être invité à le supprimer,

468
00:34:24,150 --> 00:34:27,960
mais vous devez mettre en place quelques choses supplémentaires pour que cela fonctionne correctement,

469
00:34:27,960 --> 00:34:30,825
ce que nous allons faire dans le module suivant.

470
00:34:30,825 --> 00:34:36,455
Pour le moment, nous disons qu'un utilisateur vérifié peut supprimer un commentaire spécifique, c'est tout.

471
00:34:36,455 --> 00:34:42,820
Maintenant, nous allons appliquer le même principe au routeur promo et aussi au routeur leader.

472
00:34:42,820 --> 00:34:44,950
Donc, aller dans le routeur promo,

473
00:34:44,950 --> 00:34:53,100
laissez-moi importer authentifier

474
00:34:57,320 --> 00:35:00,870
et puis obtenir est ouvert,

475
00:35:00,870 --> 00:35:03,540
donc c'est le routeur leader.

476
00:35:03,540 --> 00:35:05,380
Donc, obtenir est ouvert.

477
00:35:05,380 --> 00:35:08,365
Post, Je vais contrôler que,

478
00:35:08,365 --> 00:35:12,865
mettre, contrôler, supprimer, contrôler,

479
00:35:12,865 --> 00:35:14,790
routeur de leader, ID de leader,

480
00:35:14,790 --> 00:35:17,255
get est ok, post,

481
00:35:17,255 --> 00:35:22,330
contrôlé, mettre est contrôlé et supprimer est contrôlé.

482
00:35:22,330 --> 00:35:24,795
Même chose avec le routeur promo.

483
00:35:24,795 --> 00:35:38,652
Laissez-moi, exiger l'authentification

484
00:35:38,652 --> 00:35:43,570
et puis pour la route get est ouvert,

485
00:35:43,570 --> 00:35:47,109
POST est contrôlé, mis est contrôlé,

486
00:35:47,109 --> 00:35:50,790
delete est contrôlé, la même chose pour le Promorouter/PromoID.

487
00:35:50,790 --> 00:35:54,460
Get est ouvert, POST est contrôlé,

488
00:35:54,460 --> 00:35:58,395
mettre et supprimer sont également contrôlés, c'est tout.

489
00:35:58,395 --> 00:36:00,225
Sauvegardons tous les changements.

490
00:36:00,225 --> 00:36:02,660
Donc, une fois que nous avons terminé toutes les modifications,

491
00:36:02,660 --> 00:36:04,185
sauvegardons les modifications.

492
00:36:04,185 --> 00:36:08,270
Maintenant, notre application est prête à être testée.

493
00:36:08,270 --> 00:36:11,485
Donc, allons redémarrer notre serveur,

494
00:36:11,485 --> 00:36:14,885
ou si le serveur n'est pas en cours d'exécution,

495
00:36:14,885 --> 00:36:16,590
nous allons juste démarrer le serveur.

496
00:36:16,590 --> 00:36:18,770
En allant au terminal,

497
00:36:18,770 --> 00:36:20,040
mon serveur n'est pas en cours d'exécution.

498
00:36:20,040 --> 00:36:23,930
Donc, laissez-moi démarrer le serveur en tapant npm start.

499
00:36:24,620 --> 00:36:28,935
Fait intéressant, il vient de lancer une erreur ici,

500
00:36:28,935 --> 00:36:32,330
je voulais juste vous illustrer que même je peux faire des erreurs,

501
00:36:32,330 --> 00:36:34,840
donc vous verrez qu'il y a une erreur ici qui dit,

502
00:36:34,840 --> 00:36:40,275
« Impossible de trouver module.authenticate », puis si je regarde à travers le code,

503
00:36:40,275 --> 00:36:45,255
je trouve que ce problème s'est produit dans le,

504
00:36:45,255 --> 00:36:46,850
où est-ce que cela s'est produit ?

505
00:36:46,850 --> 00:36:48,350
Donc, je cherche juste ici,

506
00:36:48,350 --> 00:36:50,020
et puis quelque part ici,

507
00:36:50,020 --> 00:36:56,130
j'ai remarqué que ce problème s'est produit dans mon fichier users.js.

508
00:36:56,130 --> 00:36:57,870
Donc, juste là, il dit,

509
00:36:57,870 --> 00:37:00,355
c'est dans le fichier users.js.

510
00:37:00,355 --> 00:37:05,655
Donc, en allant au fichier users.js, réparons cela.

511
00:37:05,655 --> 00:37:09,015
Aller

512
00:37:09,015 --> 00:37:14,285
au fichier users.js, juste en haut quand j'avais besoin d'authentifier, j'ai dit,

513
00:37:14,285 --> 00:37:17,555
« .authenticate », et comme je vous le disais,

514
00:37:17,555 --> 00:37:21,200
cela devrait être un point car il est dans le dossier supérieur.

515
00:37:21,200 --> 00:37:25,905
Ce fichier users.js dans le dossier Routes,

516
00:37:25,905 --> 00:37:31,985
et authenticate se trouve dans le dossier Projets Route, donc il doit être dot authenticate.

517
00:37:31,985 --> 00:37:34,660
Donc, si vous faites des erreurs, voilà,

518
00:37:34,660 --> 00:37:40,450
c'est comme ça que vous allez vous rappeler l'erreur que vous avez introduite.

519
00:37:40,450 --> 00:37:44,540
Donc, sauvegardons les modifications, puis redémarrez notre serveur.

520
00:37:44,540 --> 00:37:47,795
Encore une fois, revenant à ce terminal,

521
00:37:47,795 --> 00:37:54,735
laissez-moi démarrer mon serveur et mon serveur est maintenant opérationnel,

522
00:37:54,735 --> 00:38:00,235
allons à Postman et puis testez notre application.

523
00:38:00,235 --> 00:38:04,695
Maintenant, dans Postman, permettez-moi d'abord de faire

524
00:38:04,695 --> 00:38:11,170
un GET sur localhost : 3000/plats, puis quand je fais un GET,

525
00:38:11,170 --> 00:38:15,620
c'est réussi parce que le point final GET n'est pas contrôlé.

526
00:38:15,620 --> 00:38:18,595
Donc, je peux faire un GET sur les plats,

527
00:38:18,595 --> 00:38:23,545
je peux faire un GET sur les promotions,

528
00:38:23,545 --> 00:38:25,420
et tout fonctionne très bien.

529
00:38:25,420 --> 00:38:28,300
Mais si j'essaie de faire un POST sur les plats,

530
00:38:28,300 --> 00:38:32,435
alors laissez-moi trouver où j'ai fait un POST sur les plats.

531
00:38:32,435 --> 00:38:35,245
Ici, j'ai fait un POST sur les plats.

532
00:38:35,245 --> 00:38:38,030
Donc, quand j'ai essayé de faire un POST sur la vaisselle,

533
00:38:38,030 --> 00:38:40,540
il dit immédiatement non autorisé.

534
00:38:40,540 --> 00:38:47,410
Donc, mon module Passport a réalisé que je ne suis pas autorisé, donc je ne suis pas autorisé à le faire,

535
00:38:47,410 --> 00:38:49,825
donc c'est ce dont il me rappelle.

536
00:38:49,825 --> 00:38:52,750
Laissez-moi nettoyer les cookies de,

537
00:38:52,750 --> 00:38:57,980
au cas où vous trouvez un cookie dans votre Postman il suffit de supprimer le cookie

538
00:38:57,980 --> 00:39:00,410
correspondant au localhost parce

539
00:39:00,410 --> 00:39:03,815
que ce cookie n'est plus nécessaire et ne sera pas nécessaire.

540
00:39:03,815 --> 00:39:06,100
Donc, même si je supprime le cookie puis POST,

541
00:39:06,100 --> 00:39:07,990
il dira toujours non autorisé.

542
00:39:07,990 --> 00:39:11,715
Donc, je ne suis pas autorisé à faire ces opérations.

543
00:39:11,715 --> 00:39:13,305
Donc, je dois me connecter.

544
00:39:13,305 --> 00:39:15,430
Maintenant, si vous avez fait l'exercice précédent,

545
00:39:15,430 --> 00:39:19,390
vous auriez quitté l'utilisateur que vous avez inscrit plus tôt.

546
00:39:19,390 --> 00:39:25,865
Donc, par exemple, vous auriez inscrit cet utilisateur particulier dans l'exercice précédent,

547
00:39:25,865 --> 00:39:29,530
laissez-moi essayer d'inscrire à nouveau le même utilisateur et

548
00:39:29,530 --> 00:39:36,090
mon serveur devrait se plaindre en disant UserExistsError, ce qui signifie que l'utilisateur existe,

549
00:39:36,090 --> 00:39:38,455
donc je n'ai pas besoin de m'inscrire à nouveau.

550
00:39:38,455 --> 00:39:42,290
Si vous avez supprimé l'utilisateur de votre MongoDB,

551
00:39:42,290 --> 00:39:47,275
il suffit d'inscrire cet utilisateur une fois de plus, puis nous allons nous connecter.

552
00:39:47,275 --> 00:39:55,830
Donc, nous allons envoyer une demande de connexion à ce point final.

553
00:39:55,830 --> 00:40:00,640
Donc, lorsque j'envoie la demande de connexion en faisant un POST à l'utilisateur final,

554
00:40:00,640 --> 00:40:03,365
remarquez ce qui est retourné par mon serveur.

555
00:40:03,365 --> 00:40:06,965
Vous remarquez immédiatement que dans le message de réponse

556
00:40:06,965 --> 00:40:10,830
avec l'indicateur de succès et le message d'état,

557
00:40:10,830 --> 00:40:13,740
vous obtenez également un jeton ici.

558
00:40:13,740 --> 00:40:16,365
Maintenant, ce jeton particulier,

559
00:40:16,365 --> 00:40:17,960
j'ai besoin de copier ce jeton,

560
00:40:17,960 --> 00:40:21,045
car dans mes demandes suivantes,

561
00:40:21,045 --> 00:40:23,535
je devrai inclure ce jeton.

562
00:40:23,535 --> 00:40:31,610
Donc, laissez-moi aller à la version brute de ceci et que je vais copier ce jeton.

563
00:40:31,610 --> 00:40:33,875
Ce jeton n'est rien d'autre qu'une longue chaîne là-bas,

564
00:40:33,875 --> 00:40:36,260
alors laissez-moi copier ce jeton.

565
00:40:36,260 --> 00:40:41,765
Alors maintenant, si vous êtes curieux de savoir ce qui est contenu dans ce jeton,

566
00:40:41,765 --> 00:40:44,800
le jeton Web JSON peut être examiné.

567
00:40:44,800 --> 00:40:48,140
Il existe un site particulier où vous pouvez entrer et taper

568
00:40:48,140 --> 00:40:52,235
votre jeton Web JSON, puis vérifier réellement ce qui se trouve à l'intérieur du jeton Web JSON.

569
00:40:52,235 --> 00:40:54,980
Faisons ça comme la prochaine étape.

570
00:40:54,980 --> 00:40:56,685
Dans une fenêtre de navigateur,

571
00:40:56,685 --> 00:41:05,565
tapez simplement jwt.io et cela vous mènera à ce site appelé JSON Web Token jwt.io.

572
00:41:05,565 --> 00:41:07,590
Si vous vous souvenez, dans la conférence,

573
00:41:07,590 --> 00:41:10,685
je vous avais montré la structure du jeton Web JSON

574
00:41:10,685 --> 00:41:14,290
et vous avais montré que le jeton Web JSON contient trois parties : l'en-tête,

575
00:41:14,290 --> 00:41:18,040
la charge utile et les informations qui s'y trouvent.

576
00:41:18,040 --> 00:41:19,730
Maintenant, dans ce cas,

577
00:41:19,730 --> 00:41:25,880
les informations sont ici donc je vais

578
00:41:25,880 --> 00:41:33,285
coller mon jeton Web JSON dans ce côté gauche,

579
00:41:33,285 --> 00:41:37,270
alors laissez-moi le sélectionner et puis coller mon jeton Web JSON dans

580
00:41:37,270 --> 00:41:41,920
le côté gauche dans la partie codée, puis sur le côté droit,

581
00:41:41,920 --> 00:41:46,030
il vous montre exactement ce qui est dans le jeton Web JSON que je viens de créer.

582
00:41:46,030 --> 00:41:49,580
Donc, il dit que l'en-tête contient ces deux éléments d'information.

583
00:41:49,580 --> 00:41:54,090
La charge utile indique qu'elle contient l'ID de

584
00:41:54,090 --> 00:41:59,245
l'utilisateur, puis la signature en bas ici.

585
00:41:59,245 --> 00:42:03,995
Donc, c'est ce qui est contenu dans mon jeton Web JSON.

586
00:42:03,995 --> 00:42:07,005
En revenant à Postman,

587
00:42:07,005 --> 00:42:12,110
laissez-moi essayer de prendre la vaisselle.

588
00:42:12,110 --> 00:42:15,940
Donc, quand je dis GET localhost:3000/plats,

589
00:42:15,940 --> 00:42:18,650
il retournera toujours une chaîne vide,

590
00:42:18,650 --> 00:42:23,385
tableau vide ici parce que ma base de données ne le contient pas.

591
00:42:23,385 --> 00:42:29,635
Donc, laissez-moi POST un plat dans ma base de données.

592
00:42:29,635 --> 00:42:33,290
Donc, je vais choisir l'opération POST et dans le corps,

593
00:42:33,290 --> 00:42:36,095
vous voyez que j'ai mon plat ici.

594
00:42:36,095 --> 00:42:41,215
Dans l'en-tête, je vais ajouter le nouvel en-tête appelé

595
00:42:41,215 --> 00:42:47,240
autorisation et vous vous souvenez que précédemment pour l'autorisation de base,

596
00:42:47,240 --> 00:42:53,425
vous avez dit basique et ensuite vous aviez la chaîne codée Base 64 là.

597
00:42:53,425 --> 00:42:58,970
Si vous voulez inclure votre jeton Web JSON dans l'en-tête d'autorisation,

598
00:42:58,970 --> 00:43:01,150
parce que dans notre code,

599
00:43:01,150 --> 00:43:04,550
nous avons dit autorisation comme jeton porteur.

600
00:43:04,550 --> 00:43:08,040
Donc, si vous voulez inclure le jeton dans l'en-tête d'autorisation,

601
00:43:08,040 --> 00:43:13,275
dans l'autorisation, nous dirons porteur et ensuite nous allons coller

602
00:43:13,275 --> 00:43:19,080
cette chaîne de jeton que nous venons de copier à partir de notre demande entrante.

603
00:43:19,080 --> 00:43:21,935
Donc, nous allons coller la chaîne de jeton dedans.

604
00:43:21,935 --> 00:43:24,360
Donc, c'est ce qui sera contenu dans

605
00:43:24,360 --> 00:43:29,795
l'en-tête d'autorisation de ma demande sortante ici,

606
00:43:29,795 --> 00:43:33,845
requête POST sortante ici.

607
00:43:33,845 --> 00:43:39,970
Donc, remarquez, le côté gauche dit porteur et le côté droit est la chaîne,

608
00:43:39,970 --> 00:43:43,230
le jeton que je viens de copier à partir

609
00:43:43,230 --> 00:43:48,460
du point où je me suis connecté, puis laissez-moi envoyer le message POST

610
00:43:48,460 --> 00:43:57,590
maintenant et mon POST est maintenant réussi et ceci est posté dans ma base de données.

611
00:43:57,590 --> 00:44:01,115
Maintenant, si vous voulez être sûr qu'il a été posté,

612
00:44:01,115 --> 00:44:04,555
faisons un GET et quand vous faites un GET,

613
00:44:04,555 --> 00:44:12,935
vous pouvez voir qu'en effet ce plat a été inséré dans ma base de données comme indiqué ici.

614
00:44:12,935 --> 00:44:19,260
Donc, c'est ainsi que vous allez utiliser les jetons Web JSON dans votre application.

615
00:44:19,260 --> 00:44:22,230
Ainsi, chaque fois que vous avez besoin d'effectuer une

616
00:44:22,230 --> 00:44:25,505
opération POST, PUT ou DELETE sur l'un des points de terminaison,

617
00:44:25,505 --> 00:44:27,010
vous seriez enfermant.

618
00:44:27,010 --> 00:44:33,895
Donc, laissez-moi revenir à cette demande POST ici.

619
00:44:33,895 --> 00:44:35,890
Dans l'en-tête, vous allez mettre

620
00:44:35,890 --> 00:44:41,540
ce champ d'autorisation et puis cela serait inclus dans l'autorisation,

621
00:44:41,540 --> 00:44:47,540
vous le commencerez avec le porteur, puis la chaîne de jeton,

622
00:44:47,540 --> 00:44:50,200
après cet espace porteur,

623
00:44:50,200 --> 00:44:54,215
un seul espace, puis la chaîne de jeton qui suit.

624
00:44:54,215 --> 00:44:58,310
Donc, c'est ainsi que vos messages de requête

625
00:44:58,310 --> 00:45:03,140
porteraient le jeton Web JSON dans l'en-tête du message de demande sortant.

626
00:45:03,140 --> 00:45:08,220
Vous pouvez également inclure le jeton dans le corps du message de demande sortante.

627
00:45:08,220 --> 00:45:10,310
Maintenant, pour cela, vous devrez configurer

628
00:45:10,310 --> 00:45:18,210
votre serveur express en particulier le JWT supplémentaire dans le

629
00:45:18,210 --> 00:45:21,120
fichier authenticate.js pour l'accepter

630
00:45:21,120 --> 00:45:24,455
du corps, donc vous rappelez que nous avons vu que

631
00:45:24,455 --> 00:45:28,890
le JWT supplémentaire prend en charge de nombreuses façons différentes d'extraire

632
00:45:28,890 --> 00:45:33,695
le jeton Web JSON à partir du demande.

633
00:45:33,695 --> 00:45:35,090
Donc, là, vous devez spécifier,

634
00:45:35,090 --> 00:45:36,670
si vous allez l'inclure dans le corps,

635
00:45:36,670 --> 00:45:39,115
vous devez spécifier cette information là.

636
00:45:39,115 --> 00:45:42,395
Maintenant, les détails sur la façon de le faire, vous pouvez consulter

637
00:45:42,395 --> 00:45:49,885
la documentation du module Passeport JWT pour comprendre comment cela est fait.

638
00:45:49,885 --> 00:45:54,610
Dans ce cours, je vais simplement l'utiliser dans l'en-tête d'autorisation

639
00:45:54,610 --> 00:45:59,835
comme je l'ai montré ici et cela fonctionne très bien pour la plupart des cas.

640
00:45:59,835 --> 00:46:02,620
Maintenant, si vous développez une application Web,

641
00:46:02,620 --> 00:46:06,635
une application Angular ou une application Ionic ou NativeScript,

642
00:46:06,635 --> 00:46:09,800
vous devez être en mesure de configurer

643
00:46:09,800 --> 00:46:16,615
cette application de sorte que le jeton Web JSON sera inclus dans l'en-tête d'autorisation.

644
00:46:16,615 --> 00:46:22,215
Dans la dernière leçon de ce cours,

645
00:46:22,215 --> 00:46:26,255
je vais vous montrer comment intégrer le client et le serveur,

646
00:46:26,255 --> 00:46:29,310
le client que vous avez développé dans les cours précédents avec

647
00:46:29,310 --> 00:46:32,495
le serveur que nous avons développé dans ce cours.

648
00:46:32,495 --> 00:46:35,120
Avec cela, nous complétons cet exercice.

649
00:46:35,120 --> 00:46:37,940
Dans cet exercice, nous avons vu comment nous

650
00:46:37,940 --> 00:46:42,200
pouvons configurer notre application pour utiliser les jetons Web JSON,

651
00:46:42,200 --> 00:46:50,555
et nous avons vu comment nous gérons l'authentification de l'utilisateur en utilisant le jeton Web JSON, en

652
00:46:50,555 --> 00:46:55,555
utilisant le support du module Passport et du module Passport JWT,

653
00:46:55,555 --> 00:46:58,605
et les modules JSON Web Token Node.

654
00:46:58,605 --> 00:47:01,090
Avec cela, nous complétons cet exercice.

655
00:47:01,090 --> 00:47:09,110
C' est le bon moment pour vous de faire un Git Commit avec le message Passport JWT.