1
00:00:03,890 --> 00:00:11,670
Ora che abbiamo compreso l'autenticazione basata su token utilizzando i token Web JSON

2
00:00:11,670 --> 00:00:16,035
e abbiamo anche compreso i vantaggi dell'utilizzo di questo approccio.

3
00:00:16,035 --> 00:00:22,185
Il fatto che ora stiamo costruendo un server basato su API Rest,

4
00:00:22,185 --> 00:00:24,420
in questo corso significa che

5
00:00:24,420 --> 00:00:27,585
l'autenticazione basata su token Web JSON

6
00:00:27,585 --> 00:00:31,410
è più adatta per questo server che stiamo costruendo.

7
00:00:31,410 --> 00:00:40,585
Quindi, aggiorniamo il nostro server API Rest per fare uso di token Web JSON in questo esercizio.

8
00:00:40,585 --> 00:00:45,755
Per iniziare ad aggiornare il server sul tuo terminale,

9
00:00:45,755 --> 00:00:51,935
installiamo prima il token Web JSON e il modulo del nodo JWT passaporto.

10
00:00:51,935 --> 00:00:56,445
Quindi, al prompt digitare npm, installa,

11
00:00:56,445 --> 00:01:05,640
passaporto JWT JSON Web Token e meno salva.

12
00:01:05,640 --> 00:01:15,435
Come puoi vedere, sto usando JSON Web Token 8.3.0 e passaporto JWT 4.0.0 in questo corso.

13
00:01:15,435 --> 00:01:23,180
Ora che abbiamo completato l'installazione andiamo avanti e aggiorniamo il nostro server express.

14
00:01:23,180 --> 00:01:25,700
Andando ora al nostro codice,

15
00:01:25,700 --> 00:01:30,289
aggiungiamo un file chiamato

16
00:01:30,289 --> 00:01:36,335
conflict.js nella cartella principale del nostro progetto.

17
00:01:36,335 --> 00:01:39,455
Ora, questo file conflict.js ho intenzione di usarlo per

18
00:01:39,455 --> 00:01:43,220
memorizzare alcune informazioni di configurazione per il nostro server.

19
00:01:43,220 --> 00:01:49,790
Ora, questo è un modo per centralizzare tutta la configurazione per il nostro server.

20
00:01:49,790 --> 00:01:53,600
In questo file conflict.js,

21
00:01:53,600 --> 00:01:59,825
lasciami esportare un oggetto JSON qui.

22
00:01:59,825 --> 00:02:02,490
Quindi diremo, SecretKey,

23
00:02:08,510 --> 00:02:11,550
e questo è dove

24
00:02:19,450 --> 00:02:28,705
specificherò la chiave segreta che userò per firmare il mio token Web JSON,

25
00:02:28,705 --> 00:02:36,700
e lasciatemi anche specificare un URL Mongo qui,

26
00:02:36,700 --> 00:02:41,275
che sarà l'URL per il

27
00:02:41,275 --> 00:02:51,710
mio server MongoDB localhost 27017.

28
00:02:52,200 --> 00:02:55,060
Una volta che abbiamo completato questo,

29
00:02:55,060 --> 00:02:59,260
allora andremo al file authenticate.js,

30
00:02:59,260 --> 00:03:01,780
e nel file authenticate.js

31
00:03:01,780 --> 00:03:10,700
ora creeremo la strategia JWT.

32
00:03:11,250 --> 00:03:16,175
Questa è la strategia di token web JSON fornita dal

33
00:03:16,175 --> 00:03:25,830
nostro modulo nodo JWT passaporto che abbiamo appena incluso e quindi diremo,

34
00:03:26,300 --> 00:03:32,895
generatività strategia passaporto generativity.strategy.

35
00:03:32,895 --> 00:03:35,370
Questo ci fornirà

36
00:03:35,370 --> 00:03:40,550
una strategia basata su token Web JSON per configurare il nostro modulo passaporto,

37
00:03:40,550 --> 00:03:46,820
quindi estrarre JWT, che

38
00:03:46,820 --> 00:03:53,745
otterrò anche dal passaporto JWT.

39
00:03:53,745 --> 00:03:55,935
Avremo bisogno del passaporto JWT,

40
00:03:55,935 --> 00:03:59,565
poi diremo «Estrai JWT».

41
00:03:59,565 --> 00:04:02,655
Quindi importiamo

42
00:04:02,655 --> 00:04:10,240
il modulo JSON Web Token

43
00:04:10,240 --> 00:04:12,265
che abbiamo appena installato.

44
00:04:12,265 --> 00:04:15,340
Una volta che abbiamo importato questi,

45
00:04:15,340 --> 00:04:18,370
andiamo avanti e iniziamo a configurare alcune cose.

46
00:04:18,370 --> 00:04:26,205
Insieme a questi, lasciami importare la configurazione che ho

47
00:04:26,205 --> 00:04:35,840
creato il file config.js che ho appena aggiunto al mio progetto.

48
00:04:35,840 --> 00:04:40,100
Una volta completato questo, lasciami andare avanti e

49
00:04:40,100 --> 00:04:45,650
introdurre alcune funzioni aggiuntive che esporterò da qui.

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

51
00:04:55,160 --> 00:05:02,840
questa funzione quando fornisci un parametro lì che chiamerò semplicemente utente,

52
00:05:02,840 --> 00:05:06,335
che sarà un oggetto JSON,

53
00:05:06,335 --> 00:05:10,145
questo creerà il token e lo darà per noi.

54
00:05:10,145 --> 00:05:16,685
Per creare il token, useremo il modulo jsonwebtoken che abbiamo appena importato.

55
00:05:16,685 --> 00:05:22,140
Quindi, qui diremo ritorno JWT.sign,

56
00:05:23,750 --> 00:05:31,355
questo ci aiuta a creare il token Web JSON e così dentro che

57
00:05:31,355 --> 00:05:34,430
mi permetterà di fornire il payload e

58
00:05:34,430 --> 00:05:38,825
il payload qui arriva come il parametro qui chiamato utente,

59
00:05:38,825 --> 00:05:42,620
e quindi il secondo parametro è

60
00:05:42,620 --> 00:05:51,050
la chiave segreta o privata che ottengo da config. chiave segreta,

61
00:05:51,050 --> 00:05:55,260
che ho appena configurato un po 'prima.

62
00:05:55,630 --> 00:06:02,835
Possiamo fornire ulteriori opzioni qui.

63
00:06:02,835 --> 00:06:07,055
Un' opzione che ho intenzione di fornire a questo è...

64
00:06:07,055 --> 00:06:09,410
Ok, lasciami andare alla riga successiva qui,

65
00:06:09,410 --> 00:06:14,160
l'opzione che fornirò è ExpiResin.

66
00:06:14,530 --> 00:06:20,945
ExpiResin ti dirà per quanto tempo il jsonwebtoken sarà

67
00:06:20,945 --> 00:06:27,185
valido, quindi in questo caso dico 3.600 che significa 3.600 secondi o circa un'ora.

68
00:06:27,185 --> 00:06:32,825
Un' ora dopo dovrai rinnovare il jsonwebtoken.

69
00:06:32,825 --> 00:06:36,790
Un' ora è abbastanza lunga per essere in grado di testare la nostra applicazione.

70
00:06:36,790 --> 00:06:40,370
È possibile impostare questo per essere molto più lungo se si sceglie di farlo.

71
00:06:40,370 --> 00:06:45,110
In un'applicazione reale potresti impostare questo valore molto più lungo forse

72
00:06:45,110 --> 00:06:50,075
qualche giorno e aspettarti che l'utente si autentichi nuovamente ogni pochi giorni.

73
00:06:50,075 --> 00:06:52,670
Ora, dovremo anche configurare

74
00:06:52,670 --> 00:06:58,025
la strategia basata su jsonwebtoken per la nostra applicazione passaporto.

75
00:06:58,025 --> 00:07:02,900
Quindi, lasciami dichiarare una variabile chiamata opts,

76
00:07:02,900 --> 00:07:12,140
che non è altro che le opzioni che ho intenzione di specificare per la mia strategia basata su JWT.

77
00:07:12,140 --> 00:07:18,905
Quindi diremo opts jwtFromRequest.

78
00:07:18,905 --> 00:07:22,925
Ora questa opzione specifica

79
00:07:22,925 --> 00:07:28,580
come jsonwebtoken deve essere estratto dal messaggio di richiesta in arrivo.

80
00:07:28,580 --> 00:07:33,755
Questo è dove useremo l'estratto JWT.

81
00:07:33,755 --> 00:07:39,290
Questo estratto JWT supporta vari metodi

