1 00:00:01,140 --> 00:00:03,050 ‫Jonas: Ora continuiamo a scrivere la 2 00:00:03,050 --> 00:00:04,773 ‫nostra funzione middleware di protezione. 3 00:00:06,420 --> 00:00:08,910 ‫Quindi, nell'ultima lezione, abbiamo letto il 4 00:00:08,910 --> 00:00:10,990 ‫token dall'intestazione di autorizzazione e 5 00:00:10,990 --> 00:00:14,080 ‫quindi abbiamo verificato se il token esiste effettivamente. 6 00:00:14,080 --> 00:00:15,023 ‫Quindi proprio qui. 7 00:00:15,880 --> 00:00:19,890 ‫E poi, abbiamo il passaggio di verifica per il token. 8 00:00:19,890 --> 00:00:21,880 ‫E spero che tu ricordi che 9 00:00:21,880 --> 00:00:24,520 ‫in questo passaggio verifichiamo se qualcuno ha manipolato 10 00:00:24,520 --> 00:00:27,500 ‫i dati o anche se il token è già scaduto. 11 00:00:27,500 --> 00:00:31,840 ‫Quindi abbiamo già usato, dal pacchetto token web JSON, la funzione di 12 00:00:31,840 --> 00:00:33,180 ‫assegnazione della funzione, 13 00:00:33,180 --> 00:00:35,623 ‫e ora useremo la funzione di verifica. 14 00:00:36,820 --> 00:00:39,333 ‫Quindi, proprio come prima, jwt. verifica, e poi 15 00:00:43,000 --> 00:00:46,630 ‫lì dentro, come puoi immaginare, passiamo il token in modo che 16 00:00:46,630 --> 00:00:49,160 ‫l'algoritmo possa leggere il payload e quindi 17 00:00:49,160 --> 00:00:52,133 ‫ricordare che anche questo passaggio ha bisogno del segreto. 18 00:00:53,250 --> 00:00:56,870 ‫Quindi, in pratica, per creare la firma di prova. 19 00:00:56,870 --> 00:01:00,743 ‫Quindi quel segreto è il processo. avv. JWT_SECRET. 20 00:01:03,470 --> 00:01:04,610 ‫Ricordati che? 21 00:01:04,610 --> 00:01:05,860 ‫Ora, come terzo 22 00:01:05,860 --> 00:01:09,003 ‫argomento, questa funzione richiede effettivamente una funzione di callback. 23 00:01:10,090 --> 00:01:12,180 ‫Quindi questa richiamata verrà eseguita 24 00:01:12,180 --> 00:01:14,850 ‫non appena la verifica sarà stata completata. 25 00:01:14,850 --> 00:01:16,840 ‫Quindi vedi che questa verifica 26 00:01:16,840 --> 00:01:19,564 ‫qui è in realtà una funzione asincrona. 27 00:01:19,564 --> 00:01:22,540 ‫Quindi verificherà un token e poi, 28 00:01:22,540 --> 00:01:23,620 ‫al termine, 29 00:01:23,620 --> 00:01:27,040 ‫chiamerà la funzione di callback che possiamo specificare. 30 00:01:27,040 --> 00:01:29,910 ‫Ora, abbiamo lavorato con le promesse tutto 31 00:01:29,910 --> 00:01:33,159 ‫il tempo, e non voglio davvero rompere questo schema qui. 32 00:01:33,159 --> 00:01:37,000 ‫E così, in realtà promettiamo questa funzione. 33 00:01:37,000 --> 00:01:40,370 ‫Quindi, in sostanza, per farlo tornare una promessa. 34 00:01:40,370 --> 00:01:42,660 ‫In questo modo, possiamo quindi utilizzare async 35 00:01:42,660 --> 00:01:45,613 ‫wait proprio come qualsiasi altra funzione asincrona che abbiamo utilizzato. 36 00:01:46,820 --> 00:01:48,050 ‫Quindi, per fare 37 00:01:48,050 --> 00:01:51,050 ‫ciò, Node ha effettivamente una funzione di promessa incorporata. 38 00:01:51,050 --> 00:01:53,650 ‫Tutto quello che dobbiamo fare per 39 00:01:53,650 --> 00:01:56,663 ‫usarlo è richiedere il modulo util integrato. 40 00:01:58,695 --> 00:02:00,895 ‫Quindi facciamolo proprio in cima, in realtà. 41 00:02:02,900 --> 00:02:07,900 ‫In questo modo verrà creato un oggetto chiamato util, require... 42 00:02:10,740 --> 00:02:13,400 ‫Va bene, quindi sta per utilità. 43 00:02:13,400 --> 00:02:15,420 ‫Non è quello che volevo. 44 00:02:15,420 --> 00:02:16,960 ‫Quindi sta per utilità. 45 00:02:16,960 --> 00:02:20,300 ‫E poi là, useremo il metodo promisify. 46 00:02:20,300 --> 00:02:22,900 ‫Ma dal momento che useremo solo quell'unico metodo, 47 00:02:22,900 --> 00:02:24,603 ‫possiamo effettivamente farlo più facilmente. 48 00:02:25,578 --> 00:02:26,990 ‫Quindi, invece 49 00:02:26,990 --> 00:02:30,610 ‫di farlo, possiamo semplicemente destrutturare quell'oggetto e prendere 50 00:02:30,610 --> 00:02:32,823 ‫la promessa direttamente da lì. 51 00:02:35,388 --> 00:02:38,453 ‫Quindi, di nuovo, si tratta solo di utilizzare la destrutturazione ES6. 52 00:02:41,182 --> 00:02:43,230 ‫Ok, così e ora è molto facile da usare. 53 00:02:43,230 --> 00:02:46,127 ‫Tutto ciò che dobbiamo fare è effettivamente chiamare promisify. 54 00:02:47,434 --> 00:02:51,463 ‫Quindi prometti e poi passa la funzione lì dentro. 55 00:02:53,500 --> 00:02:56,080 ‫E così ora, tutto questo qui è una 56 00:02:56,080 --> 00:02:56,970 ‫funzione che 57 00:02:56,970 --> 00:02:59,190 ‫dobbiamo chiamare, che poi restituirà una promessa. 58 00:02:59,190 --> 00:03:01,810 ‫Quindi qui, chiamiamo effettivamente la funzione. 59 00:03:01,810 --> 00:03:03,900 ‫E questo restituirà quindi una 60 00:03:03,900 --> 00:03:08,300 ‫promessa, quindi possiamo aspettarla e memorizzare il risultato in una variabile. 61 00:03:08,300 --> 00:03:10,390 ‫Quindi quel valore del risultato della 62 00:03:10,390 --> 00:03:12,350 ‫promessa sarà effettivamente i dati 63 00:03:12,350 --> 00:03:15,823 ‫decodificati, quindi il payload decodificato da questo token Web JSON. 64 00:03:17,600 --> 00:03:19,360 ‫Quindi lascia che lo chiami decodificato qui. 65 00:03:19,360 --> 00:03:20,193 ‫Va bene. 66 00:03:20,193 --> 00:03:23,490 ‫E possiamo aspettare perché in realtà abbiamo già detto 67 00:03:23,490 --> 00:03:25,453 ‫che è una funzione asincrona. 68 00:03:27,670 --> 00:03:30,850 ‫E ora, solo per vedere che 69 00:03:30,850 --> 00:03:34,730 ‫funziona davvero, registriamo anche questi dati decodificati sulla console. 70 00:03:34,730 --> 00:03:38,143 ‫E in realtà, possiamo rimuovere questa console. disconnettere il token. 71 00:03:39,050 --> 00:03:40,400 ‫Quello di cui non abbiamo più bisogno. 72 00:03:42,140 --> 00:03:46,560 ‫Quindi proviamo a inviare di nuovo questa richiesta, e sì, ma 73 00:03:46,560 --> 00:03:49,990 ‫questa volta attivando effettivamente questa intestazione di 74 00:03:49,990 --> 00:03:54,850 ‫autorizzazione in modo da inviare un token Web JSON insieme alla richiesta. 75 00:03:54,850 --> 00:03:55,940 ‫Quindi questo l'ha mandato. 76 00:03:55,940 --> 00:03:58,540 ‫E ora, in effetti, abbiamo accesso 77 00:03:58,540 --> 00:04:02,070 ‫ai dati, quindi ora abbiamo accesso al percorso protetto. 78 00:04:02,070 --> 00:04:02,903 ‫Va bene? 79 00:04:02,903 --> 00:04:06,203 ‫Ma quello che volevo vedere è questo oggetto decodificato qui. 80 00:04:07,230 --> 00:04:09,910 ‫E quindi questo qui dovrebbe essere l'ID utente. 81 00:04:09,910 --> 00:04:12,530 ‫Quindi diamo un'occhiata di nuovo a Postman. 82 00:04:12,530 --> 00:04:13,423 ‫Quindi 62a42. 83 00:04:15,520 --> 00:04:18,740 ‫E quindi, in effetti, bene, dove lo abbiamo? 84 00:04:18,740 --> 00:04:20,193 ‫Diamo un'occhiata a Compass. 85 00:04:21,240 --> 00:04:24,813 ‫E infatti, l'ID di questo utente è questo 62a42. 86 00:04:27,160 --> 00:04:29,347 ‫E quindi questo significa che qui abbiamo 87 00:04:29,347 --> 00:04:31,340 ‫effettivamente il nostro carico utile corretto. 88 00:04:31,340 --> 00:04:33,420 ‫Quindi, in pratica, l'ID utente corretto. 89 00:04:33,420 --> 00:04:36,460 ‫Abbiamo poi anche il timestamp della data di 90 00:04:36,460 --> 00:04:39,500 ‫creazione e della data di scadenza del token. 91 00:04:39,500 --> 00:04:40,700 ‫Quindi questo funziona. 92 00:04:40,700 --> 00:04:43,710 ‫Ma ora proviamo effettivamente a manipolare il payload di 93 00:04:43,710 --> 00:04:44,563 ‫questo token. 94 00:04:47,088 --> 00:04:49,090 ‫Quindi copiamolo di nuovo qui. 95 00:04:49,090 --> 00:04:52,443 ‫Ma poi vado al debugger JWT. 96 00:04:54,640 --> 00:04:57,023 ‫Quindi di nuovo, a jwt. io. 97 00:05:00,290 --> 00:05:02,363 ‫Quindi portiamolo via. 98 00:05:03,310 --> 00:05:06,010 ‫E ora quello che farò è cambiare alcuni 99 00:05:06,010 --> 00:05:09,260 ‫dati qui e questo cambierà il token codificato qui, che posso 100 00:05:09,260 --> 00:05:11,010 ‫quindi andare avanti e copiare. 101 00:05:12,420 --> 00:05:14,693 ‫Quindi sostituiamo semplicemente, in 102 00:05:15,580 --> 00:05:19,050 ‫realtà, sostituirò questi due numeri qui con 103 00:05:19,050 --> 00:05:20,940 ‫qualcosa di diverso. 104 00:05:20,940 --> 00:05:23,590 ‫E così, come vedi, questo ha cambiato il token qui. 105 00:05:23,590 --> 00:05:26,040 ‫E così ora, proverò effettivamente ad 106 00:05:26,040 --> 00:05:27,470 ‫accedere a quel 107 00:05:27,470 --> 00:05:30,373 ‫percorso protetto usando questo token web JSON manipolato. 108 00:05:31,460 --> 00:05:33,133 ‫Ok, ha senso? 109 00:05:34,100 --> 00:05:37,023 ‫Quindi solo per vedere se funziona correttamente. 110 00:05:38,632 --> 00:05:39,970 ‫Quindi sto copiando 111 00:05:39,970 --> 00:05:42,660 ‫questo qui ora e incollando quest'altro diverso. 112 00:05:42,660 --> 00:05:47,310 ‫Quindi, se ora invio questa richiesta, otteniamo un errore. 113 00:05:47,310 --> 00:05:48,250 ‫Quindi, fantastico. 114 00:05:48,250 --> 00:05:50,843 ‫Quindi, vediamo che il nome dell'errore è JsonWebTokenError 115 00:05:51,840 --> 00:05:54,220 ‫e abbiamo una firma non valida. 116 00:05:54,220 --> 00:05:55,160 ‫Quindi, fantastico. 117 00:05:55,160 --> 00:05:57,650 ‫È esattamente quello che stavamo cercando. 118 00:05:57,650 --> 00:06:00,210 ‫Quindi questo è uno dei due errori che possono verificarsi. 119 00:06:00,210 --> 00:06:02,853 ‫L'altro è che il token è già scaduto. 120 00:06:04,359 --> 00:06:07,180 ‫Quindi questo si chiama JsonWebTokenError e 121 00:06:07,180 --> 00:06:10,890 ‫quindi, in realtà, andiamo avanti e gestiamo questo errore ora. 122 00:06:10,890 --> 00:06:12,240 ‫E il modo 123 00:06:12,240 --> 00:06:16,470 ‫in cui potremmo farlo è aggiungere un blocco try-catch proprio qui. 124 00:06:16,470 --> 00:06:17,460 ‫Destra? 125 00:06:17,460 --> 00:06:19,600 ‫Quindi, subito dopo aver eseguito questo 126 00:06:19,600 --> 00:06:21,510 ‫codice, potremmo introdurre un 127 00:06:21,510 --> 00:06:24,260 ‫blocco try e quindi nel catch creeremmo errori 128 00:06:24,260 --> 00:06:26,290 ‫che sarebbero stati inviati al client. 129 00:06:26,290 --> 00:06:28,070 ‫Ora, invece di farlo in 130 00:06:28,070 --> 00:06:30,970 ‫questo modo, in realtà voglio usare il nostro middleware di 131 00:06:30,970 --> 00:06:33,290 ‫gestione degli errori globale per farlo per noi. 132 00:06:33,290 --> 00:06:35,850 ‫Quindi non ci piace gestire gli errori proprio qui 133 00:06:35,850 --> 00:06:37,220 ‫nella nostra funzione middleware. 134 00:06:37,220 --> 00:06:41,140 ‫Invece, di solito lo deleghiamo al controller degli errori. 135 00:06:41,140 --> 00:06:43,940 ‫E quindi, facciamo la stessa identica cosa qui. 136 00:06:43,940 --> 00:06:46,710 ‫Quindi controller di errore. 137 00:06:46,710 --> 00:06:48,600 ‫E poi è esattamente la stessa 138 00:06:48,600 --> 00:06:50,930 ‫cosa che abbiamo con i nostri altri errori qui. 139 00:06:50,930 --> 00:06:54,210 ‫Quindi, ad esempio, l'errore di convalida proviene da Mongoose, 140 00:06:54,210 --> 00:06:55,670 ‫quindi da un'altra libreria. 141 00:06:55,670 --> 00:06:59,060 ‫E ora, questo errore proviene in realtà da un'altra 142 00:06:59,060 --> 00:07:02,180 ‫libreria e ha anche il suo nome. 143 00:07:02,180 --> 00:07:03,470 ‫Quindi prendiamolo. 144 00:07:03,470 --> 00:07:04,820 ‫Ed è JsonWebTokenError. 145 00:07:06,900 --> 00:07:07,940 ‫Va bene. 146 00:07:07,940 --> 00:07:09,923 ‫E così, facciamo molto simile qui. 147 00:07:11,850 --> 00:07:12,683 ‫Quindi se. name 148 00:07:15,477 --> 00:07:19,310 ‫è questo, allora l'errore dovrebbe essere uguale a gestire l'errore. 149 00:07:19,310 --> 00:07:23,463 ‫Va bene. 150 00:07:27,010 --> 00:07:27,843 ‫Quindi andiamo avanti 151 00:07:27,843 --> 00:07:30,430 ‫e creiamo questa funzione, in realtà, da qualche parte quassù. 152 00:07:30,430 --> 00:07:31,953 ‫E questo è in realtà estremamente semplice. 153 00:07:35,782 --> 00:07:37,810 ‫Tutto ciò che fa è accettare un errore 154 00:07:37,810 --> 00:07:39,760 ‫e quindi restituire un nuovo AppError. 155 00:07:39,760 --> 00:07:41,433 ‫Va bene? 156 00:07:44,480 --> 00:07:45,320 ‫Quindi in 157 00:07:45,320 --> 00:07:48,950 ‫questa funzione freccia ES6, come spero tu sappia, possiamo scrivere queste righe 158 00:07:48,950 --> 00:07:50,790 ‫in cui non dobbiamo nemmeno specificare 159 00:07:50,790 --> 00:07:53,610 ‫le parentesi graffe e nemmeno la parola chiave return. 160 00:07:53,610 --> 00:07:55,610 ‫Quindi questo restituirà automaticamente 161 00:07:55,610 --> 00:07:58,670 ‫e implicitamente tutto ciò che abbiamo inserito qui. 162 00:07:58,670 --> 00:08:00,123 ‫Destra? 163 00:08:01,010 --> 00:08:01,843 ‫Quindi, quello 164 00:08:01,843 --> 00:08:04,763 ‫che vogliamo dire qui è semplicemente, token non valido, per 165 00:08:05,980 --> 00:08:07,273 ‫favore accedi di nuovo. 166 00:08:09,580 --> 00:08:12,640 ‫E poi, il codice di errore, proprio come prima, 167 00:08:12,640 --> 00:08:15,000 ‫è un 401 per Non autorizzato. 168 00:08:15,000 --> 00:08:17,463 ‫Ora, questo funziona solo, ricorda, in produzione. 169 00:08:19,497 --> 00:08:22,410 ‫E quindi, se lo facessimo di nuovo ora, 170 00:08:22,410 --> 00:08:24,883 ‫otterremmo esattamente la stessa cosa. 171 00:08:24,883 --> 00:08:27,730 ‫E quindi, torniamo qui ed eseguiamo 172 00:08:27,730 --> 00:08:29,890 ‫questo in produzione. 173 00:08:29,890 --> 00:08:32,340 ‫Quindi npm run start:production. 174 00:08:32,340 --> 00:08:37,340 ‫Sì, proprio così. 175 00:08:39,470 --> 00:08:40,733 ‫Quindi, se proviamo di 176 00:08:41,650 --> 00:08:43,890 ‫nuovo ora, vediamo se otteniamo il nostro errore. 177 00:08:43,890 --> 00:08:45,630 ‫E infatti, lo facciamo. 178 00:08:45,630 --> 00:08:47,840 ‫Quindi se, in questo momento, un utente in produzione 179 00:08:47,840 --> 00:08:50,040 ‫tenta di accedere alla nostra app con 180 00:08:50,040 --> 00:08:52,930 ‫un token non valido, beh, riceve solo questo messaggio di errore. 181 00:08:52,930 --> 00:08:55,890 ‫Va bene? 182 00:08:55,890 --> 00:08:57,120 ‫Quindi questo è il primo errore che possiamo ottenere. 183 00:08:57,120 --> 00:08:59,920 ‫Ma un altro è che l'utente tenta 184 00:08:59,920 --> 00:09:01,560 ‫di accedere all'applicazione 185 00:09:01,560 --> 00:09:03,500 ‫con un token già scaduto. 186 00:09:03,500 --> 00:09:06,147 ‫E quindi, ora proviamo a creare quell'errore. 187 00:09:06,147 --> 00:09:08,733 ‫E per farlo, cambierò 188 00:09:09,683 --> 00:09:13,080 ‫il tempo necessario alla scadenza del token. 189 00:09:13,080 --> 00:09:14,943 ‫Quindi adesso abbiamo 90 giorni. 190 00:09:17,811 --> 00:09:19,190 ‫Mettiamolo a tipo cinque secondi. 191 00:09:19,190 --> 00:09:22,183 ‫Va bene. 192 00:09:23,078 --> 00:09:23,911 ‫Dagli un salvataggio. 193 00:09:23,911 --> 00:09:24,870 ‫E ora prova ad accedere di nuovo. 194 00:09:24,870 --> 00:09:26,823 ‫Quindi salviamo anche questo qui. 195 00:09:28,090 --> 00:09:30,943 ‫Quindi, negli utenti, quindi accedi. 196 00:09:32,920 --> 00:09:37,043 ‫Quindi possiamo accedere e quindi ci darà un nuovo token, 197 00:09:39,060 --> 00:09:43,100 ‫ma questo token è valido solo per cinque secondi. 198 00:09:43,100 --> 00:09:46,100 ‫E così, questi cinque secondi dovrebbero essere passati a questo punto. 199 00:09:46,100 --> 00:09:49,550 ‫Quindi ora copierò questo token e proverò ad accedere al 200 00:09:49,550 --> 00:09:51,690 ‫nostro percorso protetto utilizzando quel token. 201 00:09:51,690 --> 00:09:55,713 ‫Quindi incollalo qui. 202 00:09:58,529 --> 00:09:59,362 ‫E ora, vediamo cosa otteniamo. 203 00:09:59,362 --> 00:10:01,630 ‫E in effetti, per qualche ragione, ha funzionato. 204 00:10:01,630 --> 00:10:04,280 ‫Quindi diamo di nuovo un'occhiata al nostro debugger JWT. 205 00:10:04,280 --> 00:10:08,593 ‫E dice, creato il 2 maggio, ma scade 206 00:10:11,620 --> 00:10:14,160 ‫solo il 31 luglio. 207 00:10:14,160 --> 00:10:16,720 ‫Quindi qualcosa è andato storto nella creazione del token, immagino. 208 00:10:16,720 --> 00:10:21,023 ‫E quindi, cambiamo questo di nuovo qui. 209 00:10:22,140 --> 00:10:23,810 ‫E ne metterò solo cinque qui. 210 00:10:23,810 --> 00:10:25,993 ‫Quindi, quel cinque dovrebbe stare 211 00:10:27,270 --> 00:10:30,340 ‫per cinque millisecondi, o posso anche, tipo, mettere 212 00:10:30,340 --> 00:10:32,630 ‫5000, che dovrebbe essere cinque secondi. 213 00:10:32,630 --> 00:10:34,733 ‫Va bene. 214 00:10:37,680 --> 00:10:38,890 ‫Quindi permettetemi di salvarlo di nuovo ora per riavviare il server. 215 00:10:38,890 --> 00:10:42,363 ‫Ritenta. 216 00:10:43,240 --> 00:10:44,570 ‫Quindi accedi di nuovo qui. 217 00:10:44,570 --> 00:10:46,113 ‫Va bene. 218 00:10:47,680 --> 00:10:48,600 ‫Quindi ora tutto 219 00:10:48,600 --> 00:10:52,930 ‫ciò che dobbiamo fare è sostanzialmente aspettare cinque secondi, e quel tempo dovrebbe essere già passato a questo punto. 220 00:10:52,930 --> 00:10:56,933 ‫Incollalo di nuovo qui. 221 00:11:00,230 --> 00:11:01,500 ‫E andiamo. 222 00:11:01,500 --> 00:11:03,560 ‫E infatti, otteniamo un errore. 223 00:11:03,560 --> 00:11:05,860 ‫Ora ricorda come questo è 224 00:11:05,860 --> 00:11:09,850 ‫fondamentalmente l'errore standard che otteniamo nel caso in cui non 225 00:11:09,850 --> 00:11:13,230 ‫gestiamo correttamente quell'errore nella nostra gestione degli errori. 226 00:11:13,230 --> 00:11:14,700 ‫Destra? 227 00:11:14,700 --> 00:11:15,750 ‫Quindi diamo un'occhiata all'errore. 228 00:11:15,750 --> 00:11:18,840 ‫E in realtà, l'abbiamo qui nella console. 229 00:11:18,840 --> 00:11:21,350 ‫Quindi vediamo da dove viene. 230 00:11:21,350 --> 00:11:24,620 ‫E sì, viene da questo posto. 231 00:11:24,620 --> 00:11:26,673 ‫Quindi questo è il caso in cui abbiamo un errore sconosciuto. 232 00:11:27,760 --> 00:11:31,690 ‫Ricorda, quindi un errore che non è contrassegnato 233 00:11:31,690 --> 00:11:34,090 ‫come errore operativo e quindi 234 00:11:34,090 --> 00:11:35,640 ‫vogliamo registrarlo. 235 00:11:35,640 --> 00:11:37,543 ‫Quindi lo registriamo qui e poi 236 00:11:38,500 --> 00:11:39,650 ‫inviamo questo messaggio di 237 00:11:39,650 --> 00:11:42,150 ‫errore generico al client, quindi quello che abbiamo appena 238 00:11:42,150 --> 00:11:43,270 ‫visto in Postman. 239 00:11:43,270 --> 00:11:45,610 ‫Ma qui abbiamo effettivamente i dettagli di questo errore. 240 00:11:45,610 --> 00:11:48,100 ‫E così, questo ha il nome di TokenExpiredError. 241 00:11:48,100 --> 00:11:51,480 ‫Va bene. 242 00:11:51,480 --> 00:11:52,313 ‫E quindi, ora gestiamo anche questo. 243 00:11:52,313 --> 00:11:55,360 ‫Quindi lo sto copiando ora e poi ne creo 244 00:11:55,360 --> 00:11:57,171 ‫solo un altro se qui. 245 00:11:57,171 --> 00:12:02,171 ‫Quindi se l'errore. name è uguale a questo, beh 246 00:12:02,300 --> 00:12:07,300 ‫allora, diciamo, handleJWTEpiredError 247 00:12:08,980 --> 00:12:10,343 ‫con 248 00:12:12,711 --> 00:12:14,461 ‫la freccia. 249 00:12:18,640 --> 00:12:20,233 ‫Copiamolo e mettiamolo qui. 250 00:12:22,568 --> 00:12:25,750 ‫E quindi questo, ovviamente, è molto simile a quello precedente. 251 00:12:33,186 --> 00:12:37,770 ‫Il tuo token è scaduto. 252 00:12:37,770 --> 00:12:40,493 ‫Per favore esegui l'accesso di nuovo. 253 00:12:43,940 --> 00:12:45,193 ‫E ancora, con un codice di errore 401. 254 00:12:48,670 --> 00:12:51,423 ‫Ok, proviamo di nuovo. 255 00:12:52,360 --> 00:12:54,270 ‫E quindi, questo è esattamente il messaggio di 256 00:12:54,270 --> 00:12:56,043 ‫errore che ora dovremmo vedere qui. 257 00:12:56,043 --> 00:12:58,023 ‫Va bene. 258 00:12:59,430 --> 00:13:00,263 ‫E infatti lo è. 259 00:13:00,263 --> 00:13:01,263 ‫Grande. 260 00:13:02,480 --> 00:13:03,520 ‫Finiamo il processo qui 261 00:13:03,520 --> 00:13:04,980 ‫e avviamolo in modalità dev, ovviamente. 262 00:13:04,980 --> 00:13:07,560 ‫Quindi npm 263 00:13:07,560 --> 00:13:10,213 ‫inizia, e va bene. 264 00:13:11,700 --> 00:13:13,740 ‫Quindi questo non ci serve altro, quindi chiudiamolo. 265 00:13:13,740 --> 00:13:17,460 ‫O in realtà, correggiamo questo piccolo errore qui, perché in effetti 266 00:13:17,460 --> 00:13:19,880 ‫non usiamo affatto questo errore qui. 267 00:13:19,880 --> 00:13:23,113 ‫Quindi liberiamocene. 268 00:13:24,170 --> 00:13:25,423 ‫E poi quaggiù, non abbiamo bisogno di passarlo lì dentro. 269 00:13:29,260 --> 00:13:32,063 ‫Freddo. 270 00:13:39,290 --> 00:13:40,123 ‫Ovviamente, dobbiamo anche riportarlo a 90 giorni. 271 00:13:41,060 --> 00:13:44,423 ‫Va bene. 272 00:13:47,200 --> 00:13:48,040 ‫E 273 00:13:48,040 --> 00:13:51,560 ‫così, giusto per essere davvero sicuri, accediamo di nuovo 274 00:13:51,560 --> 00:13:52,803 ‫qui, copiamo il 275 00:13:53,830 --> 00:13:55,513 ‫token e mettiamolo qui. 276 00:13:56,680 --> 00:13:59,050 ‫Ora, questo processo qui di copiare il 277 00:13:59,050 --> 00:14:01,750 ‫token e poi incollarlo qui in questa intestazione può 278 00:14:01,750 --> 00:14:04,190 ‫sembrare un po' strano, e in realtà lo 279 00:14:04,190 --> 00:14:05,640 ‫sistemeremo in uno 280 00:14:05,640 --> 00:14:07,230 ‫dei video futuri in modo 281 00:14:07,230 --> 00:14:09,030 ‫che fondamentalmente questo processo avvenga automaticamente. 282 00:14:09,030 --> 00:14:12,070 ‫Ma ora, l'importante è che sia effettivamente 283 00:14:12,070 --> 00:14:13,970 ‫tornato a funzionare ora. 284 00:14:13,970 --> 00:14:16,750 ‫Quindi possiamo effettivamente sbarazzarci di questa console. accedi qui e vai 285 00:14:16,750 --> 00:14:21,027 ‫al passaggio successivo. 286 00:14:21,027 --> 00:14:24,250 ‫E potremmo davvero fermarci qui ora, se volessimo. 287 00:14:24,250 --> 00:14:27,010 ‫E ancora, la maggior parte dei tutorial 288 00:14:27,010 --> 00:14:30,130 ‫che scoprirai là, in effetti, si fermerebbe qui. 289 00:14:30,130 --> 00:14:32,420 ‫Ma questo non è ancora abbastanza sicuro. 290 00:14:32,420 --> 00:14:35,210 ‫Quindi, ad esempio, cosa succede se l'utente 291 00:14:35,210 --> 00:14:37,550 ‫è stato cancellato nel frattempo? 292 00:14:37,550 --> 00:14:39,840 ‫Quindi il token esisterà ancora, ma se 293 00:14:39,840 --> 00:14:41,800 ‫l'utente non esiste più, allora 294 00:14:41,800 --> 00:14:43,900 ‫in realtà non vogliamo accedervi, giusto? 295 00:14:43,900 --> 00:14:47,780 ‫O ancora peggio, cosa succede se l'utente ha effettivamente cambiato 296 00:14:47,780 --> 00:14:50,070 ‫la sua password dopo che il 297 00:14:50,070 --> 00:14:52,130 ‫token è stato emesso? 298 00:14:52,130 --> 00:14:54,360 ‫Bene, anche questo non dovrebbe funzionare, giusto? 299 00:14:54,360 --> 00:14:56,950 ‫Ad esempio, immagina che qualcuno 300 00:14:56,950 --> 00:15:00,750 ‫abbia rubato il token Web JSON da un utente. 301 00:15:00,750 --> 00:15:01,870 ‫Ma poi, per 302 00:15:01,870 --> 00:15:04,380 ‫proteggersi da ciò, l'utente cambia la sua password. 303 00:15:04,380 --> 00:15:06,770 ‫E quindi, ovviamente, quel vecchio token emesso prima 304 00:15:06,770 --> 00:15:09,270 ‫della modifica della password non dovrebbe più essere valido. 305 00:15:09,270 --> 00:15:12,940 ‫Quindi non dovrebbe essere accettato di accedere a percorsi protetti. 306 00:15:12,940 --> 00:15:16,906 ‫E quindi, questo è il tipo di cose che implementeremo 307 00:15:16,906 --> 00:15:19,550 ‫qui nei passaggi tre e quattro. 308 00:15:19,550 --> 00:15:22,060 ‫Quindi la prima cosa da fare è verificare se 309 00:15:22,060 --> 00:15:23,120 ‫l'utente esiste ancora. 310 00:15:23,120 --> 00:15:26,060 ‫E così, quello dovrebbe essere il più facile. 311 00:15:26,060 --> 00:15:28,690 ‫Quindi diciamo solo, Utente. trova per ID. 312 00:15:28,690 --> 00:15:32,463 ‫E quindi, questo è il motivo 313 00:15:36,568 --> 00:15:38,440 ‫per cui abbiamo effettivamente 314 00:15:38,440 --> 00:15:40,540 ‫l'ID nel payload, perché ora possiamo usare 315 00:15:40,540 --> 00:15:42,767 ‫quell'ID e interrogare l'utente usando solo quell'ID. 316 00:15:42,767 --> 00:15:46,530 ‫Così decodificato. ID. 317 00:15:46,530 --> 00:15:49,390 ‫Va bene? 318 00:15:49,390 --> 00:15:50,223 ‫Quindi dovrebbe quindi trovare il nuovo utente. 319 00:15:50,223 --> 00:15:53,110 ‫E, naturalmente, dobbiamo aspettarlo e quindi 320 00:15:53,110 --> 00:15:55,860 ‫memorizzarlo in una variabile. 321 00:15:55,860 --> 00:15:59,560 ‫Lo chiamo il freshUser. 322 00:15:59,560 --> 00:16:01,480 ‫Va bene? 323 00:16:03,148 --> 00:16:03,981 ‫Perché non è davvero un nuovo utente. 324 00:16:03,981 --> 00:16:05,460 ‫Questo è solo quando ne creiamo uno. 325 00:16:05,460 --> 00:16:07,300 ‫Ma questo non è davvero nuovo, è 326 00:16:07,300 --> 00:16:09,030 ‫solo l'utente basato sull'ID decodificato. 327 00:16:09,030 --> 00:16:12,980 ‫Va bene? 328 00:16:12,980 --> 00:16:13,870 ‫E possiamo 329 00:16:13,870 --> 00:16:16,833 ‫farlo in modo da essere sicuri al 100% che l'ID 330 00:16:16,833 --> 00:16:18,990 ‫sia effettivamente corretto, perché se lo abbiamo 331 00:16:18,990 --> 00:16:22,460 ‫fatto fino a questo punto del codice qui, significa che il processo 332 00:16:22,460 --> 00:16:25,110 ‫di verifica che abbiamo precedentemente, qui, ha avuto successo. 333 00:16:25,110 --> 00:16:28,200 ‫In caso contrario, ciò avrebbe causato un errore 334 00:16:28,200 --> 00:16:30,220 ‫che avrebbe poi impedito il 335 00:16:30,220 --> 00:16:31,490 ‫proseguimento della funzione. 336 00:16:31,490 --> 00:16:33,410 ‫E quindi, di nuovo, 337 00:16:33,410 --> 00:16:36,660 ‫questo processo di verifica qui è responsabile della verifica 338 00:16:36,660 --> 00:16:38,620 ‫se nessuno ha alterato l'ID che 339 00:16:38,620 --> 00:16:40,900 ‫si trova nel payload di questo token. 340 00:16:40,900 --> 00:16:43,033 ‫E quindi, per questo motivo, 341 00:16:43,970 --> 00:16:46,970 ‫possiamo essere sicuri al 100% che l'utente per il quale 342 00:16:46,970 --> 00:16:50,600 ‫abbiamo emesso il JWT è esattamente quello il cui ID è 343 00:16:50,600 --> 00:16:52,790 ‫ora all'interno del payload decodificato, quindi questo. 344 00:16:52,790 --> 00:16:56,810 ‫Va bene? 345 00:16:56,810 --> 00:16:57,690 ‫Quindi il processo di verifica è davvero fondamentale. 346 00:16:57,690 --> 00:17:00,440 ‫È davvero ciò che fa funzionare tutto questo. 347 00:17:00,440 --> 00:17:02,440 ‫Ad ogni modo, ora ciò che dobbiamo fare è 348 00:17:04,730 --> 00:17:06,410 ‫verificare se esiste effettivamente un freshUser. 349 00:17:06,410 --> 00:17:09,570 ‫E se no, allora, ovviamente, restituiremo 350 00:17:09,570 --> 00:17:11,570 ‫un nuovo errore. 351 00:17:11,570 --> 00:17:13,844 ‫Quindi, se non c'è freshUser, 352 00:17:13,844 --> 00:17:16,577 ‫torna da questo middleware e chiama quello 353 00:17:19,880 --> 00:17:22,100 ‫successivo con un errore. 354 00:17:22,100 --> 00:17:24,083 ‫Quindi questo è uno schema che abbiamo 355 00:17:24,920 --> 00:17:27,100 ‫visto più e più volte a questo punto, giusto? 356 00:17:27,100 --> 00:17:29,403 ‫Quindi il token non esiste 357 00:17:30,350 --> 00:17:31,490 ‫più. 358 00:17:35,470 --> 00:17:39,173 ‫E in effetti è il contrario. 359 00:17:40,810 --> 00:17:42,750 ‫Quindi, in realtà, l'utente 360 00:17:42,750 --> 00:17:45,200 ‫appartenente al token non esiste più. 361 00:17:47,170 --> 00:17:48,680 ‫Destra? 362 00:17:48,680 --> 00:17:49,513 ‫E poi il 401. 363 00:17:49,513 --> 00:17:51,297 ‫Va bene. 364 00:17:53,780 --> 00:17:54,920 ‫Quindi testiamolo ancora una volta. 365 00:17:54,920 --> 00:17:57,860 ‫E creiamo effettivamente un nuovo utente per quello. 366 00:17:57,860 --> 00:18:00,843 ‫Quindi prova solo con la stessa password, quindi usiamo sempre 367 00:18:02,620 --> 00:18:04,880 ‫la stessa qui solo per rendere il nostro 368 00:18:04,880 --> 00:18:06,590 ‫test un po' più semplice. 369 00:18:06,590 --> 00:18:09,160 ‫E so che tutti questi test qui 370 00:18:09,160 --> 00:18:11,070 ‫fanno impiegare molto tempo al 371 00:18:11,070 --> 00:18:14,440 ‫video, ma ovviamente è molto importante testare tutto ciò che 372 00:18:14,440 --> 00:18:15,900 ‫facciamo, specialmente in 373 00:18:15,900 --> 00:18:17,950 ‫un argomento così importante come l'autenticazione. 374 00:18:17,950 --> 00:18:21,713 ‫Quindi ora sto usando questo JWT qui, quindi 375 00:18:23,071 --> 00:18:27,780 ‫lo incollo qui, ma ovviamente, prima di inviare la richiesta, 376 00:18:27,780 --> 00:18:30,630 ‫andrò avanti ed eliminerò immediatamente quell'utente. 377 00:18:30,630 --> 00:18:33,573 ‫Va bene? 378 00:18:34,650 --> 00:18:35,690 ‫Quindi, di nuovo, supponiamo che 379 00:18:35,690 --> 00:18:37,690 ‫qualcuno abbia creato un utente e poi abbia effettuato l'accesso, 380 00:18:37,690 --> 00:18:40,020 ‫e diciamo che, dopo un po' di tempo, l'utente è stato eliminato. 381 00:18:40,020 --> 00:18:43,500 ‫Ma nel frattempo, qualcuno potrebbe aver avuto accesso a quel 382 00:18:43,500 --> 00:18:44,333 ‫JWT 383 00:18:44,333 --> 00:18:47,410 ‫e ora potrebbe provare ad accedere come quell'utente 384 00:18:47,410 --> 00:18:50,030 ‫che è stato, in effetti, già eliminato. 385 00:18:50,030 --> 00:18:52,580 ‫E quindi, ancora una volta, non dovremmo permettere che ciò accada. 386 00:18:52,580 --> 00:18:55,520 ‫Quindi permettetemi di eliminare questo utente qui ora. 387 00:18:55,520 --> 00:18:57,713 ‫E ci siamo. 388 00:18:59,010 --> 00:18:59,943 ‫E quindi, proviamolo ora. 389 00:19:01,720 --> 00:19:03,630 ‫E ancora, tieni presente che l'utente 390 00:19:03,630 --> 00:19:07,060 ‫appartenente all'ID che è in questo payload ora non è più lì. 391 00:19:07,060 --> 00:19:10,690 ‫Quindi vediamo. 392 00:19:10,690 --> 00:19:12,040 ‫E infatti, riceviamo questo messaggio di errore che abbiamo appena creato. 393 00:19:12,040 --> 00:19:16,313 ‫Quindi anche quello funziona. 394 00:19:17,520 --> 00:19:20,200 ‫E andiamo all'ultimo. 395 00:19:20,200 --> 00:19:22,400 ‫Quindi, passaggio numero quattro, controlla se l'utente ha 396 00:19:22,400 --> 00:19:23,830 ‫modificato di recente la password. 397 00:19:23,830 --> 00:19:27,070 ‫Quindi, in pratica, dopo l'emissione del token. 398 00:19:27,070 --> 00:19:30,100 ‫E per implementare questo test, creeremo effettivamente un altro 399 00:19:30,100 --> 00:19:31,550 ‫metodo di istanza. 400 00:19:31,550 --> 00:19:34,260 ‫Quindi, in pratica, un metodo 401 00:19:34,260 --> 00:19:37,030 ‫che sarà disponibile su tutti i documenti. 402 00:19:37,030 --> 00:19:38,330 ‫Quindi i documenti sono istanze di un modello. 403 00:19:38,330 --> 00:19:41,410 ‫Va bene? 404 00:19:41,410 --> 00:19:42,243 ‫E lo facciamo perché 405 00:19:42,243 --> 00:19:44,490 ‫è un bel po' di codice di cui abbiamo bisogno per questa verifica. 406 00:19:44,490 --> 00:19:46,540 ‫E quindi, in realtà, questo 407 00:19:46,540 --> 00:19:50,040 ‫codice appartiene al modello Utente e non proprio al controller. 408 00:19:50,040 --> 00:19:51,970 ‫Va bene? 409 00:19:51,970 --> 00:19:52,803 ‫E quindi, 410 00:19:52,803 --> 00:19:55,050 ‫facciamolo come abbiamo fatto prima per controllare la password. 411 00:19:55,050 --> 00:19:57,270 ‫Quindi nel modello utente, abbiamo già 412 00:19:57,270 --> 00:19:59,840 ‫implementato questo metodo di istanza statica CorrectPassword, ricordi? 413 00:19:59,840 --> 00:20:04,710 ‫E così, ora creiamone un altro. 414 00:20:04,710 --> 00:20:06,903 ‫Quindi userSchema. metodi. password modificataDopo. 415 00:20:08,339 --> 00:20:13,339 ‫Quindi funzione, e in 416 00:20:22,390 --> 00:20:24,550 ‫questa funzione passeremo il timestamp JWT. 417 00:20:24,550 --> 00:20:27,530 ‫Quindi, in pratica, quel timestamp che dice quando 418 00:20:27,530 --> 00:20:29,630 ‫è stato emesso il token. 419 00:20:29,630 --> 00:20:32,190 ‫Quindi chiamiamolo JWTTimestamp. 420 00:20:32,190 --> 00:20:34,437 ‫Va bene. 421 00:20:40,310 --> 00:20:41,143 ‫E per impostazione predefinita, restituiremo false da questo metodo. 422 00:20:41,143 --> 00:20:44,600 ‫E ciò significherà che l'utente non ha cambiato 423 00:20:44,600 --> 00:20:45,720 ‫la sua 424 00:20:45,720 --> 00:20:48,320 ‫password dopo l'emissione del token. 425 00:20:48,320 --> 00:20:50,410 ‫Va bene? 426 00:20:50,410 --> 00:20:51,860 ‫Quindi mettiamolo qui, return false, fondamentalmente per impostazione predefinita. 427 00:20:51,860 --> 00:20:56,860 ‫Va bene. 428 00:20:58,470 --> 00:20:59,303 ‫Ma poi, 429 00:20:59,303 --> 00:21:02,987 ‫abbiamo anche if this, e ricordiamo che in un metodo di istanza, 430 00:21:02,987 --> 00:21:05,827 ‫la parola chiave this punta sempre al documento corrente. 431 00:21:05,827 --> 00:21:09,477 ‫E quindi, qui abbiamo accesso alle proprietà. 432 00:21:09,477 --> 00:21:13,210 ‫Ora, abbiamo effettivamente bisogno di creare un campo ora nel nostro schema per 433 00:21:13,210 --> 00:21:16,280 ‫la data in cui la password è stata modificata. 434 00:21:16,280 --> 00:21:18,750 ‫Quindi non l'abbiamo ancora. 435 00:21:18,750 --> 00:21:20,050 ‫Quindi aggiungiamolo rapidamente qui. 436 00:21:21,200 --> 00:21:23,713 ‫Quindi passwordChangedAt e il tipo 437 00:21:25,980 --> 00:21:27,813 ‫sarà un Date. 438 00:21:31,320 --> 00:21:34,520 ‫Ora, questa proprietà passwordChangedAt qui 439 00:21:34,520 --> 00:21:37,890 ‫verrà sempre modificata, ovviamente, quando qualcuno 440 00:21:37,890 --> 00:21:40,160 ‫cambia la password. 441 00:21:40,160 --> 00:21:42,910 ‫Quindi in questo momento, non abbiamo quella logica da nessuna parte, e 442 00:21:42,910 --> 00:21:45,270 ‫quindi da nessuna parte stiamo effettivamente definendo questa proprietà. 443 00:21:45,270 --> 00:21:48,743 ‫E così, la maggior parte dei documenti, quindi 444 00:21:49,630 --> 00:21:53,230 ‫la maggior parte degli utenti, semplicemente non avranno questa 445 00:21:53,230 --> 00:21:56,720 ‫proprietà nei loro dati, quindi nel loro oggetto, giusto? 446 00:21:56,720 --> 00:21:58,600 ‫E quindi, ovviamente, dobbiamo testarlo. 447 00:21:58,600 --> 00:22:01,363 ‫Va bene? 448 00:22:03,430 --> 00:22:04,610 ‫Quindi, se la 449 00:22:04,610 --> 00:22:07,740 ‫proprietà passwordChangedAt esiste, solo allora vogliamo fare effettivamente il confronto. 450 00:22:07,740 --> 00:22:11,510 ‫Va bene? 451 00:22:11,510 --> 00:22:12,343 ‫Ma se 452 00:22:12,343 --> 00:22:16,010 ‫no, quindi se passwordChanged non esiste, allora significa che l'utente non 453 00:22:16,010 --> 00:22:17,640 ‫ha mai effettivamente cambiato la 454 00:22:17,640 --> 00:22:20,020 ‫password, e quindi possiamo semplicemente restituire false. 455 00:22:20,020 --> 00:22:23,171 ‫Quindi, di nuovo, questa è la nostra impostazione predefinita, 456 00:22:23,171 --> 00:22:25,560 ‫il che significa che l'utente non 457 00:22:25,560 --> 00:22:28,190 ‫ha cambiato la password dopo questo timestamp. 458 00:22:28,190 --> 00:22:30,540 ‫Va bene. 459 00:22:30,540 --> 00:22:31,373 ‫E 460 00:22:31,373 --> 00:22:35,760 ‫ora, solo per iniziare, accediamo effettivamente alla console. passwordChangedAt e, naturalmente, anche JWTTimestamp, solo così 461 00:22:35,760 --> 00:22:37,933 ‫possiamo 462 00:22:39,370 --> 00:22:42,010 ‫vedere come possiamo confrontarli. 463 00:22:42,010 --> 00:22:44,950 ‫Va bene. 464 00:22:44,950 --> 00:22:45,783 ‫E ora dobbiamo 465 00:22:47,560 --> 00:22:49,690 ‫creare effettivamente un utente che abbia questa proprietà, ok? 466 00:22:49,690 --> 00:22:52,720 ‫E ancora, più avanti nella sezione quando implementeremo 467 00:22:52,720 --> 00:22:54,260 ‫la logica per 468 00:22:54,260 --> 00:22:57,280 ‫cambiare la password è quando imposteremo questa proprietà. 469 00:22:57,280 --> 00:22:59,760 ‫Va bene? 470 00:22:59,760 --> 00:23:00,593 ‫Ma ora 471 00:23:00,593 --> 00:23:04,140 ‫lo imposteremo artificialmente, fondamentalmente, qui quando creiamo un nuovo utente. 472 00:23:04,140 --> 00:23:06,260 ‫Va bene? 473 00:23:06,260 --> 00:23:07,093 ‫Quindi mettiamolo qui. 474 00:23:08,690 --> 00:23:10,130 ‫E qui, qualsiasi data, in realtà, servirà. 475 00:23:10,130 --> 00:23:12,810 ‫Quindi diciamo il 30 aprile 2019 qui. 476 00:23:12,810 --> 00:23:17,810 ‫E quindi dovrebbe essere analizzato bene in MongoDB. 477 00:23:18,430 --> 00:23:21,313 ‫Proviamo, vediamo se funziona. 478 00:23:22,460 --> 00:23:24,293 ‫E questo non ha funzionato. 479 00:23:25,210 --> 00:23:26,520 ‫Quindi non potrebbe davvero analizzare la data, diciamo. 480 00:23:26,520 --> 00:23:29,913 ‫E in realtà, devo iniziare con l'anno e 481 00:23:30,980 --> 00:23:33,710 ‫poi il giorno alla fine. 482 00:23:33,710 --> 00:23:36,400 ‫Quindi il 2019 e poi il 30 aprile. 483 00:23:36,400 --> 00:23:41,050 ‫Riprova. 484 00:23:41,050 --> 00:23:42,103 ‫E così vedi che ora funziona davvero. 485 00:23:43,190 --> 00:23:45,300 ‫Quindi abbiamo questa data analizzata qui. 486 00:23:45,300 --> 00:23:48,210 ‫Va bene? 487 00:23:48,210 --> 00:23:49,350 ‫Ora, per vedere effettivamente 488 00:23:49,350 --> 00:23:51,910 ‫il risultato di ciò, dobbiamo ovviamente chiamare questo metodo. 489 00:23:51,910 --> 00:23:55,040 ‫Va bene? 490 00:23:55,040 --> 00:23:56,560 ‫Quindi è quello che faremo qui al punto quattro. 491 00:23:56,560 --> 00:23:59,033 ‫Va bene? 492 00:24:00,010 --> 00:24:01,110 ‫E quindi, ricorda 493 00:24:01,110 --> 00:24:04,630 ‫che possiamo chiamare questo metodo di istanza su un documento utente. 494 00:24:04,630 --> 00:24:06,200 ‫Così frescoUtente. changePasswordAfter, e poi 495 00:24:06,200 --> 00:24:09,197 ‫quel timestamp. 496 00:24:14,837 --> 00:24:17,370 ‫Quindi questo è decodificato. iat, così emesso a, fondamentalmente. 497 00:24:17,370 --> 00:24:22,370 ‫Va bene. 498 00:24:25,450 --> 00:24:26,350 ‫Quindi vediamo semplicemente il risultato di farlo. 499 00:24:26,350 --> 00:24:29,130 ‫E quindi, ovviamente, questo dovrebbe ora, non 500 00:24:29,130 --> 00:24:32,953 ‫qui, quindi ora dovrebbe registrare nella console questi due valori. 501 00:24:33,870 --> 00:24:37,123 ‫Va bene. 502 00:24:39,320 --> 00:24:40,153 ‫Ora, ovviamente, 503 00:24:40,153 --> 00:24:43,170 ‫ho bisogno di accedere esattamente con questo utente, quindi con 504 00:24:43,170 --> 00:24:44,223 ‫test, quindi eccoci qui. 505 00:24:47,780 --> 00:24:48,853 ‫Accesso. 506 00:24:50,250 --> 00:24:51,173 ‫Copia di nuovo questo token qui. 507 00:24:53,090 --> 00:24:56,200 ‫E ancora, fondamentalmente lo 508 00:24:56,200 --> 00:24:59,580 ‫automatizzeremo nel prossimo video, in realtà. 509 00:24:59,580 --> 00:25:01,233 ‫Va bene. 510 00:25:02,740 --> 00:25:03,700 ‫Incollalo qui. 511 00:25:03,700 --> 00:25:04,673 ‫E ora, abbiamo effettivamente questo bug qui. 512 00:25:05,670 --> 00:25:08,312 ‫Quindi ho appena scritto male questo nome di funzione qui. 513 00:25:08,312 --> 00:25:13,312 ‫Bene, copiamolo e basta. 514 00:25:13,670 --> 00:25:14,920 ‫Ritenta. 515 00:25:16,410 --> 00:25:17,403 ‫Oddio. 516 00:25:18,780 --> 00:25:20,150 ‫Cosa c'è che non va adesso? 517 00:25:20,150 --> 00:25:21,823 ‫E vedo che ho semplicemente dimenticato questo registro qui. 518 00:25:25,420 --> 00:25:27,633 ‫Quindi un altro stupido errore. 519 00:25:28,752 --> 00:25:30,090 ‫Probabilmente l'ha visto arrivare. 520 00:25:30,090 --> 00:25:32,320 ‫Ma ora ci siamo. 521 00:25:32,320 --> 00:25:33,550 ‫Quindi tutto ha 522 00:25:33,550 --> 00:25:35,120 ‫funzionato bene e tutto ciò che 523 00:25:35,120 --> 00:25:37,450 ‫volevamo davvero vedere per ora erano questi due risultati. 524 00:25:37,450 --> 00:25:39,560 ‫Quindi fondamentalmente abbiamo questo qui con questo 525 00:25:39,560 --> 00:25:43,110 ‫formato di data, e poi l'altro in questo millisecondo o secondo 526 00:25:43,110 --> 00:25:43,943 ‫timestamp qui. 527 00:25:43,943 --> 00:25:47,600 ‫E quindi, ora dobbiamo convertire questa 528 00:25:47,600 --> 00:25:51,670 ‫passwordChangedAt anche in un timestamp del genere. 529 00:25:51,670 --> 00:25:54,240 ‫Va bene? 530 00:25:54,240 --> 00:25:55,073 ‫E quindi, per questo, creiamo una nuova variabile. 531 00:25:55,073 --> 00:25:57,853 ‫Così cambiatoTimestamp. 532 00:25:59,560 --> 00:26:01,330 ‫E possiamo usare questo. passwordCambiataAt. prendi tempo. 533 00:26:03,800 --> 00:26:06,100 ‫Va bene? 534 00:26:12,730 --> 00:26:13,563 ‫E quindi, 535 00:26:13,563 --> 00:26:16,913 ‫questa è una delle tante, molte funzioni di data che JavaScript ci offre. 536 00:26:16,913 --> 00:26:18,563 ‫Va bene. 537 00:26:19,450 --> 00:26:20,960 ‫E ora confrontiamo rapidamente questi 538 00:26:20,960 --> 00:26:23,760 ‫due perché non siamo ancora del tutto pronti, in realtà. 539 00:26:23,760 --> 00:26:26,253 ‫Quindi l'invio solo per vedere i risultati qui. 540 00:26:28,770 --> 00:26:31,930 ‫E quindi quello che vediamo qui fondamentalmente è che 541 00:26:31,930 --> 00:26:33,610 ‫questo qui è 542 00:26:33,610 --> 00:26:36,580 ‫ora, fondamentalmente, in secondi, e questo in millisecondi. 543 00:26:36,580 --> 00:26:38,210 ‫Quindi è 1000 volte di più. 544 00:26:38,210 --> 00:26:40,540 ‫E quindi, sappiamo che dobbiamo dividerlo per 545 00:26:40,540 --> 00:26:43,340 ‫1000 e poi analizzare l'intera cosa come un numero intero. 546 00:26:45,630 --> 00:26:48,583 ‫E per questo, usiamo parseInt. 547 00:26:50,550 --> 00:26:52,820 ‫Quindi un'altra funzione JavaScript disponibile per i numeri. 548 00:26:52,820 --> 00:26:57,180 ‫E poi in realtà dobbiamo anche specificare la base. 549 00:26:57,180 --> 00:27:00,320 ‫Quindi questo è un numero in base 10. 550 00:27:00,320 --> 00:27:02,920 ‫Va bene? 551 00:27:02,920 --> 00:27:03,970 ‫E così ora, vediamo di nuovo il risultato. 552 00:27:03,970 --> 00:27:07,373 ‫E ora, sembra molto più amichevole. 553 00:27:10,120 --> 00:27:13,360 ‫Va bene. 554 00:27:13,360 --> 00:27:14,193 ‫E così, ora restituiamo effettivamente il nostro risultato. 555 00:27:14,193 --> 00:27:17,040 ‫E ancora, tieni presente che falso significa non cambiato. 556 00:27:17,040 --> 00:27:22,040 ‫Va bene? 557 00:27:24,500 --> 00:27:25,520 ‫E non 558 00:27:25,520 --> 00:27:30,207 ‫modificato significa sostanzialmente che il giorno o l'ora in cui è stato emesso il 559 00:27:32,300 --> 00:27:34,240 ‫token è inferiore al timestamp modificato. 560 00:27:34,240 --> 00:27:37,893 ‫Va bene? 561 00:27:40,280 --> 00:27:41,113 ‫Quindi, solo per fare un esempio 562 00:27:44,330 --> 00:27:45,830 ‫qui, supponiamo che il token sia stato emesso al momento 100. 563 00:27:45,830 --> 00:27:49,327 ‫Ma poi, abbiamo cambiato la password, diciamo, al tempo 200. 564 00:27:50,460 --> 00:27:53,843 ‫Va bene? 565 00:27:55,240 --> 00:27:56,073 ‫E così, abbiamo 566 00:27:56,073 --> 00:27:57,609 ‫cambiato la password dopo che il 567 00:27:57,609 --> 00:27:59,840 ‫token è stato emesso, e quindi, questo è ora vero. 568 00:27:59,840 --> 00:28:01,940 ‫Va bene? 569 00:28:01,940 --> 00:28:03,379 ‫Ed è proprio quello che vogliamo 570 00:28:03,379 --> 00:28:04,810 ‫restituire qui, perché falso 571 00:28:04,810 --> 00:28:06,910 ‫significa non cambiato, e quindi vero, ovviamente, significa cambiato. 572 00:28:06,910 --> 00:28:09,200 ‫E quindi, è esattamente quello che abbiamo qui. 573 00:28:09,200 --> 00:28:11,980 ‫Ma ora, diciamo che la password è 574 00:28:11,980 --> 00:28:13,410 ‫stata modificata l'ultima 575 00:28:13,410 --> 00:28:15,810 ‫volta a 200, ma solo dopo 576 00:28:15,810 --> 00:28:18,640 ‫abbiamo emesso il token, quindi diciamo, all'ora 300. 577 00:28:18,640 --> 00:28:21,260 ‫E quindi, 300, meno di 200? 578 00:28:21,260 --> 00:28:23,660 ‫No, è falso. 579 00:28:23,660 --> 00:28:25,160 ‫E così, torniamo false, che di nuovo significa non cambiato. 580 00:28:25,160 --> 00:28:29,200 ‫E quindi, ecco perché usiamo questo segno meno qui. 581 00:28:29,200 --> 00:28:32,720 ‫Va bene? 582 00:28:32,720 --> 00:28:33,553 ‫Torniamo al nostro controller e usiamo effettivamente questo. 583 00:28:36,800 --> 00:28:41,800 ‫Quindi, se la password è stata effettivamente modificata, beh, 584 00:28:45,480 --> 00:28:49,910 ‫in questo caso, vogliamo effettivamente un errore. 585 00:28:49,910 --> 00:28:53,030 ‫Quindi torna dopo, di nuovo, un nuovo AppError. 586 00:28:53,030 --> 00:28:57,623 ‫Recentemente... 587 00:29:02,970 --> 00:29:04,220 ‫Per favore esegui l'accesso di nuovo. 588 00:29:11,790 --> 00:29:13,620 ‫Va bene. 589 00:29:13,620 --> 00:29:15,030 ‫E ancora una volta il codice 401. 590 00:29:15,030 --> 00:29:18,363 ‫Va bene. 591 00:29:19,770 --> 00:29:20,820 ‫Quindi, di nuovo, 592 00:29:20,820 --> 00:29:23,220 ‫questo tornerà vero se l'utente ha effettivamente cambiato la password. 593 00:29:23,220 --> 00:29:25,790 ‫E quindi, se tutto questo qui è vero, 594 00:29:25,790 --> 00:29:28,540 ‫beh, allora proprio in quel caso è quando vogliamo 595 00:29:28,540 --> 00:29:30,600 ‫che si verifichi questo errore. 596 00:29:30,600 --> 00:29:33,220 ‫Va bene? 597 00:29:33,220 --> 00:29:34,820 ‫Quindi questo era in realtà l'ultimo passo. 598 00:29:34,820 --> 00:29:37,510 ‫Va bene. 599 00:29:37,510 --> 00:29:38,952 ‫Quindi, in pratica, se il codice può arrivare 600 00:29:38,952 --> 00:29:41,030 ‫fino alla fine di questo codice qui, solo allora verrà eseguito il prossimo. 601 00:29:41,030 --> 00:29:45,410 ‫E poi, con next, andiamo al gestore di 602 00:29:45,410 --> 00:29:49,100 ‫route successivo, che significa effettivamente concedere l'accesso 603 00:29:49,100 --> 00:29:51,470 ‫a quella route protetta. 604 00:29:51,470 --> 00:29:52,783 ‫In realtà mettiamolo qui. 605 00:29:53,750 --> 00:29:55,740 ‫Concedere l'accesso al percorso protetto. 606 00:29:55,740 --> 00:30:00,740 ‫Va bene? 607 00:30:02,340 --> 00:30:03,597 ‫Perché questo è davvero tutto ciò che fa il prossimo. 608 00:30:03,597 --> 00:30:05,310 ‫Successivamente ci porta al prossimo 609 00:30:05,310 --> 00:30:08,070 ‫middleware, che di solito è, quindi, il gestore di route 610 00:30:08,070 --> 00:30:10,880 ‫stesso, quindi quello che restituisce i dati che sono stati protetti. 611 00:30:10,880 --> 00:30:14,550 ‫Va bene. 612 00:30:14,550 --> 00:30:15,383 ‫Solo un'ultima cosa 613 00:30:15,383 --> 00:30:18,540 ‫che vogliamo fare qui è effettivamente inserire tutti i dati dell'utente nella richiesta. 614 00:30:18,540 --> 00:30:22,930 ‫Quindi possiamo semplicemente dire, req, quindi request, . user sarà uguale a 615 00:30:22,930 --> 00:30:27,100 ‫freshUser. 616 00:30:27,100 --> 00:30:30,510 ‫Va bene. 617 00:30:30,510 --> 00:30:31,343 ‫E ancora, ovviamente, 618 00:30:31,343 --> 00:30:32,430 ‫il codice raggiunge questo 619 00:30:32,430 --> 00:30:34,930 ‫punto solo qui nel caso in cui tutto sia corretto. 620 00:30:34,930 --> 00:30:37,470 ‫Va bene? 621 00:30:37,470 --> 00:30:38,303 ‫E quindi, 622 00:30:38,303 --> 00:30:40,710 ‫questo qui potrebbe essere utile in futuro. 623 00:30:40,710 --> 00:30:42,110 ‫Grande. 624 00:30:43,150 --> 00:30:43,983 ‫Proviamolo ancora una volta. 625 00:30:43,983 --> 00:30:46,450 ‫E fondamentalmente, questo cambiamento è nel passato ora. 626 00:30:46,450 --> 00:30:51,450 ‫E quindi, questo token che abbiamo qui, o in realtà, 627 00:30:51,820 --> 00:30:53,840 ‫avrei potuto riutilizzare 628 00:30:53,840 --> 00:30:56,890 ‫solo questo invece di registrarlo di nuovo. 629 00:30:56,890 --> 00:30:58,520 ‫Ma comunque, questo token è 630 00:30:58,520 --> 00:31:00,500 ‫stato emesso dopo la modifica della password. 631 00:31:00,500 --> 00:31:02,344 ‫E quindi, questo token ora dovrebbe funzionare. 632 00:31:02,344 --> 00:31:04,920 ‫Quindi accediamo di nuovo 633 00:31:04,920 --> 00:31:07,500 ‫e proviamo con questo token. 634 00:31:10,900 --> 00:31:13,203 ‫E infatti, otteniamo l'accesso. 635 00:31:18,020 --> 00:31:20,030 ‫Ora, spostati su Compass per cambiare quella data. 636 00:31:20,030 --> 00:31:22,853 ‫Va bene. 637 00:31:24,511 --> 00:31:26,010 ‫Mettiamolo un mese dopo. 638 00:31:26,010 --> 00:31:27,657 ‫E così, sarà davvero 639 00:31:27,657 --> 00:31:30,780 ‫in futuro, almeno nel mio futuro quando registrerò questo video. 640 00:31:30,780 --> 00:31:34,150 ‫Ovviamente lo farai in un secondo momento. 641 00:31:34,150 --> 00:31:36,640 ‫E quindi, per testarlo, per favore mettilo nel tuo futuro. 642 00:31:36,640 --> 00:31:40,373 ‫Quindi nel futuro della data in cui stai 643 00:31:41,420 --> 00:31:43,060 ‫guardando questo video. 644 00:31:43,060 --> 00:31:44,710 ‫Quindi, se ora 645 00:31:45,960 --> 00:31:50,960 ‫torno a Postman e accedo di nuovo, ok, quindi se accedo di nuovo ora 646 00:31:53,860 --> 00:31:56,430 ‫e provo ad accedere a quel percorso, 647 00:31:56,430 --> 00:31:58,710 ‫beh, questo token verrà emesso, in 648 00:31:58,710 --> 00:32:01,420 ‫pratica, dopo che la password è stata modificata. 649 00:32:01,420 --> 00:32:03,553 ‫O addirittura prima che la password sia stata modificata. 650 00:32:08,680 --> 00:32:10,590 ‫Quindi, scusa per questa confusione. 651 00:32:10,590 --> 00:32:12,610 ‫Quindi la password è stata cambiata il 30 652 00:32:12,610 --> 00:32:15,800 ‫maggio, ma questo token è stato emesso il 2 maggio, e così, prima. 653 00:32:15,800 --> 00:32:19,650 ‫Quindi, in pratica, ora è come se l'utente avesse cambiato la 654 00:32:19,650 --> 00:32:21,950 ‫password dopo l'emissione del token. 655 00:32:21,950 --> 00:32:25,880 ‫E quindi, questa è esattamente la situazione in cui non vogliamo dare 656 00:32:25,880 --> 00:32:27,341 ‫accesso al percorso protetto. 657 00:32:27,341 --> 00:32:31,070 ‫E quindi, questo dovrebbe ora riflettere quello. 658 00:32:31,070 --> 00:32:35,170 ‫E infatti, l'utente ha cambiato la password di 659 00:32:35,170 --> 00:32:38,740 ‫recente, per favore accedi di nuovo. 660 00:32:38,740 --> 00:32:40,280 ‫Grande. 661 00:32:40,280 --> 00:32:41,240 ‫Quindi ora funziona. 662 00:32:41,240 --> 00:32:42,953 ‫Quindi il nostro middleware di protezione è ora completamente implementato. 663 00:32:43,870 --> 00:32:48,000 ‫Eliminiamo questa console. accedi qui. 664 00:32:48,000 --> 00:32:51,620 ‫Non ho più bisogno di quello. 665 00:32:51,620 --> 00:32:53,820 ‫E va bene. 666 00:32:53,820 --> 00:32:55,800 ‫Quindi ricapitoliamo rapidamente, e questo video 667 00:32:55,800 --> 00:32:57,230 ‫è molto lungo, un 668 00:32:57,230 --> 00:32:59,520 ‫po' più lungo di quanto mi aspettassi. 669 00:32:59,520 --> 00:33:01,330 ‫Ma è davvero 670 00:33:01,330 --> 00:33:03,820 ‫importante capire e spiegare come 671 00:33:03,820 --> 00:33:06,700 ‫funziona tutto questo e perché è importante. 672 00:33:06,700 --> 00:33:07,810 ‫E quindi, lo preferisco piuttosto che fare questo video molto più breve. 673 00:33:07,810 --> 00:33:12,710 ‫Certo, potrei semplicemente scrivere il codice, ma poi non capiresti davvero 674 00:33:12,710 --> 00:33:14,127 ‫cosa sta succedendo. 675 00:33:14,127 --> 00:33:17,330 ‫Quindi questa parte l'abbiamo già capita. 676 00:33:17,330 --> 00:33:19,410 ‫Quindi questa parte, credo anche io, 677 00:33:19,410 --> 00:33:21,680 ‫quindi è qui che avviene la verifica, quindi 678 00:33:21,680 --> 00:33:24,060 ‫in pratica vedendo se il payload del token 679 00:33:24,060 --> 00:33:26,570 ‫non è stato manipolato da una terza parte dannosa. 680 00:33:26,570 --> 00:33:30,900 ‫Va bene? 681 00:33:30,900 --> 00:33:31,733 ‫E poiché 682 00:33:31,733 --> 00:33:33,730 ‫raggiungiamo questo codice qui, significa che nessuno ha 683 00:33:33,730 --> 00:33:36,790 ‫modificato il token Web JSON e quindi possiamo ottenere un nuovo utente. 684 00:33:36,790 --> 00:33:39,350 ‫Quindi, in pratica, possiamo ottenere l'utente 685 00:33:39,350 --> 00:33:41,690 ‫corrente, chiamiamolo effettivamente currentUser. 686 00:33:41,690 --> 00:33:43,650 ‫Perchè no? 687 00:33:43,650 --> 00:33:44,483 ‫Quindi qui, qui e anche qui. 688 00:33:45,450 --> 00:33:47,993 ‫Va bene? 689 00:33:49,670 --> 00:33:50,503 ‫Quindi possiamo ottenere 690 00:33:50,503 --> 00:33:53,020 ‫l'utente corrente da quell'ID che è stato appena decodificato dal payload. 691 00:33:53,020 --> 00:33:55,023 ‫Ora, se currentUser non esiste, quindi 692 00:33:56,100 --> 00:33:58,260 ‫questo è ciò che stiamo testando 693 00:33:58,260 --> 00:34:00,660 ‫qui, beh, in quel caso non vogliamo 694 00:34:00,660 --> 00:34:01,990 ‫dare accesso al 695 00:34:01,990 --> 00:34:04,290 ‫percorso e invece creiamo questo nuovo errore. 696 00:34:04,290 --> 00:34:06,343 ‫Ma se l'utente esiste, beh, 697 00:34:07,400 --> 00:34:08,870 ‫allora arriviamo al 698 00:34:08,870 --> 00:34:12,030 ‫punto numero quattro, dove controlliamo se è avvenuta una 699 00:34:12,030 --> 00:34:15,060 ‫modifica della password dopo l'emissione del token, giusto? 700 00:34:15,060 --> 00:34:18,060 ‫E se lo ha fatto, poi di nuovo, creiamo un nuovo errore. 701 00:34:18,060 --> 00:34:21,200 ‫E se non lo fa, beh, allora arriviamo 702 00:34:21,200 --> 00:34:22,720 ‫fino alla fine 703 00:34:22,720 --> 00:34:24,460 ‫della funzione middleware, dove 704 00:34:24,460 --> 00:34:26,750 ‫assegniamo l'utente corrente alla richiesta. user in modo da poterlo utilizzare 705 00:34:26,750 --> 00:34:30,640 ‫in una prossima funzione middleware. 706 00:34:30,640 --> 00:34:33,860 ‫Va bene? 707 00:34:33,860 --> 00:34:34,693 ‫Perché ricorda, 708 00:34:34,693 --> 00:34:37,030 ‫questo oggetto request, questo è quello che 709 00:34:37,030 --> 00:34:38,950 ‫viaggia, sostanzialmente, da middleware a middleware. 710 00:34:38,950 --> 00:34:40,660 ‫Quindi, se vogliamo passare i dati 711 00:34:40,660 --> 00:34:42,330 ‫da un middleware a quello 712 00:34:42,330 --> 00:34:44,600 ‫successivo, possiamo semplicemente inserire alcune cose sull'oggetto della 713 00:34:44,600 --> 00:34:47,860 ‫richiesta, e quindi quei dati saranno disponibili in un secondo momento. 714 00:34:47,860 --> 00:34:51,220 ‫Va bene. 715 00:34:51,220 --> 00:34:52,053 ‫Quindi, questo è tutto. 716 00:34:52,053 --> 00:34:52,886 ‫Questo è 717 00:34:52,886 --> 00:34:54,560 ‫un algoritmo di protezione del percorso 718 00:34:54,560 --> 00:34:58,300 ‫molto sofisticato e molto completo, fondamentalmente, ma penso che sia davvero importante farlo 719 00:34:58,300 --> 00:34:59,740 ‫nel miglior modo possibile. 720 00:34:59,740 --> 00:35:02,820 ‫Ad ogni modo, sono felice di vedere che sei 721 00:35:02,820 --> 00:35:04,990 ‫arrivato alla fine di questo grande video, 722 00:35:04,990 --> 00:35:07,050 ‫e ci vediamo nel prossimo.