82
00:07:39,290 --> 00:07:44,970
per estrarre informazioni dall'intestazione.

83
00:07:44,970 --> 00:07:49,580
Dirà da AuthHeader da AuthHeader come token portatore,

84
00:07:49,580 --> 00:07:51,510
dall'intestazione quale schema e così via.

85
00:07:51,510 --> 00:07:54,380
Se leggi la documentazione,

86
00:07:54,380 --> 00:07:58,040
ti dirà vari modi di estrarre il jsonwebtoken.

87
00:07:58,040 --> 00:08:00,770
È possibile passare il token nel corpo del

88
00:08:00,770 --> 00:08:04,970
messaggio di richiesta in arrivo e quindi è possibile estrarlo da lì, è

89
00:08:04,970 --> 00:08:08,255
anche possibile utilizzare estrattori personalizzati e così via.

90
00:08:08,255 --> 00:08:14,180
In questo corso, ho intenzione di utilizzare il metodo più semplice chiamato

91
00:08:14,180 --> 00:08:20,745
dall'intestazione di autenticazione come un token portatore.

92
00:08:20,745 --> 00:08:22,220
Abbiamo già familiarità con

93
00:08:22,220 --> 00:08:25,055
l'intestazione di autenticazione perché come abbiamo usato con

94
00:08:25,055 --> 00:08:30,440
l'autenticazione di base e l'autenticazione basata su cookie in precedenza.

95
00:08:30,440 --> 00:08:32,180
Quindi, userò

96
00:08:32,180 --> 00:08:38,350
lo stesso campo di intestazione nel messaggio di richiesta per portare il jsonwebtoken.

97
00:08:38,350 --> 00:08:45,270
Quindi dirò opts come token portatore jsonwebtoken.

98
00:08:45,270 --> 00:08:51,160
Il prossimo diremo opts.SecretorKey,

99
00:08:56,980 --> 00:09:02,795
questo è il secondo parametro che mi aiuta a

100
00:09:02,795 --> 00:09:11,670
fornire la chiave segreta che userò all'interno della mia strategia per l'accesso.

101
00:09:11,670 --> 00:09:15,875
Quindi questa è l'altra opzione che ho intenzione di specificare qui.

102
00:09:15,875 --> 00:09:18,065
Una volta che sto specificando questi due,

103
00:09:18,065 --> 00:09:26,390
lasciami esportare la strategia Passport

104
00:09:26,390 --> 00:09:30,680
che ho intenzione di configurare qui così diremo ExportJWTPassport,

105
00:09:30,680 --> 00:09:34,355
quindi diremo passport.use.

106
00:09:34,355 --> 00:09:37,940
Ricorda il modo in cui hai specificato la strategia locale in precedenza.

107
00:09:37,940 --> 00:09:42,035
Qui stiamo specificando la strategia basata su JWT,

108
00:09:42,035 --> 00:09:47,895
quindi creeremo una nuova strategia JWT,

109
00:09:47,895 --> 00:09:51,320
ricordare che abbiamo appena importato la strategia JWT

110
00:09:51,320 --> 00:09:56,615
qui che è ciò che useremo per creare una nuova strategia.

111
00:09:56,615 --> 00:10:01,235
Questa strategia JWT prende

112
00:10:01,235 --> 00:10:07,675
l'oggetto options che ho appena creato come primo parametro.

113
00:10:07,675 --> 00:10:14,210
Le opzioni di strategia e la seconda è la funzione di verifica che ho bisogno di fornire,

114
00:10:14,210 --> 00:10:18,050
e quindi la funzione di verifica che ho intenzione di fornire nella riga successiva qui,

115
00:10:18,050 --> 00:10:28,545
diremo FunctionJWT_PayLoad.

116
00:10:28,545 --> 00:10:33,900
Fatto. Quindi, quando viene chiamata questa funzione,

117
00:10:33,900 --> 00:10:39,270
il fatto è il callback fornito dal passaporto.

118
00:10:39,270 --> 00:10:44,270
Quindi, ogni volta che hai il passaporto che stai configurando con una nuova strategia,

119
00:10:44,270 --> 00:10:46,750
devi fornire il secondo parametro fatto.

120
00:10:46,750 --> 00:10:48,460
Attraverso questo parametro fatto,

121
00:10:48,460 --> 00:10:52,235
si passerà indietro le informazioni al passaporto che poi

122
00:10:52,235 --> 00:10:57,780
utilizzerà per caricare le cose sul messaggio di richiesta.

123
00:10:57,780 --> 00:11:00,710
Quindi, quando il passaporto analizza il messaggio di richiesta,

124
00:11:00,710 --> 00:11:04,110
utilizzerà la strategia e quindi estrarre le informazioni,

125
00:11:04,110 --> 00:11:09,540
e quindi caricarlo sul nostro messaggio di richiesta.

126
00:11:09,540 --> 00:11:13,905
Quindi, dal momento che questa è una funzione,

127
00:11:13,905 --> 00:11:19,795
userò solo una funzione freccia qui,

128
00:11:19,795 --> 00:11:22,160
mi sono affezionato alle funzioni di freccia.

129
00:11:22,160 --> 00:11:25,650
Quindi, lasciatemi creare che come una funzione freccia qui,

130
00:11:25,650 --> 00:11:28,345
e all'interno di questa funzione,

131
00:11:28,345 --> 00:11:30,465
definiremo la funzione.

132
00:11:30,465 --> 00:11:32,970
Quindi, cosa facciamo all'interno della funzione?

133
00:11:32,970 --> 00:11:37,420
Lasciami fare un console.log di

134
00:11:38,370 --> 00:11:44,020
payload JWT e poi

135
00:11:44,660 --> 00:11:49,995
lasciami solo disconnettere l'opzione che arriva qui,

136
00:11:49,995 --> 00:11:51,770
l'opzione di payload JWT che viene qui, in

137
00:11:51,770 --> 00:11:55,420
modo che tu possa vedere cosa c'è all'interno del payload JWT.

138
00:11:55,420 --> 00:12:04,250
Quindi, cercheremo un utente dicendo user.findone,

139
00:12:04,250 --> 00:12:14,020
e poi so che nel jwt.payload,

140
00:12:14,020 --> 00:12:17,210
c'è un campo ID che entra.

141
00:12:17,210 --> 00:12:21,360
Quindi, questo è quello che sto per assegnare come campo ID qui.

142
00:12:21,360 --> 00:12:26,040
Quindi, dirò, user.findone e il secondo

143
00:12:26,040 --> 00:12:36,190
è una funzione di callback.

144
00:12:36,870 --> 00:12:45,295
Come ti rendi conto, questo metodo utente Mongoose e si tenta di trovare.

145
00:12:45,295 --> 00:12:54,665
Quindi, diremo se err allora, ritorno fatto.

146
00:12:54,665 --> 00:12:57,945
Che cosa fa questo? Questo fatto è il callback che il

147
00:12:57,945 --> 00:13:02,155
passaporto passerà nella vostra strategia qui.

148
00:13:02,155 --> 00:13:04,965
Quindi, stiamo andando a chiamare questa funzione fatta.

149
00:13:04,965 --> 00:13:11,200
Questo fatto in passaporto richiede tre parametri.

150
00:13:12,890 --> 00:13:20,400
Quindi, puoi vedere le tre informazioni che questo fatto si aspetta che dica, errore: qualsiasi.

151
00:13:20,400 --> 00:13:24,525
Quindi, se hai un errore lo passerai come primo parametro.

152
00:13:24,525 --> 00:13:26,495
Il secondo parametro, utente? ,

153
00:13:26,495 --> 00:13:28,245
Se esiste un utente,

154
00:13:28,245 --> 00:13:33,770
il valore dell'utente verrà passato e quindi se qualche informazione? :, qualsiasi.

155
00:13:33,770 --> 00:13:37,100
Quindi, questi due sono parametri opzionali e quindi,

156
00:13:37,100 --> 00:13:38,690
se si passa in qualsiasi informazione,

157
00:13:38,690 --> 00:13:42,145
allora che verrà utilizzato all'interno dell'applicazione.

158
00:13:42,145 --> 00:13:44,650
Se passo false come secondo parametro,

159
00:13:44,650 --> 00:13:47,515
significa che l'utente non esiste o quello.

160
00:13:47,515 --> 00:13:50,810
Quindi, interpreterà che l'utente non esiste.

161
00:13:50,810 --> 00:13:52,335
Quindi, potrei dire, err,

162
00:13:52,335 --> 00:13:54,900
falso, perché questo è un errore.

163
00:13:54,900 --> 00:13:58,080
Quindi, non ho intenzione di passare un valore utente lì,

164
00:13:58,080 --> 00:14:00,660
ho solo intenzione di passare in false.

165
00:14:00,660 --> 00:14:06,040
Lì, il prossimo,

166
00:14:06,040 --> 00:14:11,510
possiamo dire, altrimenti se (utente).

167
00:14:11,510 --> 00:14:15,860
Quindi, se l'utente non è nullo,

168
00:14:15,860 --> 00:14:18,960
diremo return done (null).

169
00:14:19,230 --> 00:14:22,210
Non c'è errore quindi, il primo parametro sarà

170
00:14:22,210 --> 00:14:25,080
nullo e il secondo parametro è l'utente,

171
00:14:25,080 --> 00:14:29,895
ma abbiamo appena ottenuto da MongoDB.

172
00:14:29,895 --> 00:14:35,445
In caso contrario, torneremo

173
00:14:35,445 --> 00:14:41,395
fatto con null, false.

174
00:14:41,395 --> 00:14:43,650
Quindi, nell'ultimo caso,

175
00:14:43,650 --> 00:14:45,100
non siamo riusciti a trovare l'utente,

176
00:14:45,100 --> 00:14:47,120
quindi stiamo andando a passare in false.

177
00:14:47,120 --> 00:14:50,200
Quindi, la gestiremo in questo modo.

178
00:14:50,200 --> 00:14:53,345
Se vuoi, puoi creare un nuovo account utente a questo punto,

179
00:14:53,345 --> 00:14:58,365
ma ho intenzione di mantenere questo semplice solo in modo che sia facile per noi capire.

180
00:14:58,365 --> 00:15:00,810
Quindi, diremo solo, nullo, falso. Quello e' sei.

181
00:15:00,810 --> 00:15:07,475
Quindi, questa è la strategia di passaporto JSONWebToken che ho appena configurato qui.

182
00:15:07,475 --> 00:15:11,420
Inoltre, lasciami esportare

183
00:15:11,420 --> 00:15:19,450
un'altra funzione da qui chiamata VerifyUser.

184
00:15:19,450 --> 00:15:21,110
Ora, questa funzione VerifyUser,

185
00:15:21,110 --> 00:15:24,935
lo userò per verificare un utente in arrivo.

186
00:15:24,935 --> 00:15:28,810
Quindi, questo è dove userò passport.authenticate.

187
00:15:28,890 --> 00:15:36,440
Quindi, il passport.authenticate, la strategia è la strategia jwt che ho appena configurato,

188
00:15:36,440 --> 00:15:39,490
la strategia JsonWebToken che ho appena configurato.

189
00:15:39,490 --> 00:15:41,625
Poi, la seconda parte,

190
00:15:41,625 --> 00:15:46,305
direi, sessione: false.

191
00:15:46,305 --> 00:15:47,740
Quindi, questo significa che,

192
00:15:47,740 --> 00:15:51,305
non stiamo andando a creare sessioni in questo caso.

193
00:15:51,305 --> 00:15:58,215
Come ricorderete, un'applicazione inversa,

194
00:15:58,215 --> 00:16:00,530
stiamo usando l'autenticazione basata su token.

195
00:16:00,530 --> 00:16:02,435
Quindi non creeremo sessioni.

196
00:16:02,435 --> 00:16:07,690
Quindi, è per questo che ho impostato questa sessione

197
00:16:07,690 --> 00:16:11,795
di opzione su false qui, e, naturalmente, il primo ha specificato la strategia che userò.

198
00:16:11,795 --> 00:16:14,050
Quindi, per verificare un utente,

199
00:16:14,050 --> 00:16:15,930
userò la strategia JWT.

200
00:16:15,930 --> 00:16:18,110
Come funziona la strategia JWT?

201
00:16:18,110 --> 00:16:20,540
Nella richiesta in arrivo,

202
00:16:21,040 --> 00:16:26,845
il token verrà incluso nell'intestazione di autenticazione come abbiamo visto qui.

203
00:16:26,845 --> 00:16:29,950
Abbiamo detto intestazione di autenticazione come token portatore.

204
00:16:29,950 --> 00:16:33,530
Se questo è incluso, allora verrà estratto e che verrà

205
00:16:33,530 --> 00:16:38,210
utilizzato per autenticare l'utente in base al token.

206
00:16:38,210 --> 00:16:47,770
Correzione minore qui, questo dovrebbe essere user.findone_id è uguale a jwt_payload. _id,

207
00:16:47,770 --> 00:16:56,475
perché questo è il valore id che si trova all'interno del payload del mio JSONWebToken.

208
00:16:56,475 --> 00:17:01,615
Quindi, stiamo cercando l'utente con quel dato ID.

209
00:17:01,615 --> 00:17:06,170
Quindi, una volta completato questo, ora,

210
00:17:06,170 --> 00:17:11,790
la seconda parte che dobbiamo fare è che dobbiamo creare il token da qualche parte.

211
00:17:11,790 --> 00:17:14,005
Ora, dove creiamo il token?

212
00:17:14,005 --> 00:17:20,290
Quindi, questo è dove qualcosa che stiamo facendo nel file users.js è molto utile per noi.

213
00:17:20,290 --> 00:17:22,270
Nel file users.js,

214
00:17:22,270 --> 00:17:27,180
ricorda che hai già questo endpoint chiamato login.

215
00:17:27,180 --> 00:17:28,700
Nell' endpoint di accesso

216
00:17:28,700 --> 00:17:33,410
si utilizzava il nome utente e la password per autenticare l'utente.

217
00:17:33,410 --> 00:17:38,030
Quindi, anche con JSONWebToken per emettere il JsonWebToken,

218
00:17:38,030 --> 00:17:41,959
è necessario prima autenticare l'utente utilizzando una delle altre strategie,

219
00:17:41,959 --> 00:17:44,630
e se si intende utilizzare prima la strategia locale,

220
00:17:44,630 --> 00:17:49,715
autenticeremo l'utente utilizzando il nome utente e la password.

221
00:17:49,715 --> 00:17:53,415
Una volta che l'utente è autenticato con il nome utente e

222
00:17:53,415 --> 00:17:55,885
la password, allora emetteremo il token all'utente dicendo:

223
00:17:55,885 --> 00:17:57,330
«Ok, sei un utente valido,

224
00:17:57,330 --> 00:17:58,630
ti darò il token».

225
00:17:58,630 --> 00:18:02,390
Tutte le richieste successive porteranno semplicemente il token

226
00:18:02,390 --> 00:18:06,860
nell'intestazione del messaggio di richiesta in arrivo.

227
00:18:06,860 --> 00:18:10,415
Quindi, prima, creavamo sessioni.

228
00:18:10,415 --> 00:18:11,840
Quando l'utente è autenticato,

229
00:18:11,840 --> 00:18:13,935
non useremo più le sessioni.

230
00:18:13,935 --> 00:18:17,640
Invece, quando l'utente viene autenticato utilizzando la strategia locale,

231
00:18:17,640 --> 00:18:20,110
emetteremo un token per l'utente.

232
00:18:20,110 --> 00:18:25,955
Quindi, all'interno di questo metodo Router.post che abbiamo fatto su quell'endpoint /login,

233
00:18:25,955 --> 00:18:31,730
ho intenzione di creare un token e passare questo token all'utente.

234
00:18:31,730 --> 00:18:36,980
Quindi, qui, diremo un router.post.

235
00:18:38,550 --> 00:18:40,785
Lasciatemi creare un token.

236
00:18:40,785 --> 00:18:42,630
Per creare un token,

237
00:18:42,630 --> 00:18:50,150
abbiamo questa funzione nel modulo di autenticazione chiamato Authenticate.getToken.

238
00:18:51,250 --> 00:18:54,325
Quindi, ricordate, che abbiamo già,

239
00:18:54,325 --> 00:18:57,050
per fare uso di questo, naturalmente,

240
00:18:57,050 --> 00:18:59,210
anche prima di iniziare da lì,

241
00:18:59,210 --> 00:19:02,750
ho bisogno di importare l'autenticazione.

242
00:19:05,940 --> 00:19:17,720
Modulo qui. Quindi, diremo autenticare richiedono. /authenticate.

243
00:19:18,000 --> 00:19:26,740
Quindi, quando nel tuo codice qui,

244
00:19:26,740 --> 00:19:29,270
ora possiamo dire Authenticate.GetToken,

245
00:19:31,530 --> 00:19:37,585
e il GetToken prende il parametro qui.

246
00:19:37,585 --> 00:19:41,875
Ora, ricorda, tornando indietro il file authenticate.js.

247
00:19:41,875 --> 00:19:46,665
Il file authenticate.js accetta qui un parametro

248
00:19:46,665 --> 00:19:53,105
che verrà utilizzato come payload quando si crea il JSONWebToken.

249
00:19:53,105 --> 00:19:55,785
Quindi, nel file users.js,

250
00:19:55,785 --> 00:19:59,230
creerò un token dando un payload,

251
00:19:59,230 --> 00:20:02,890
che contiene solo l'ID dell'utente.

252
00:20:02,890 --> 00:20:06,070
Quindi, diremo id: req.user. _id

253
00:20:06,740 --> 00:20:11,940
Questo è sufficiente per creare il JsonWebToken.

254
00:20:11,940 --> 00:20:15,315
Non vogliamo includere altre informazioni dell'utente.

255
00:20:15,315 --> 00:20:18,690
Se si sceglie di farlo, è possibile includere altre parti delle informazioni dell'utente,

256
00:20:18,690 --> 00:20:21,715
ma suggerirei di mantenere piccolo JsonWebToken.

257
00:20:21,715 --> 00:20:25,700
L' ID utente è sufficiente perché se è necessario cercare l'utente,

258
00:20:25,700 --> 00:20:32,840
l'ID utente è sufficiente per cercare in MongoDB l'utente.

259
00:20:32,840 --> 00:20:39,230
Quindi, ho intenzione di codificare solo l'ID dell'utente qui.

260
00:20:39,230 --> 00:20:44,930
Ora, sai che req.user sarebbe già presente,

261
00:20:44,930 --> 00:20:50,530
perché quando passport.authenticate ('local') autentica correttamente l'utente,

262
00:20:50,530 --> 00:20:54,650
questo sta per caricare la proprietà utente sul messaggio di richiesta.

263
00:20:54,650 --> 00:20:57,300
Quindi, è per questo che sono in grado di farlo qui.

264
00:20:57,300 --> 00:21:01,830
Quindi, questo è ciò che userò per creare il token.

265
00:21:01,900 --> 00:21:05,120
Ora, una volta creato il token,

266
00:21:05,120 --> 00:21:09,720
voglio passare questo token all'utente.

267
00:21:09,720 --> 00:21:15,715
Quindi, nell'oggetto rest.json che sto fornendo qui,

268
00:21:15,715 --> 00:21:21,755
sto già portando il flag vero successo e anche,

269
00:21:21,755 --> 00:21:23,855
un messaggio di stato qui.

270
00:21:23,855 --> 00:21:28,270
Permettetemi di aggiungere il token

271
00:21:28,270 --> 00:21:34,880
come una delle proprietà nel messaggio di risposta qui.

272
00:21:36,480 --> 00:21:39,475
Quindi, il token che ho appena creato,

273
00:21:39,475 --> 00:21:47,595
lo passerò come seconda proprietà all'interno di questa stringa Json qui.

274
00:21:47,595 --> 00:21:55,370
Quindi ora, quando il mio client riceve questa stringa Json nel corpo del messaggio di risposta,

275
00:21:55,370 --> 00:21:59,870
può entrare ed estrarre il token da lì.

276
00:22:00,140 --> 00:22:05,500
Questo è tutto. Quindi, ora abbiamo aggiornato il file users.js

277
00:22:05,500 --> 00:22:08,630
e ora puoi vedere come il token verrà

278
00:22:08,630 --> 00:22:12,690
creato e inviato all'utente quando l'utente viene autenticato correttamente.

279
00:22:12,690 --> 00:22:16,330
Ora, questo schema può essere utilizzato anche

280
00:22:16,330 --> 00:22:21,250
quando si utilizza l'autenticazione di terze parti come basata su OAuth 2.0,

281
00:22:21,250 --> 00:22:23,525
che esamineremo nel modulo successivo.

282
00:22:23,525 --> 00:22:25,695
Ora, la procedura sarà simile.

283
00:22:25,695 --> 00:22:28,880
Si creerà un token quando l'utente viene autenticato

284
00:22:28,880 --> 00:22:32,560
dal provider di autenticazione di terze parti o OAuth

285
00:22:32,560 --> 00:22:35,640
e quindi si passerà il token all'utente,

286
00:22:35,640 --> 00:22:39,010
in un approccio simile a quello che si vede qui.

287
00:22:39,010 --> 00:22:41,285
Ora, una volta che abbiamo fatto questo,

288
00:22:41,285 --> 00:22:44,255
allora andiamo al file app.js.

289
00:22:44,255 --> 00:22:53,660
Nel file app.js, perché abbiamo incluso un file di configurazione qui.

290
00:22:53,660 --> 00:22:59,005
Quindi, lasciami richiedere il file di configurazione qui,

291
00:22:59,005 --> 00:23:06,465
e poi l'URL che sto usando qui invece di hardcoding questo URL,

292
00:23:06,465 --> 00:23:11,345
dirò config.mongoURL.

293
00:23:11,345 --> 00:23:16,680
Quindi, ora, vedi come il mio file config.js può essere utilizzato come

294
00:23:16,680 --> 00:23:23,520
luogo centralizzato in cui posso preparare la configurazione per la mia applicazione.

295
00:23:23,520 --> 00:23:29,200
Questo è tutto. Quindi, ciò che accade ora è che quando l'utente si

296
00:23:29,200 --> 00:23:35,010
autentica sull'endpoint /login e l'utente viene autenticato correttamente,

297
00:23:35,010 --> 00:23:40,840
il token verrà creato dal server e restituito al client o all'utente.

298
00:23:40,840 --> 00:23:43,765
Quindi, il client includerà il token in

299
00:23:43,765 --> 00:23:47,765
ogni successiva richiesta in arrivo nell'intestazione di autorizzazione.

300
00:23:47,765 --> 00:23:50,590
Ora, come include l'intestazione di autorizzazione?

301
00:23:50,590 --> 00:23:54,220
Torniamo a authentic.js e qui,

302
00:23:54,220 --> 00:24:01,625
si vede che abbiamo detto ExtractJWT.FromAuthHeaderErasBearerToken qui.

303
00:24:01,625 --> 00:24:06,290
Quindi, questo sarà incluso nell'intestazione di autenticazione come token portatore.

304
00:24:06,290 --> 00:24:08,385
Ti mostrerò come questo è fatto,

305
00:24:08,385 --> 00:24:15,535
quindi usiamo il postino per includere il token portatore nell'intestazione di autenticazione.

306
00:24:15,535 --> 00:24:17,690
Ora, quando questo arriva,

307
00:24:17,690 --> 00:24:21,060
allora ricordi che proprio qui sotto,

308
00:24:21,060 --> 00:24:25,095
hai configurato questo metodo qui chiamato VerifyUser,

309
00:24:25,095 --> 00:24:30,635
che chiama l'autenticazione del passaporto con JWT.

310
00:24:30,635 --> 00:24:34,460
Quindi, questo usa il token che

311
00:24:34,460 --> 00:24:38,620
arriva nell'intestazione di autenticazione e quindi verifica l'utente.

312
00:24:38,620 --> 00:24:41,980
Quindi, ogni volta che voglio verificare l'autenticità dell'utente,

313
00:24:41,980 --> 00:24:43,855
posso semplicemente chiamare l'utente di verifica

314
00:24:43,855 --> 00:24:49,115
e che avvierà la chiamata al passport.authenticate e verificherà lo sser.

315
00:24:49,115 --> 00:24:50,315
Se questo ha successo

316
00:24:50,315 --> 00:24:51,800
, mi permetterà di procedere.

317
00:24:51,800 --> 00:24:55,620
Questa procedura è molto simile a quello che hai fatto nel

318
00:24:55,620 --> 00:25:01,610
file users.js in cui richiami lo stesso passport.authenticate ('local').

319
00:25:01,720 --> 00:25:04,320
Quindi, se questo ha successo,

320
00:25:04,320 --> 00:25:05,885
allora vai avanti.

321
00:25:05,885 --> 00:25:10,930
Se fallisce, la funzione di autenticazione restituirà il messaggio di errore

322
00:25:10,930 --> 00:25:16,050
al client che dice che l'utente non è autorizzato.

323
00:25:16,050 --> 00:25:18,345
Quindi, questo è già preso cura di.

324
00:25:18,345 --> 00:25:23,020
Quindi ora, che abbiamo incluso questo nel mio file authenticate.js,

325
00:25:23,020 --> 00:25:26,050
qualsiasi posto in cui voglio verificare l'utente,

326
00:25:26,050 --> 00:25:27,480
posso semplicemente chiamare

327
00:25:27,480 --> 00:25:31,210
questa funzione VerifyUser che

328
00:25:31,210 --> 00:25:34,320
ho specificato qui o l'esportazione che ho specificato qui,

329
00:25:34,320 --> 00:25:37,220
che chiameremo sul passport.authenticate usando

330
00:25:37,220 --> 00:25:40,540
la strategia JWT per autenticare l'utente.

331
00:25:40,540 --> 00:25:42,440
Ora, come facciamo a usarlo?

332
00:25:42,440 --> 00:25:47,785
Ora, quello che faremo è andare in ognuno dei nostri router,

333
00:25:47,785 --> 00:25:56,945
e controllare le opzioni su tutti i percorsi che vogliamo controllare.

334
00:25:56,945 --> 00:26:00,300
Quindi, tornando al file app.js, ora,

335
00:26:00,300 --> 00:26:07,925
che non stiamo usando sessioni ho intenzione di rimuovere questa sessione da qui,

336
00:26:07,925 --> 00:26:10,150
perché non stiamo più usando le sessioni.

337
00:26:10,150 --> 00:26:14,990
Allo stesso modo, ho intenzione di rimuovere questo passport.session da qui anche.

338
00:26:14,990 --> 00:26:17,580
Anche questo non è necessario.

339
00:26:17,580 --> 00:26:20,430
Inoltre, questa autenticazione, vedi prima,

340
00:26:20,430 --> 00:26:21,940
quando ho configurato questa autenticazione,

341
00:26:21,940 --> 00:26:25,490
questa autenticazione è stata applicata a ogni singola richiesta in entrata.

342
00:26:25,490 --> 00:26:28,705
Ora, cambierò la mia applicazione,

343
00:26:28,705 --> 00:26:35,055
per cui richiederò l'autenticazione solo su determinati percorsi e non su tutti i percorsi.

344
00:26:35,055 --> 00:26:39,665
Quindi, lasciami rimuovere completamente questa autenticazione da app.js.

345
00:26:39,665 --> 00:26:41,995
Quindi, ora, quando arriva la richiesta,

346
00:26:41,995 --> 00:26:45,850
se è su/endpoint,

347
00:26:45,850 --> 00:26:47,080
l'indice verrà servito.

348
00:26:47,080 --> 00:26:52,040
Se si trova sull'endpoint /users, ti permetterà di passare

349
00:26:52,040 --> 00:26:57,815
alle varie route che sono montate su/users nel users.js,

350
00:26:57,815 --> 00:27:00,900
e successivamente, al resto di quelle.

351
00:27:00,900 --> 00:27:03,420
Quello che farò ora è che lascerò

352
00:27:03,420 --> 00:27:07,250
aperta la cartella pubblica affinché chiunque possa accedere.

353
00:27:07,250 --> 00:27:09,145
Ora, in molte applicazioni,

354
00:27:09,145 --> 00:27:10,665
questo potrebbe andare bene.

355
00:27:10,665 --> 00:27:13,045
Quindi, lo lascio aperto.

356
00:27:13,045 --> 00:27:14,825
Ora, sui piatti, sulle

357
00:27:14,825 --> 00:27:17,920
promozioni e sull'endpoint dei leader,

358
00:27:17,920 --> 00:27:20,875
tutte le richieste di ottenere.

359
00:27:20,875 --> 00:27:28,205
Lascerò che vengano rispostati senza richiedere alcuna autenticazione.

360
00:27:28,205 --> 00:27:30,200
Ora perche' dovrei volerlo fare?

361
00:27:30,200 --> 00:27:33,190
Se un utente sta facendo una richiesta get,

362
00:27:33,190 --> 00:27:35,455
l'utente vuole solo recuperare le informazioni.

363
00:27:35,455 --> 00:27:40,490
Quindi, ad esempio, dal lato client se sto implementando un'applicazione web utilizzando Angular

364
00:27:40,490 --> 00:27:46,290
o un'applicazione client che utilizza lo script ionico o nativo,

365
00:27:46,290 --> 00:27:49,920
allora forse voglio implementare la mia app in

366
00:27:49,920 --> 00:27:54,310
modo tale che la pagina principale

367
00:27:54,310 --> 00:27:57,715
visualizzi già le informazioni genetiche che vuoi rendere disponibili a chiunque

368
00:27:57,715 --> 00:28:01,590
visiti il tuo sito web o che apra la tua app.

369
00:28:01,590 --> 00:28:04,360
Quindi, le informazioni di base possono essere visualizzate lì.

370
00:28:04,360 --> 00:28:08,060
Ma se vuoi cambiare qualcosa,

371
00:28:08,060 --> 00:28:12,110
ti aspetti che l'utente venga autenticato.

372
00:28:12,110 --> 00:28:16,255
Quindi, consentirai operazioni POST, operazioni put

373
00:28:16,255 --> 00:28:21,110
e operazioni di eliminazione solo da utenti autenticati.

374
00:28:21,110 --> 00:28:23,605
Allo stesso modo, per i commenti, ad esempio,

375
00:28:23,605 --> 00:28:30,280
si può dire che i commenti possono essere pubblicati o modificati solo da utenti autenticati.

376
00:28:30,280 --> 00:28:34,570
Quindi, è possibile limitare solo alcuni percorsi per gli utenti autenticati,

377
00:28:34,570 --> 00:28:37,940
l'altro percorso è possibile lasciarli aperti. Come facciamo?

378
00:28:37,940 --> 00:28:41,180
Ora questo è dove l'utente di verifica che

379
00:28:41,180 --> 00:28:45,055
abbiamo esportato dal file authenticate.js è utile.

380
00:28:45,055 --> 00:28:49,460
Ora invece di controllare tutti i punti finali,

381
00:28:49,460 --> 00:28:53,190
tutte le varie operazioni sui piatti, promozioni

382
00:28:53,190 --> 00:28:54,740
e leader in punti,

383
00:28:54,740 --> 00:28:58,240
apriremo solo le operazioni get per chiunque,

384
00:28:58,240 --> 00:29:00,830
ma le

385
00:29:00,830 --> 00:29:04,995
operazioni post, put ed delete saranno limitate solo agli utenti autenticati.

386
00:29:04,995 --> 00:29:10,350
Nell' assegnazione, aggiungerai un'altra categoria di utenti denominati utenti admin.

387
00:29:10,350 --> 00:29:15,320
Ora si dovrebbe limitare alcune operazioni per essere eseguite solo da utenti amministratori.

388
00:29:15,320 --> 00:29:18,460
Quindi, ad esempio, la modifica dei piatti

389
00:29:18,460 --> 00:29:22,530
o l'eliminazione delle informazioni dei piatti dal database,

390
00:29:22,530 --> 00:29:24,600
sarà limitata solo agli utenti amministratori.

391
00:29:24,600 --> 00:29:30,000
Ma gli utenti di base possono pubblicare commenti,

392
00:29:30,000 --> 00:29:32,470
modificare i commenti che hanno pubblicato

393
00:29:32,470 --> 00:29:35,450
e forse anche salvare alcuni piatti preferiti.

394
00:29:35,450 --> 00:29:38,520
Faremo quella parte nel quarto modulo.

395
00:29:38,520 --> 00:29:42,735
Ora, come controlliamo percorsi specifici?

396
00:29:42,735 --> 00:29:46,210
Quindi questo è dove dobbiamo andare in ciascuno dei router

397
00:29:46,210 --> 00:29:50,365
e quindi importare controlli su percorsi specifici.

398
00:29:50,365 --> 00:29:53,945
Quindi, iniziamo con il percorso dei piatti.

399
00:29:53,945 --> 00:29:55,770
Quindi, per il percorso dei piatti,

400
00:29:55,770 --> 00:29:59,950
ricorderai che questo è controllato nel file dishRouter.js.

401
00:29:59,950 --> 00:30:02,515
Quindi, andando a dishRouter.js,

402
00:30:02,515 --> 00:30:07,450
cerchiamo prima di importare l'autenticazione qui.

403
00:30:07,450 --> 00:30:13,400
Quindi diremo, const authenticate

404
00:30:17,010 --> 00:30:24,700
richiedono../authenticate perché questo

405
00:30:24,700 --> 00:30:29,110
file authenticator.js si trova nella cartella di livello superiore.

406
00:30:29,110 --> 00:30:32,105
Quindi, ricorda../autentica qui.

407
00:30:32,105 --> 00:30:34,505
Quindi, una volta importato l'autenticazione,

408
00:30:34,505 --> 00:30:37,965
per il percorso del router piatto per questo percorso,

409
00:30:37,965 --> 00:30:42,560
l'operazione get, ho intenzione di consentire senza alcun problema.

410
00:30:42,560 --> 00:30:44,820
Quindi, questo è aperto.

411
00:30:44,820 --> 00:30:47,025
Quindi non ho intenzione di imporre alcuna restrizione.

412
00:30:47,025 --> 00:30:51,750
Dal post, se vogliamo applicare più middleware,

413
00:30:51,750 --> 00:30:56,035
possiamo semplicemente aggiungere il principale all'interno di questo uno dietro l'altro.

414
00:30:56,035 --> 00:30:58,050
Ora, quando viene chiamato il post, in questo

415
00:30:58,050 --> 00:31:02,295
momento stai semplicemente eseguendo questa funzione qui.

416
00:31:02,295 --> 00:31:04,150
Ora poco prima,

417
00:31:04,150 --> 00:31:12,400
posso entrare e dire, Authenticate.VerifyUser, lì.

418
00:31:12,400 --> 00:31:13,805
Allora, cosa fa questo?

419
00:31:13,805 --> 00:31:17,210
Questo dice che se arriva una richiesta di post,

420
00:31:17,210 --> 00:31:20,940
eseguirei prima questo middleware,

421
00:31:20,940 --> 00:31:24,805
che ho esportato dal file authentic.js, per

422
00:31:24,805 --> 00:31:26,100
prima cosa lo applico,

423
00:31:26,100 --> 00:31:32,075
che equivale a dire passaporto autenticare JWT e stai controllando l'utente.

424
00:31:32,075 --> 00:31:34,655
Quindi se questo ha successo,

425
00:31:34,655 --> 00:31:38,890
allora passerò a fare il resto.

426
00:31:38,890 --> 00:31:42,955
Se l'autenticazione non riesce a questo

427
00:31:42,955 --> 00:31:46,290
punto, l'autenticazione passaporto

428
00:31:46,290 --> 00:31:49,395
risponderà al client con il messaggio di errore appropriato.

429
00:31:49,395 --> 00:31:51,640
Quindi questo è già gestito dall'autenticazione del passaporto,

430
00:31:51,640 --> 00:31:54,350
quindi non devo preoccuparmi nulla oltre quel punto.

431
00:31:54,350 --> 00:31:58,300
Se ho attraversato questo middleware e poi

432
00:31:58,300 --> 00:32:02,990
eseguo la funzione successiva, significa che la mia autenticazione ha avuto successo,

433
00:32:02,990 --> 00:32:05,560
quindi sono in grado di procedere in avanti da questo punto.

434
00:32:05,560 --> 00:32:11,760
Quindi, questo agisce come la barriera per questo metodo post.

435
00:32:11,760 --> 00:32:14,860
Ora usando lo stesso argomento,

436
00:32:14,860 --> 00:32:21,435
posso semplicemente applicare questo particolare middleware a tutti gli altri metodi.

437
00:32:21,435 --> 00:32:23,845
Posso farlo al put.

438
00:32:23,845 --> 00:32:26,030
Anche se in questo caso,

439
00:32:26,030 --> 00:32:28,640
mettere non sta andando a fare nulla.

440
00:32:28,640 --> 00:32:30,110
Ma in ogni caso,

441
00:32:30,110 --> 00:32:33,980
lo farò semplicemente per motivi di uniformità,

442
00:32:33,980 --> 00:32:38,490
applicherò l'utente di verifica anche per mettere e, naturalmente,

443
00:32:38,490 --> 00:32:41,315
anche per eliminare, ho intenzione di applicare put.

444
00:32:41,315 --> 00:32:44,805
Allo stesso modo, scendendo su/dishId,

445
00:32:44,805 --> 00:32:48,915
ottengo permetterò che funzioni senza alcun problema.

446
00:32:48,915 --> 00:32:52,470
Post, applicherò l'utente di verifica.

447
00:32:52,470 --> 00:32:59,600
Mettere anche applicherò l'utente di verifica e per eliminare anche lo stesso.

448
00:32:59,600 --> 00:33:09,105
Per il/dishid/comments, lascerò il get open,

449
00:33:09,105 --> 00:33:14,030
va bene per chiunque recuperare commenti su un piatto specifico.

450
00:33:14,030 --> 00:33:17,140
Post, ho intenzione di chiudere questo,

451
00:33:17,140 --> 00:33:21,995
quindi solo gli utenti verificati possono pubblicare commenti.

452
00:33:21,995 --> 00:33:27,710
Metti anche io chiuderò questo e cancellerò troppo.

453
00:33:29,280 --> 00:33:33,035
Devi fare un passo avanti e dire:

454
00:33:33,035 --> 00:33:38,230
«Solo gli utenti che hanno pubblicato il commento possono eliminare i propri post.»

455
00:33:38,230 --> 00:33:40,310
Ma lo faremo nel prossimo modulo.

456
00:33:40,310 --> 00:33:41,840
Per il momento, ho intenzione di dire,

457
00:33:41,840 --> 00:33:44,415
«Ok, un utente verificato può cancellare qualsiasi commento.»

458
00:33:44,415 --> 00:33:46,715
Questo ovviamente non è vero,

459
00:33:46,715 --> 00:33:48,850
possiamo mettere un ulteriore controllo,

460
00:33:48,850 --> 00:33:52,145
ma lo faremo nel prossimo modulo di questo corso.

461
00:33:52,145 --> 00:33:54,405
Quindi, per eliminare anche applico lo stesso.

462
00:33:54,405 --> 00:33:58,060
Ancora una volta, per i commenti/commenti del router piatto Id,

463
00:33:58,060 --> 00:34:00,300
ottenere lo lascerò aperto.

464
00:34:00,300 --> 00:34:04,485
Post, lo lascio chiuso.

465
00:34:04,485 --> 00:34:12,640
Metti anche chiudilo e poi per cancella anche chiuderò questo.

466
00:34:12,640 --> 00:34:14,970
Elimina, naturalmente, come ho detto,

467
00:34:14,970 --> 00:34:19,180
l'operazione di eliminazione dovrebbe essere consentita solo

468
00:34:19,180 --> 00:34:24,150
a un utente che ha creato il commento dovrebbe essere chiesto di eliminarlo,

469
00:34:24,150 --> 00:34:27,960
ma è necessario impostare alcune cose aggiuntive affinché funzioni correttamente, cosa

470
00:34:27,960 --> 00:34:30,825
che faremo nel modulo successivo.

471
00:34:30,825 --> 00:34:36,455
Per il momento, stiamo dicendo che un utente verificato può eliminare un commento specifico, il gioco è fatto.

472
00:34:36,455 --> 00:34:42,820
Ora applicheremo lo stesso principio al router promozionale e anche al router leader.

473
00:34:42,820 --> 00:34:44,950
Quindi, andando nel router promozionale,

474
00:34:44,950 --> 00:34:53,100
lasciami importare l'autenticazione

475
00:34:57,320 --> 00:35:00,870
e poi ottenere è aperto,

476
00:35:00,870 --> 00:35:03,540
quindi questo è il router leader.

477
00:35:03,540 --> 00:35:05,380
Quindi, ottenere è aperto.

478
00:35:05,380 --> 00:35:08,365
Post, ho intenzione di controllare che,

479
00:35:08,365 --> 00:35:12,865
mettere, controllare, eliminare, controllare,

480
00:35:12,865 --> 00:35:14,790
leader router, leader ID,

481
00:35:14,790 --> 00:35:17,255
get is okay, post,

482
00:35:17,255 --> 00:35:22,330
controllato, put è controllato e delete è controllato.

483
00:35:22,330 --> 00:35:24,795
Stessa cosa con il router promozionale.

484
00:35:24,795 --> 00:35:38,652
Permettetemi di richiedere l'autenticazione

485
00:35:38,652 --> 00:35:43,570
e quindi per il percorso get è aperto,

486
00:35:43,570 --> 00:35:47,109
POST è controllato, put è controllato,

487
00:35:47,109 --> 00:35:50,790
delete è controllato, stessa cosa per Promorouter/PromoID.

488
00:35:50,790 --> 00:35:54,460
Get è aperto, POST è controllato,

489
00:35:54,460 --> 00:35:58,395
put ed delete sono controllati anche, il gioco è fatto.

490
00:35:58,395 --> 00:36:00,225
Salviamo tutte le modifiche.

491
00:36:00,225 --> 00:36:02,660
Quindi, una volta completate tutte le modifiche,

492
00:36:02,660 --> 00:36:04,185
salviamo le modifiche.

493
00:36:04,185 --> 00:36:08,270
Ora, la nostra applicazione è pronta per essere testata.

494
00:36:08,270 --> 00:36:11,485
Quindi, andiamo a riavviare il nostro server,

495
00:36:11,485 --> 00:36:14,885
o se il server non è in esecuzione,

496
00:36:14,885 --> 00:36:16,590
faremo solo avviare il server.

497
00:36:16,590 --> 00:36:18,770
Andando al terminale,

498
00:36:18,770 --> 00:36:20,040
il mio server non è in esecuzione.

499
00:36:20,040 --> 00:36:23,930
Quindi, lasciami avviare il server digitando npm start.

500
00:36:24,620 --> 00:36:28,935
È interessante notare che ha appena generato un errore qui,

501
00:36:28,935 --> 00:36:32,330
volevo solo illustrarti che anche io posso commettere errori,

502
00:36:32,330 --> 00:36:34,840
quindi vedrai che c'è un errore qui che dice

503
00:36:34,840 --> 00:36:40,275
«Impossibile trovare module.authenticate», e poi se guardo attraverso il codice,

504
00:36:40,275 --> 00:36:45,255
trovo che questo problema si è verificato in,

505
00:36:45,255 --> 00:36:46,850
Dove si è verificato?

506
00:36:46,850 --> 00:36:48,350
Quindi, cerco qui,

507
00:36:48,350 --> 00:36:50,020
e poi da qualche parte quaggiù,

508
00:36:50,020 --> 00:36:56,130
ho notato che questo problema si è verificato all'interno del mio file users.js.

509
00:36:56,130 --> 00:36:57,870
Quindi, proprio lì, dice,

510
00:36:57,870 --> 00:37:00,355
questo è nel file users.js.

511
00:37:00,355 --> 00:37:05,655
Quindi, andando al file users.js, ripariamo questo.

512
00:37:05,655 --> 00:37:09,015
Andando

513
00:37:09,015 --> 00:37:14,285
al file users.js, proprio in alto quando ho richiesto l'autenticazione, ho detto,

514
00:37:14,285 --> 00:37:17,555
«.authenticate», e come ti stavo

515
00:37:17,555 --> 00:37:21,200
dicendo, dovrebbe essere un punto perché è nella cartella superiore.

516
00:37:21,200 --> 00:37:25,905
Questo file users.js nella cartella Routes

517
00:37:25,905 --> 00:37:31,985
e authenticate si trova nella cartella Projects Route quindi questo dovrebbe essere dot dot authenticate.

518
00:37:31,985 --> 00:37:34,660
Quindi, se commetti degli errori,

519
00:37:34,660 --> 00:37:40,450
ecco come ti verrà ricordato l'errore che hai introdotto.

520
00:37:40,450 --> 00:37:44,540
Quindi, salviamo le modifiche e poi riavviamo il nostro server.

521
00:37:44,540 --> 00:37:47,795
Ancora una volta, tornando a quel terminale,

522
00:37:47,795 --> 00:37:54,735
lasciami avviare il mio server e il mio server è ora attivo e funzionante,

523
00:37:54,735 --> 00:38:00,235
andiamo a Postman e poi testiamo la nostra applicazione.

524
00:38:00,235 --> 00:38:04,695
Ora, in Postman, lasciami prima provare a fare

525
00:38:04,695 --> 00:38:11,170
un GET su localhost: 3000/piatti e poi quando faccio un GET,

526
00:38:11,170 --> 00:38:15,620
ha successo perché il punto finale GET non è controllato.

527
00:38:15,620 --> 00:38:18,595
Così posso fare un GET sui piatti,

528
00:38:18,595 --> 00:38:23,545
Posso fare un GET sulle promozioni,

529
00:38:23,545 --> 00:38:25,420
e tutto funziona bene.

530
00:38:25,420 --> 00:38:28,300
Ma se provo a fare un POST sui piatti,

531
00:38:28,300 --> 00:38:32,435
quindi fammi trovare dove ho fatto un POST sui piatti.

532
00:38:32,435 --> 00:38:35,245
Qui ho fatto un POST sui piatti.

533
00:38:35,245 --> 00:38:38,030
Quindi, quando ho provato a fare un POST sui piatti,

534
00:38:38,030 --> 00:38:40,540
dice immediatamente non autorizzato.

535
00:38:40,540 --> 00:38:47,410
Quindi il mio modulo Passport si è reso conto che non sono autorizzato, quindi non mi è permesso farlo,

536
00:38:47,410 --> 00:38:49,825
quindi è quello che mi sta ricordando.

537
00:38:49,825 --> 00:38:52,750
Lasciami pulire i cookie da,

538
00:38:52,750 --> 00:38:57,980
nel caso in cui trovi un cookie nel tuo Postman rimuovi semplicemente il cookie

539
00:38:57,980 --> 00:39:00,410
corrispondente al localhost perché

540
00:39:00,410 --> 00:39:03,815
quel cookie non è più necessario e non sarà richiesto.

541
00:39:03,815 --> 00:39:06,100
Quindi, anche se rimuovo il cookie e poi POST,

542
00:39:06,100 --> 00:39:07,990
dirà comunque non autorizzato.

543
00:39:07,990 --> 00:39:11,715
Quindi, non sono autorizzato a fare queste operazioni.

544
00:39:11,715 --> 00:39:13,305
Quindi, devo accedere.

545
00:39:13,305 --> 00:39:15,430
Ora, se hai fatto l'esercizio precedente,

546
00:39:15,430 --> 00:39:19,390
avresti lasciato l'utente a cui ti sei registrato in precedenza.

547
00:39:19,390 --> 00:39:25,865
Quindi, ad esempio, avresti firmato questo particolare utente nell'esercizio precedente,

548
00:39:25,865 --> 00:39:29,530
lasciami provare a registrare di nuovo lo stesso utente e il

549
00:39:29,530 --> 00:39:36,090
mio server dovrebbe lamentarsi dicendo userExistsError in modo che significa che l'utente esiste,

550
00:39:36,090 --> 00:39:38,455
quindi non ho bisogno di registrarmi di nuovo.

551
00:39:38,455 --> 00:39:42,290
Se hai cancellato l'utente dal tuo MongoDB,

552
00:39:42,290 --> 00:39:47,275
basta iscriverti quell'utente ancora una volta e poi facciamo il login.

553
00:39:47,275 --> 00:39:55,830
Quindi, invieremo una richiesta di accesso a quel punto finale.

554
00:39:55,830 --> 00:40:00,640
Quindi, quando invio la richiesta di accesso facendo un POST all'utente finale,

555
00:40:00,640 --> 00:40:03,365
nota cosa viene restituito dal mio server.

556
00:40:03,365 --> 00:40:06,965
Si nota immediatamente che nel messaggio di risposta

557
00:40:06,965 --> 00:40:10,830
insieme al flag di successo e al messaggio di stato,

558
00:40:10,830 --> 00:40:13,740
si ottiene anche un token qui.

559
00:40:13,740 --> 00:40:16,365
Ora, questo particolare token,

560
00:40:16,365 --> 00:40:17,960
ho bisogno di copiare questo token,

561
00:40:17,960 --> 00:40:21,045
perché nelle mie richieste successive,

562
00:40:21,045 --> 00:40:23,535
dovrò includere questo token.

563
00:40:23,535 --> 00:40:31,610
Quindi, lasciami andare alla versione grezza di questo e che ho intenzione di copiare questo token.

564
00:40:31,610 --> 00:40:33,875
Questo token non è altro che una lunga stringa lì,

565
00:40:33,875 --> 00:40:36,260
quindi fammi copiare questo token.

566
00:40:36,260 --> 00:40:41,765
Quindi ora se sei curioso di sapere cosa è contenuto in questo token,

567
00:40:41,765 --> 00:40:44,800
il token Web JSON può essere esaminato.

568
00:40:44,800 --> 00:40:48,140
C' è un particolare sito in cui puoi entrare e digitare

569
00:40:48,140 --> 00:40:52,235
il tuo token Web JSON e quindi verificare effettivamente cosa c'è all'interno del token Web JSON.

570
00:40:52,235 --> 00:40:54,980
Facciamolo come il prossimo passo.

571
00:40:54,980 --> 00:40:56,685
In una finestra del browser,

572
00:40:56,685 --> 00:41:05,565
basta digitare jwt.io e questo vi porterà a questo sito chiamato JSON Web Token jwt.io.

573
00:41:05,565 --> 00:41:07,590
Se ricordi, nella lezione,

574
00:41:07,590 --> 00:41:10,685
ti avevo mostrato la struttura del token Web JSON

575
00:41:10,685 --> 00:41:14,290
e ti avevo mostrato che il token Web JSON contiene tre parti: l'intestazione,

576
00:41:14,290 --> 00:41:18,040
il payload e le informazioni lì.

577
00:41:18,040 --> 00:41:19,730
Ora, in questo caso,

578
00:41:19,730 --> 00:41:25,880
le informazioni sono qui, quindi

579
00:41:25,880 --> 00:41:33,285
incollerò il mio token Web JSON in questo lato sinistro,

580
00:41:33,285 --> 00:41:37,270
quindi lasciami selezionarlo e quindi incollare

581
00:41:37,270 --> 00:41:41,920
il mio token Web JSON nel lato sinistro nella parte codificata e poi sul lato destro,

582
00:41:41,920 --> 00:41:46,030
ti sta mostrando esattamente ciò che è all'interno del token Web JSON che ho appena creato.

583
00:41:46,030 --> 00:41:49,580
Quindi, dice che l'intestazione contiene queste due informazioni.

584
00:41:49,580 --> 00:41:54,090
Il payload avviso che contiene l'ID

585
00:41:54,090 --> 00:41:59,245
dell'utente e quindi la firma in basso qui.

586
00:41:59,245 --> 00:42:03,995
Quindi, questo è ciò che è contenuto all'interno del mio token Web JSON.

587
00:42:03,995 --> 00:42:07,005
Tornando al Postman,

588
00:42:07,005 --> 00:42:12,110
fammi provare a prendere i piatti.

589
00:42:12,110 --> 00:42:15,940
Quindi, quando dico GET localhost: 3000/piatti,

590
00:42:15,940 --> 00:42:18,650
restituirà comunque una stringa

591
00:42:18,650 --> 00:42:23,385
vuota, array vuoto qui perché il mio database non lo contiene.

592
00:42:23,385 --> 00:42:29,635
Quindi, lasciami POST un piatto sul mio database.

593
00:42:29,635 --> 00:42:33,290
Quindi, ho intenzione di scegliere l'operazione POST e nel corpo,

594
00:42:33,290 --> 00:42:36,095
vedi che ho il mio piatto qui.

595
00:42:36,095 --> 00:42:41,215
Nell' intestazione, ho intenzione di aggiungere la nuova intestazione chiamata

596
00:42:41,215 --> 00:42:47,240
autorizzazione e si ricorda che in precedenza per l'autorizzazione di base,

597
00:42:47,240 --> 00:42:53,425
hai detto di base e poi hai avuto la stringa codificata Base 64 lì.

598
00:42:53,425 --> 00:42:58,970
Se si desidera includere il token Web JSON nell'intestazione di autorizzazione,

599
00:42:58,970 --> 00:43:01,150
perché nel nostro codice,

600
00:43:01,150 --> 00:43:04,550
abbiamo detto autorizzazione come token portatore.

601
00:43:04,550 --> 00:43:08,040
Quindi, se si desidera includere il token nell'intestazione di autorizzazione,

602
00:43:08,040 --> 00:43:13,275
nell'autorizzazione diremo portatore e poi incolleremo quella

603
00:43:13,275 --> 00:43:19,080
stringa di token che abbiamo appena copiato dalla nostra richiesta in arrivo.

604
00:43:19,080 --> 00:43:21,935
Quindi, incolleremo la stringa di token lì dentro.

605
00:43:21,935 --> 00:43:24,360
Quindi, questo è ciò che sarà contenuto

606
00:43:24,360 --> 00:43:29,795
nell'intestazione di autorizzazione della mia richiesta in uscita qui,

607
00:43:29,795 --> 00:43:33,845
richiesta POST in uscita qui.

608
00:43:33,845 --> 00:43:39,970
Quindi nota, il lato sinistro dice portatore e il lato destro è la stringa,

609
00:43:39,970 --> 00:43:43,230
il token che ho appena copiato dal

610
00:43:43,230 --> 00:43:48,460
punto in cui ho effettuato l'accesso e poi lasciami inviare il messaggio POST

611
00:43:48,460 --> 00:43:57,590
ora e il mio POST ha successo e questo viene pubblicato nel mio database.

612
00:43:57,590 --> 00:44:01,115
Ora, se vuoi essere sicuro che sia stato pubblicato,

613
00:44:01,115 --> 00:44:04,555
facciamo un GET e quando fai un GET,

614
00:44:04,555 --> 00:44:12,935
puoi vedere che effettivamente quel piatto è stato inserito nel mio database come mostrato qui.

615
00:44:12,935 --> 00:44:19,260
Quindi, questo è il modo in cui userai i token Web JSON nella tua applicazione.

616
00:44:19,260 --> 00:44:22,230
Quindi, ogni volta che è necessario eseguire un'

617
00:44:22,230 --> 00:44:25,505
operazione POST, PUT o DELETE su uno qualsiasi degli endpoint,

618
00:44:25,505 --> 00:44:27,010
si sta allegando.

619
00:44:27,010 --> 00:44:33,895
Quindi, lasciami tornare a questa richiesta POST qui.

620
00:44:33,895 --> 00:44:35,890
Nell' intestazione, inserirai

621
00:44:35,890 --> 00:44:41,540
questo campo di autorizzazione e quindi questo verrebbe incluso nell'autorizzazione,

622
00:44:41,540 --> 00:44:47,540
lo avvierai con il portatore e poi la stringa di token,

623
00:44:47,540 --> 00:44:50,200
dopo quello spazio portatore,

624
00:44:50,200 --> 00:44:54,215
un singolo spazio e poi la stringa di token che segue.

625
00:44:54,215 --> 00:44:58,310
Quindi, ecco come i messaggi di richiesta

626
00:44:58,310 --> 00:45:03,140
porterebbero il token Web JSON nell'intestazione del messaggio di richiesta in uscita.

627
00:45:03,140 --> 00:45:08,220
È inoltre possibile includere il token nel corpo del messaggio di richiesta in uscita.

628
00:45:08,220 --> 00:45:10,310
Ora, per questo, dovrai configurare

629
00:45:10,310 --> 00:45:18,210
il tuo server express in particolare il JWT extra nel

630
00:45:18,210 --> 00:45:21,120
file authenticate.js per accettarlo

631
00:45:21,120 --> 00:45:24,455
dal corpo in modo da ricordare che lì abbiamo visto che

632
00:45:24,455 --> 00:45:28,890
il JWT extra supporta molti modi diversi di estrarre

633
00:45:28,890 --> 00:45:33,695
il token Web JSON dall' richiesta.

634
00:45:33,695 --> 00:45:35,090
Quindi, lì è necessario specificare,

635
00:45:35,090 --> 00:45:36,670
se hai intenzione di includerlo nel corpo,

636
00:45:36,670 --> 00:45:39,115
è necessario specificare tali informazioni lì.

637
00:45:39,115 --> 00:45:42,395
Ora, i dettagli su come farlo è possibile consultare

638
00:45:42,395 --> 00:45:49,885
la documentazione del modulo Passport JWT per capire come questo è fatto.

639
00:45:49,885 --> 00:45:54,610
In questo corso, ho intenzione di usarlo semplicemente nell'intestazione di autorizzazione

640
00:45:54,610 --> 00:45:59,835
come ho mostrato qui e questo funziona bene per la maggior parte dei casi.

641
00:45:59,835 --> 00:46:02,620
Ora, se si sta sviluppando un'app Web,

642
00:46:02,620 --> 00:46:06,635
un'app angolare o un'app Ionic o NativeScript,

643
00:46:06,635 --> 00:46:09,800
è necessario essere in grado di configurare

644
00:46:09,800 --> 00:46:16,615
tale app in cui il token Web JSON verrà incluso nell'intestazione di autorizzazione.

645
00:46:16,615 --> 00:46:22,215
Nell' ultima lezione di questo corso,

646
00:46:22,215 --> 00:46:26,255
vi mostrerò come integrare il client e il server,

647
00:46:26,255 --> 00:46:29,310
il client che avete sviluppato nei corsi precedenti con

648
00:46:29,310 --> 00:46:32,495
il server che abbiamo sviluppato in questo corso.

649
00:46:32,495 --> 00:46:35,120
Con questo, completiamo questo esercizio.

650
00:46:35,120 --> 00:46:37,940
In questo esercizio, abbiamo visto come

651
00:46:37,940 --> 00:46:42,200
possiamo configurare la nostra applicazione per utilizzare JSON Web Tokens,

652
00:46:42,200 --> 00:46:50,555
e abbiamo visto come gestiamo l'autenticazione dell'utente utilizzando il token Web JSON,

653
00:46:50,555 --> 00:46:55,555
utilizzando il supporto dal modulo Passport e il modulo Passport JWT,

654
00:46:55,555 --> 00:46:58,605
e i moduli JSON Web Token Node.

655
00:46:58,605 --> 00:47:01,090
Con questo, completiamo questo esercizio.

656
00:47:01,090 --> 00:47:09,110
Questo è un buon momento per fare un Git Commit con il messaggio Passport JWT.