1 00:00:01,210 --> 00:00:04,650 ‫Kursleiter: Und nun erstellen wir endlich den letzten 2 00:00:04,650 --> 00:00:07,010 ‫Teil der Passwort-Reset-Funktionalität, wo 3 00:00:07,010 --> 00:00:10,593 ‫wir tatsächlich das neue Passwort für den Benutzer festlegen. 4 00:00:12,250 --> 00:00:15,900 ‫Beginnen wir also wie zuvor damit, die Schritte 5 00:00:15,900 --> 00:00:19,713 ‫zu definieren, die wir für diesen resetPassword-Flow unternehmen werden. 6 00:00:21,240 --> 00:00:26,240 ‫Rufen Sie also zuerst den Benutzer basierend auf dem Token ab. 7 00:00:30,350 --> 00:00:35,350 ‫Im zweiten Schritt legen wir dann das neue Passwort fest, jedoch 8 00:00:35,890 --> 00:00:40,153 ‫nur, wenn das Token noch nicht abgelaufen ist und 9 00:00:42,070 --> 00:00:44,040 ‫ein Benutzer vorhanden ist. 10 00:00:44,040 --> 00:00:48,633 ‫Legen Sie in diesem Fall das neue Passwort fest. 11 00:00:51,580 --> 00:00:55,250 ‫Danach müssen wir die Eigenschaft changePasswordAt 12 00:00:57,210 --> 00:01:01,000 ‫für den aktuellen Benutzer aktualisieren und schließlich, 13 00:01:04,080 --> 00:01:05,403 ‫wie bei 14 00:01:07,320 --> 00:01:10,533 ‫dieser Funktionalität üblich, den Benutzer 15 00:01:11,680 --> 00:01:12,853 ‫anmelden. 16 00:01:14,010 --> 00:01:18,840 ‫Senden Sie grundsätzlich das JSON Web Token an den Client. 17 00:01:18,840 --> 00:01:22,733 ‫Okay, es gibt noch viel zu tun und fangen wir an. 18 00:01:23,950 --> 00:01:27,493 ‫Denken Sie also aus dem letzten Video daran, dass 19 00:01:27,493 --> 00:01:30,450 ‫der Reset-Token, der tatsächlich in der URL gesendet 20 00:01:30,450 --> 00:01:33,110 ‫wird, dieser unverschlüsselte Token hier ist. 21 00:01:33,110 --> 00:01:34,723 ‫Also eigentlich dieser. 22 00:01:35,570 --> 00:01:37,810 ‫Aber diejenige, die wir in der 23 00:01:37,810 --> 00:01:39,680 ‫Datenbank haben, ist die verschlüsselte. 24 00:01:39,680 --> 00:01:42,580 ‫Darüber haben wir bereits gesprochen, und nun müssen 25 00:01:42,580 --> 00:01:44,910 ‫wir im Grunde den ursprünglichen Token 26 00:01:44,910 --> 00:01:46,630 ‫wieder verschlüsseln, damit 27 00:01:46,630 --> 00:01:49,240 ‫wir ihn dann mit dem in der 28 00:01:49,240 --> 00:01:51,433 ‫Datenbank gespeicherten, also verschlüsselten, vergleichen können. 29 00:01:52,870 --> 00:01:55,110 ‫Mit dem Passwort haben wir also schon 30 00:01:55,110 --> 00:01:57,890 ‫einmal etwas Ähnliches gemacht, aber mit dem Passwort 31 00:01:57,890 --> 00:02:01,010 ‫konnten wir es nicht so einfach wie möglich mit diesem 32 00:02:01,010 --> 00:02:02,650 ‫vergleichen, da wir für 33 00:02:02,650 --> 00:02:05,770 ‫das Passwort den recht komplexen bcrypt-Algorithmus verwendet haben, der 34 00:02:05,770 --> 00:02:07,490 ‫in diesem Fall wir nicht. 35 00:02:07,490 --> 00:02:09,750 ‫Hier ist es also ganz einfach. 36 00:02:09,750 --> 00:02:13,040 ‫Alles was wir noch tun müssen, ist den 37 00:02:13,040 --> 00:02:17,390 ‫Token zu verschlüsseln und mit dem verschlüsselten in der Datenbank zu vergleichen. 38 00:02:17,390 --> 00:02:22,390 ‫Sagen wir also hashedToken, und so brauchen wir 39 00:02:23,670 --> 00:02:26,813 ‫nun auch hier das Krypto-Paket. 40 00:02:31,730 --> 00:02:36,167 ‫Const crypto und dann require('crypto'). 41 00:02:41,280 --> 00:02:42,123 ‫Jetzt rechts. 42 00:02:43,780 --> 00:02:47,593 ‫Dann gehen wir zurück, und so verwenden 43 00:02:48,750 --> 00:02:51,610 ‫wir Krypto. createHash. 44 00:02:53,070 --> 00:02:57,973 ‫Denken Sie daran, dann wieder den Namen des 45 00:02:58,910 --> 00:03:03,910 ‫Algorithmus, sha256, dann . update, im Grunde für den Ort, für den 46 00:03:04,140 --> 00:03:06,040 ‫String, den wir hashen möchten. 47 00:03:06,040 --> 00:03:10,110 ‫Erinnern Sie sich in req. Parameter. 48 00:03:10,110 --> 00:03:14,083 ‫Also benutzen wir diesen dann für eine lange Zeit. Zeichen. 49 00:03:15,060 --> 00:03:17,950 ‫Und wieder ist es ein Parameter, 50 00:03:17,950 --> 00:03:22,233 ‫weil wir das hier in der URL angegeben haben, also so. 51 00:03:23,250 --> 00:03:26,470 ‫Es handelt sich jetzt also um einen Parameter namens token. 52 00:03:26,470 --> 00:03:31,470 ‫Und so ist es hier natürlich req. Parameter. Zeichen. 53 00:03:31,804 --> 00:03:34,790 ‫Und schließlich müssen wir auch Digest sagen 54 00:03:36,840 --> 00:03:38,633 ‫und in hexadezimal umwandeln. 55 00:03:40,380 --> 00:03:42,760 ‫Das ist jetzt im Grunde dasselbe 56 00:03:42,760 --> 00:03:46,180 ‫wie vorher, wo wir das Original verschlüsselt haben, und so 57 00:03:46,180 --> 00:03:49,520 ‫konnten wir es in seine eigene Funktion umwandeln, aber 58 00:03:49,520 --> 00:03:51,693 ‫halten wir es hier einfach. 59 00:03:54,240 --> 00:03:58,930 ‫Lassen Sie uns nun den Benutzer basierend auf diesem Token abrufen. 60 00:03:58,930 --> 00:04:01,060 ‫Denn das ist eigentlich das Einzige, 61 00:04:01,060 --> 00:04:03,530 ‫was wir derzeit über den Benutzer wissen. 62 00:04:03,530 --> 00:04:07,080 ‫Wir haben keine E-Mail, wir haben nichts, daher ist dieses 63 00:04:07,080 --> 00:04:10,130 ‫Token das einzige, was den Benutzer identifizieren kann. 64 00:04:10,130 --> 00:04:12,520 ‫Und so können wir jetzt im Grunde die 65 00:04:12,520 --> 00:04:14,170 ‫Datenbank nach diesem Token abfragen. 66 00:04:14,170 --> 00:04:17,303 ‫Und es wird dann den Benutzer finden, der dieses Token hat. 67 00:04:19,230 --> 00:04:24,230 ‫Warten Sie also, wie wir bereits wissen, und dann Benutzer. einen finden. 68 00:04:27,790 --> 00:04:31,213 ‫Diese Eigenschaft heißt also passwordResetToken 69 00:04:32,090 --> 00:04:36,117 ‫und wir suchen nach dem hashedToken. 70 00:04:37,940 --> 00:04:42,220 ‫Und jetzt müssen wir es natürlich als async deklarieren und 71 00:04:43,150 --> 00:04:44,643 ‫in catchAsync vorbereiten. 72 00:04:48,557 --> 00:04:51,810 ‫Speichern Sie es, das sollte diesen Fehler beheben, 73 00:04:51,810 --> 00:04:53,950 ‫und das tut es tatsächlich. 74 00:04:53,950 --> 00:04:56,950 ‫Dadurch wird der Benutzer gefunden, der über das Token verfügt, 75 00:04:56,950 --> 00:04:59,100 ‫das über die URL gesendet wird. 76 00:04:59,100 --> 00:05:00,910 ‫Aber im Moment 77 00:05:00,910 --> 00:05:04,090 ‫berücksichtigen wir das Ablaufdatum des Tokens nicht. 78 00:05:04,090 --> 00:05:06,000 ‫Und wie könnten wir das tun? 79 00:05:06,000 --> 00:05:09,020 ‫Nun, im Grunde wollen wir überprüfen, 80 00:05:09,020 --> 00:05:11,860 ‫ob die Eigenschaft passwordResetExpires größer 81 00:05:11,860 --> 00:05:13,723 ‫ist als jetzt. 82 00:05:14,890 --> 00:05:17,350 ‫Denn wenn das Ablaufdatum größer als jetzt ist, 83 00:05:17,350 --> 00:05:20,420 ‫bedeutet dies, dass es in der Zukunft liegt, was wiederum bedeutet, 84 00:05:20,420 --> 00:05:22,313 ‫dass es noch nicht abgelaufen ist. 85 00:05:23,180 --> 00:05:24,850 ‫Dies ist also eine 86 00:05:24,850 --> 00:05:28,343 ‫sehr einfache Möglichkeit, dies mit dieser Abfrage tatsächlich richtig zu machen. 87 00:05:30,619 --> 00:05:32,702 ‫Also, passwordResetExpires, wo dieses Datum 88 00:05:35,170 --> 00:05:37,460 ‫gespeichert ist, und jetzt müssen wir 89 00:05:37,460 --> 00:05:38,840 ‫nur noch überprüfen, 90 00:05:38,840 --> 00:05:41,470 ‫ob es tatsächlich größer ist als jetzt. 91 00:05:41,470 --> 00:05:45,440 ‫Und wir wissen also bereits, wie das mit MongoDB geht, oder? 92 00:05:45,440 --> 00:05:50,110 ‫Also, neues Objekt und dann der größere Operator und dann wollen wir 93 00:05:50,110 --> 00:05:53,737 ‫es mit Datum vergleichen. jetzt, und dies wird 94 00:05:56,310 --> 00:05:59,410 ‫eigentlich ein Zeitstempel von jetzt sein, aber 95 00:05:59,410 --> 00:06:02,900 ‫hinter den Kulissen konvertiert MongoDB dann alles in 96 00:06:02,900 --> 00:06:05,170 ‫dasselbe und kann sie daher 97 00:06:05,170 --> 00:06:06,520 ‫genau vergleichen. 98 00:06:08,070 --> 00:06:10,440 ‫Damit können wir gleichzeitig den Benutzer 99 00:06:10,440 --> 00:06:14,120 ‫für den Token finden und auch prüfen, ob der 100 00:06:14,120 --> 00:06:16,370 ‫Token noch nicht abgelaufen ist. 101 00:06:16,370 --> 00:06:18,190 ‫So großartig. 102 00:06:18,190 --> 00:06:21,190 ‫Als nächstes wollen wir natürlich einen Fehler senden, 103 00:06:21,190 --> 00:06:25,530 ‫wenn kein Benutzer vorhanden ist oder im Grunde der Token abgelaufen ist. 104 00:06:25,530 --> 00:06:27,230 ‫Aber das ist in 105 00:06:27,230 --> 00:06:30,500 ‫diesem Fall dasselbe, denn wenn das Token abgelaufen ist, 106 00:06:30,500 --> 00:06:32,513 ‫wird es einfach keinen Benutzer zurückgeben. 107 00:06:33,956 --> 00:06:37,730 ‫Und so müssen wir nur sagen, wenn kein 108 00:06:38,970 --> 00:06:43,970 ‫Benutzer, dann, wie immer, als nächstes zurück, das ist nicht mext. 109 00:06:47,920 --> 00:06:51,910 ‫Also neuer AppError, und 110 00:06:51,910 --> 00:06:56,793 ‫sagen wir, Token ist ungültig oder abgelaufen. 111 00:06:59,850 --> 00:07:02,853 ‫Und dann 400, so schlechte Anfrage. 112 00:07:04,140 --> 00:07:07,050 ‫Wenn also kein Fehler auftritt und 113 00:07:07,050 --> 00:07:09,400 ‫next nicht aufgerufen wird, 114 00:07:09,400 --> 00:07:12,160 ‫dann setzen wir das Passwort tatsächlich. 115 00:07:12,160 --> 00:07:15,550 ‫Wir haben also bereits den Benutzer und jetzt ist es 116 00:07:15,550 --> 00:07:20,550 ‫ganz einfach: Benutzer. Passwort ist gleich req. Karosserie. Passwort. 117 00:07:24,880 --> 00:07:28,140 ‫Und das liegt daran, dass wir das Passwort 118 00:07:28,140 --> 00:07:31,713 ‫und auch die Passwortbestätigung selbstverständlich über den Body versenden. 119 00:07:33,551 --> 00:07:34,701 ‫Lassen Sie uns 120 00:07:37,870 --> 00:07:39,553 ‫also auch das und passwordConfirm duplizieren. 121 00:07:41,425 --> 00:07:44,630 ‫Und dann löschen wir im Grunde das Reset-Token und 122 00:07:44,630 --> 00:07:45,733 ‫das abgelaufene. 123 00:07:46,800 --> 00:07:51,800 ‫Also passwordResetToken, also genau wie zuvor, haben wir es auf undefined 124 00:07:52,040 --> 00:07:57,037 ‫gesetzt und jetzt user. Passwort läuft ab gleich 125 00:07:59,510 --> 00:08:01,160 ‫undefined. 126 00:08:01,160 --> 00:08:02,220 ‫Gut. 127 00:08:02,220 --> 00:08:04,350 ‫Und natürlich müssen wir es jetzt wieder 128 00:08:04,350 --> 00:08:07,000 ‫speichern, da dies das Dokument nur ändert, es 129 00:08:07,000 --> 00:08:08,410 ‫nicht wirklich aktualisiert. 130 00:08:08,410 --> 00:08:09,973 ‫Es wird also nicht wirklich gespeichert. 131 00:08:11,200 --> 00:08:15,503 ‫Warten Sie also auf den Benutzer. speichern. 132 00:08:17,500 --> 00:08:20,350 ‫Und in diesem Fall müssen wir 133 00:08:20,350 --> 00:08:24,340 ‫die Validatoren eigentlich nicht ausschalten, weil wir tatsächlich validieren wollen. 134 00:08:24,340 --> 00:08:27,620 ‫Zum Beispiel möchten wir, dass der 135 00:08:27,620 --> 00:08:31,440 ‫Validator bestätigt, ob das Passwort gleich passwordConfirm ist. 136 00:08:31,440 --> 00:08:33,380 ‫Und damit erledigt dieser Validator automatisch 137 00:08:33,380 --> 00:08:35,033 ‫all diese Arbeit für uns. 138 00:08:36,800 --> 00:08:39,390 ‫Dann der dritte Schritt, was wir am Ende 139 00:08:39,390 --> 00:08:42,030 ‫tatsächlich tun werden, und als nächstes werden wir 140 00:08:42,030 --> 00:08:43,990 ‫den Benutzer im Grunde einsperren. 141 00:08:43,990 --> 00:08:47,400 ‫Mit anderen Worten, senden Sie das JSON Web Token. 142 00:08:47,400 --> 00:08:51,930 ‫Und holen wir uns den Code von hier, also diesen. 143 00:08:51,930 --> 00:08:53,770 ‫Und wieder tun wir dies 144 00:08:53,770 --> 00:08:55,700 ‫hier bereits an drei verschiedenen Orten. 145 00:08:55,700 --> 00:08:59,280 ‫Also hier im Login, auch im Signup, und jetzt 146 00:08:59,280 --> 00:09:01,400 ‫zum dritten Mal hier unten. 147 00:09:01,400 --> 00:09:05,170 ‫Und so werden wir das irgendwann in der Zukunft in seine 148 00:09:05,170 --> 00:09:06,383 ‫eigene Funktion umgestalten. 149 00:09:07,230 --> 00:09:09,673 ‫Aber im Moment sind wir gut so. 150 00:09:11,180 --> 00:09:14,743 ‫Und so lassen Sie uns jetzt tatsächlich weitermachen und dies testen. 151 00:09:16,710 --> 00:09:19,020 ‫Dieses Reset-Token, das wir zuvor 152 00:09:19,020 --> 00:09:22,080 ‫hatten, ist also bereits abgelaufen, und wir müssen 153 00:09:22,080 --> 00:09:24,640 ‫im Grunde genommen nach einem neuen fragen. 154 00:09:24,640 --> 00:09:29,490 ‫Kommen wir also zu Postman und schlagen unsere Route zum Vergessen des Passworts ein. 155 00:09:29,490 --> 00:09:32,120 ‫Lassen Sie uns hier einfach die 156 00:09:32,120 --> 00:09:36,350 ‫Unordnung reduzieren und all diese offenen Registerkarten loswerden, die wir nicht 157 00:09:36,350 --> 00:09:37,500 ‫mehr benötigen. 158 00:09:38,910 --> 00:09:41,150 ‫Eigentlich brauchen wir hier diesen Test 159 00:09:43,480 --> 00:09:45,270 ‫für dieses Reset-Passwort, denn denken 160 00:09:45,270 --> 00:09:48,210 ‫Sie daran, dass dieser tatsächlich ein JSON-Web-Token zurückbekommt, 161 00:09:48,210 --> 00:09:51,540 ‫und deshalb wollen wir das in der Umgebungsvariablen speichern, genau 162 00:09:51,540 --> 00:09:52,890 ‫wie wir es 163 00:09:52,890 --> 00:09:54,830 ‫bei allen anderen gemacht haben. 164 00:09:54,830 --> 00:09:58,373 ‫Das mache ich jetzt, nur damit ich es nicht vergesse. 165 00:10:00,550 --> 00:10:04,100 ‫Alles klar, fangen wir im Grunde damit an, das 166 00:10:04,100 --> 00:10:05,690 ‫Passwort zu vergessen. 167 00:10:05,690 --> 00:10:08,620 ‫Das Versenden dieser Anfrage, was wiederum wegen des 168 00:10:08,620 --> 00:10:10,750 ‫Sendens der E-Mail einige Zeit 169 00:10:10,750 --> 00:10:14,947 ‫in Anspruch nimmt, aber hier gehen wir zu unserer E-Mail, und das 170 00:10:16,880 --> 00:10:19,463 ‫ist gerade vor ein paar Sekunden angekommen. 171 00:10:20,670 --> 00:10:24,890 ‫Also, das ist natürlich dieses Token. 172 00:10:24,890 --> 00:10:29,890 ‫Also schnappen wir es uns, kopieren es und jetzt zurück zu Postman, wir 173 00:10:31,060 --> 00:10:34,303 ‫verwenden es im Reset Password, als URL. 174 00:10:35,750 --> 00:10:37,253 ‫Okay, sinnvoll? 175 00:10:38,250 --> 00:10:41,603 ‫Auch hier senden wir dieses Token direkt in der URL. 176 00:10:43,600 --> 00:10:45,730 ‫Dann geben wir hier den 177 00:10:45,730 --> 00:10:49,453 ‫Body an, denn jetzt müssen wir tatsächlich unser neues Passwort angeben. 178 00:10:53,720 --> 00:10:57,843 ‫Also Passwort und sagen wir newpass. 179 00:11:01,650 --> 00:11:03,050 ‫Und dann... 180 00:11:05,950 --> 00:11:07,450 ‫Und hier nennen wir es 181 00:11:07,450 --> 00:11:10,263 ‫anders, denn im Moment möchte ich eigentlich einen Fehler sehen. 182 00:11:11,480 --> 00:11:14,727 ‫Und natürlich heißt dies passwordConfirm. 183 00:11:17,360 --> 00:11:20,393 ‫Mal sehen, was passiert, wenn wir dies versuchen. 184 00:11:23,240 --> 00:11:27,080 ‫Warten wir es ab, und wir erhalten, dass das Passwort 185 00:11:27,080 --> 00:11:29,640 ‫kürzer ist als die zulässige Mindestlänge. 186 00:11:29,640 --> 00:11:34,480 ‫Okay, also lass uns das ändern, 123, und hier sagen wir 1234. 187 00:11:36,090 --> 00:11:37,740 ‫Deshalb möchte ich, dass sie anders sind. 188 00:11:37,740 --> 00:11:40,630 ‫Aber Sie sehen, dass die Validierung hier gut funktioniert hat, 189 00:11:40,630 --> 00:11:43,273 ‫auch wenn das Passwort mit Speichern aktualisiert wurde. 190 00:11:45,610 --> 00:11:48,800 ‫So, und jetzt bekommen wir Passwörter sind nicht gleich! 191 00:11:48,800 --> 00:11:50,960 ‫Das ist also wieder ein Validierungsfehler. 192 00:11:50,960 --> 00:11:53,430 ‫Und denken Sie daran, dass dies der 193 00:11:53,430 --> 00:11:56,213 ‫einzige Grund ist, warum wir speichern und nicht aktualisieren müssen. 194 00:11:57,206 --> 00:11:59,090 ‫Früher haben wir also 195 00:11:59,090 --> 00:12:03,220 ‫zum Aktualisieren von Touren findOneAndUpdate verwendet, aber jetzt für alles, 196 00:12:03,220 --> 00:12:06,820 ‫was mit Passwörtern und dem Benutzer zu tun 197 00:12:06,820 --> 00:12:10,110 ‫hat, verwenden wir immer save, weil wir immer 198 00:12:10,110 --> 00:12:12,580 ‫alle Validatoren und vor allem die 199 00:12:12,580 --> 00:12:14,450 ‫Save-Middleware-Funktionen ausführen möchten. 200 00:12:14,450 --> 00:12:18,293 ‫Also zum Beispiel diejenigen, bei denen die Passwörter verschlüsselt sind. 201 00:12:20,400 --> 00:12:21,610 ‫Also lass es uns jetzt beenden. 202 00:12:21,610 --> 00:12:25,030 ‫Oh, ich habe es nicht richtig korrigiert, tut mir leid. 203 00:12:25,030 --> 00:12:28,230 ‫Und nun sollte es eigentlich funktionieren. 204 00:12:28,230 --> 00:12:32,870 ‫Und tatsächlich haben wir Erfolg und wir bekommen ein neues Zeichen. 205 00:12:32,870 --> 00:12:36,600 ‫Also toll, mal sehen, ob dieses Token tatsächlich gültig ist. 206 00:12:36,600 --> 00:12:40,973 ‫Wenn wir können, erhalten Sie alle Touren mit diesem brandneuen Token. 207 00:12:43,870 --> 00:12:46,210 ‫Und es geht los. 208 00:12:46,210 --> 00:12:51,000 ‫Unser neues Token funktioniert also tatsächlich, und nun sollten diese beiden 209 00:12:51,000 --> 00:12:53,990 ‫Eigenschaften für diesen Benutzer, also für 210 00:12:53,990 --> 00:12:56,190 ‫hello@jonas, eigentlich weg sein. 211 00:12:56,190 --> 00:12:59,760 ‫Das Passwort läuft also ab und das Token sollte 212 00:12:59,760 --> 00:13:03,550 ‫weg sein, denn das haben wir in unserem Code getan. 213 00:13:03,550 --> 00:13:06,760 ‫Also, ja, sie sind nicht mehr hier. 214 00:13:06,760 --> 00:13:10,210 ‫Jetzt müssen wir nur noch diesen fehlenden Schritt hier tun, 215 00:13:10,210 --> 00:13:12,690 ‫nämlich die passwordAt-Eigenschaft für diesen aktuellen Benutzer 216 00:13:13,610 --> 00:13:14,773 ‫zu aktualisieren. 217 00:13:15,680 --> 00:13:17,260 ‫Aber das sollte 218 00:13:17,260 --> 00:13:20,690 ‫nicht allzu schwer sein, also kehren wir schnell zum 219 00:13:20,690 --> 00:13:24,550 ‫userModel zurück, wo wir dies mithilfe von Middleware tun werden. 220 00:13:24,550 --> 00:13:26,800 ‫Und lassen Sie uns die gesamte 221 00:13:26,800 --> 00:13:29,023 ‫Middleware hier oben zusammenfassen. 222 00:13:32,241 --> 00:13:35,408 ‫Also userSchema. pre und nochmal 223 00:13:38,830 --> 00:13:42,763 ‫dot save, und dann eine Funktion mit next. 224 00:13:44,850 --> 00:13:47,010 ‫Auch hier wird diese Funktion 225 00:13:47,010 --> 00:13:50,890 ‫ausgeführt, kurz bevor ein neues Dokument tatsächlich gespeichert wird. 226 00:13:50,890 --> 00:13:52,220 ‫Und so ist es 227 00:13:52,220 --> 00:13:54,880 ‫der perfekte Ort, um diese Eigenschaft tatsächlich zu spezifizieren. 228 00:13:54,880 --> 00:13:57,480 ‫Und ich hätte es natürlich auch in einem Controller 229 00:13:58,820 --> 00:14:01,133 ‫direkt neben diesem Code machen können, zum Beispiel. 230 00:14:02,310 --> 00:14:05,853 ‫Aber ich möchte wirklich, dass dies sozusagen automatisch geschieht. 231 00:14:06,740 --> 00:14:08,700 ‫Also quasi hinter den Kulissen. 232 00:14:08,700 --> 00:14:11,350 ‫Denn später werden wir an einer 233 00:14:11,350 --> 00:14:15,290 ‫anderen Stelle das Passwort aktualisieren und dann sicherstellen, dass wir 234 00:14:15,290 --> 00:14:17,410 ‫dort denselben Code einfügen. 235 00:14:17,410 --> 00:14:19,300 ‫Und so passiert es wieder, 236 00:14:19,300 --> 00:14:20,640 ‫irgendwie hinter den 237 00:14:20,640 --> 00:14:23,810 ‫Kulissen, ohne dass wir uns darum kümmern müssen. 238 00:14:23,810 --> 00:14:26,600 ‫Wann genau wollen wir 239 00:14:26,600 --> 00:14:30,630 ‫nun die Eigenschaft passwordChangedAt auf genau setzen? 240 00:14:30,630 --> 00:14:33,450 ‫Nun, wir wollen es nur, wenn wir die Kennworteigenschaft 241 00:14:33,450 --> 00:14:34,660 ‫tatsächlich geändert haben. 242 00:14:34,660 --> 00:14:37,290 ‫Und ich bin mir nicht sicher, ob wir diesen Trick schon einmal 243 00:14:37,290 --> 00:14:39,660 ‫verwendet haben, aber egal, lass uns ihn jetzt anwenden. 244 00:14:39,660 --> 00:14:44,660 ‫Also, wenn wir nicht geändert haben, wenn nicht dies. isModified, also einfach so, 245 00:14:47,620 --> 00:14:49,100 ‫und dann 246 00:14:49,100 --> 00:14:53,070 ‫der Name der Eigenschaft, also Passwort. 247 00:14:53,070 --> 00:14:56,380 ‫Kehren Sie in diesem Fall also sofort zurück und führen 248 00:14:57,270 --> 00:14:59,360 ‫Sie die nächste Middleware aus. 249 00:14:59,360 --> 00:15:02,823 ‫Okay, nicht so, aber so. 250 00:15:04,380 --> 00:15:07,770 ‫Wenn wir also die Eigenschaft password nicht 251 00:15:07,770 --> 00:15:08,770 ‫geändert 252 00:15:08,770 --> 00:15:12,970 ‫haben, dann manipulieren Sie natürlich nicht die Eigenschaft passwordChangedAt. 253 00:15:12,970 --> 00:15:15,860 ‫Aber was ist mit dem Erstellen eines neuen Dokuments? 254 00:15:15,860 --> 00:15:18,010 ‫Nun, wenn wir ein neues Dokument 255 00:15:18,010 --> 00:15:20,150 ‫erstellen, haben wir tatsächlich 256 00:15:20,150 --> 00:15:24,350 ‫das Passwort geändert und dann die Eigenschaft passwordChangedAt gesetzt, richtig? 257 00:15:24,350 --> 00:15:27,260 ‫Nun, in der aktuellen Implementierung würden wir das tatsächlich tun. 258 00:15:27,260 --> 00:15:29,860 ‫Aber es gibt noch etwas anderes, das wir hier verwenden können. 259 00:15:29,860 --> 00:15:32,950 ‫Im Grunde wollen wir diese Middleware-Funktion also 260 00:15:32,950 --> 00:15:36,630 ‫sofort beenden, wenn das Passwort nicht geändert wurde oder 261 00:15:36,630 --> 00:15:40,274 ‫das Dokument neu ist, und können daher die 262 00:15:40,274 --> 00:15:41,633 ‫isNew-Eigenschaft verwenden. 263 00:15:42,700 --> 00:15:46,210 ‫Und wieder ist dies eines dieser sehr schönen Dinge, die Sie 264 00:15:46,210 --> 00:15:48,290 ‫durch das Lesen Ihrer Dokumentation lernen. 265 00:15:48,290 --> 00:15:52,010 ‫Daher kann ich nicht genug betonen, wie wichtig es ist, 266 00:15:52,010 --> 00:15:55,160 ‫die Dokumentationen wirklich zu lesen, wenn Sie etwas brauchen, 267 00:15:55,160 --> 00:15:56,870 ‫das Sie nirgendwo finden. 268 00:15:56,870 --> 00:15:59,010 ‫Denn es gibt wirklich so 269 00:15:59,010 --> 00:16:02,983 ‫viele Dinge, die man in einem Kurs nicht unterrichten kann. 270 00:16:04,810 --> 00:16:08,500 ‫Wie auch immer, wenn der Code diese Überprüfung hier 271 00:16:08,500 --> 00:16:10,830 ‫besteht, nun, dann sagen wir ganz 272 00:16:10,830 --> 00:16:14,217 ‫einfach dies. passwordChangedAt = Datum. jetzt. 273 00:16:18,660 --> 00:16:22,303 ‫Und dann rufen wir als nächstes an. 274 00:16:23,640 --> 00:16:26,300 ‫Theoretisch sollte dies nun gut funktionieren, aber 275 00:16:26,300 --> 00:16:27,590 ‫in der Praxis 276 00:16:27,590 --> 00:16:30,160 ‫tritt manchmal ein kleines Problem auf. 277 00:16:30,160 --> 00:16:33,580 ‫Und dieses Problem besteht darin, dass das Speichern 278 00:16:33,580 --> 00:16:37,440 ‫in der Datenbank manchmal etwas langsamer ist als das 279 00:16:37,440 --> 00:16:40,460 ‫Ausgeben des JSON-Web-Tokens, sodass der geänderte Passwort-Zeitstempel 280 00:16:40,460 --> 00:16:42,560 ‫manchmal etwas nach 281 00:16:42,560 --> 00:16:45,280 ‫der Erstellung des JSON-Web-Tokens gesetzt wird. 282 00:16:45,280 --> 00:16:48,000 ‫Und damit wird es dann so weit, dass 283 00:16:48,000 --> 00:16:51,120 ‫sich der Benutzer nicht mit dem neuen Token anmelden kann. 284 00:16:51,120 --> 00:16:54,570 ‫Denken Sie daran, dass dieser Zeitstempel hier 285 00:16:54,570 --> 00:16:57,660 ‫tatsächlich existiert, damit wir ihn 286 00:16:57,660 --> 00:17:01,200 ‫mit dem Zeitstempel im JSON-Web-Token vergleichen können, richtig? 287 00:17:01,200 --> 00:17:04,353 ‫Zur Erinnerung, es ist genau 288 00:17:05,930 --> 00:17:10,930 ‫hier, wo wir überprüfen, ob der Benutzer das Passwort 289 00:17:11,560 --> 00:17:15,170 ‫nach der Ausgabe des Tokens geändert hat. 290 00:17:15,170 --> 00:17:18,920 ‫Und hier unten, wo wir dann dieses neue Token 291 00:17:18,920 --> 00:17:21,010 ‫im Reset-Passwort erstellt haben. 292 00:17:21,010 --> 00:17:24,170 ‫Denken Sie daran, dass wir hier dieses 293 00:17:24,170 --> 00:17:27,770 ‫neue Token erstellen, und auch hier kommt es manchmal 294 00:17:27,770 --> 00:17:31,500 ‫vor, dass dieses Token kurz vor der tatsächlichen Erstellung 295 00:17:31,500 --> 00:17:33,960 ‫des geänderten Kennwortzeitstempels erstellt wird. 296 00:17:33,960 --> 00:17:38,960 ‫Also müssen wir das nur beheben, indem wir eine Sekunde subtrahieren. 297 00:17:39,610 --> 00:17:42,733 ‫Also im Grunde tausend Millisekunden. 298 00:17:43,750 --> 00:17:47,670 ‫Und damit wird das passwordChangedAt dann eine Sekunde in die 299 00:17:47,670 --> 00:17:50,840 ‫Vergangenheit gelegt, okay, was dann natürlich nicht 300 00:17:50,840 --> 00:17:54,500 ‫100% genau ist, aber das ist überhaupt kein Problem, 301 00:17:54,500 --> 00:17:58,000 ‫denn eine Sekunde macht hier überhaupt keinen Unterschied. 302 00:17:58,000 --> 00:18:01,213 ‫Es ist ein kleiner Hack, aber auch hier ist es kein Problem. 303 00:18:02,190 --> 00:18:06,190 ‫Wenn Sie also dieses passwordChanged eine Sekunde in die Vergangenheit legen, 304 00:18:06,190 --> 00:18:08,920 ‫wird sichergestellt, dass das Token immer erstellt 305 00:18:08,920 --> 00:18:11,433 ‫wird, nachdem das Passwort geändert wurde. 306 00:18:13,290 --> 00:18:15,800 ‫So, das funktioniert jetzt, aber wie 307 00:18:15,800 --> 00:18:18,380 ‫immer, lassen Sie es uns auch schnell testen. 308 00:18:18,380 --> 00:18:21,060 ‫Okay, also zurück zum Postboten. 309 00:18:21,060 --> 00:18:23,990 ‫Lassen Sie uns ein neues Passwort zurücksetzen, oder eigentlich 310 00:18:23,990 --> 00:18:26,060 ‫wollte ich das überhaupt nicht, aber 311 00:18:26,060 --> 00:18:28,400 ‫es ist eine großartige Sache zu sehen, 312 00:18:28,400 --> 00:18:30,200 ‫dass der Code tatsächlich funktioniert. 313 00:18:30,200 --> 00:18:33,610 ‫Das Token ist also ungültig oder abgelaufen, und das liegt 314 00:18:33,610 --> 00:18:35,999 ‫daran, dass 10 Minuten vergangen sind, 315 00:18:35,999 --> 00:18:38,640 ‫seit ich dieses Token tatsächlich erstellt habe. 316 00:18:38,640 --> 00:18:41,240 ‫Und ich denke, das hatten wir noch nicht 317 00:18:41,240 --> 00:18:45,043 ‫getestet, und deshalb ist es toll, dass es jetzt aus Versehen tatsächlich funktioniert hat. 318 00:18:46,370 --> 00:18:50,160 ‫Also, das kommt noch einmal, falls Sie sich fragen, was 319 00:18:50,160 --> 00:18:51,493 ‫zum Teufel passiert 320 00:18:53,840 --> 00:18:56,500 ‫ist, das ist natürlich diese Fehlermeldung hier. 321 00:18:56,500 --> 00:18:59,450 ‫Dies bedeutet, dass kein Benutzer gefunden wurde, 322 00:18:59,450 --> 00:19:03,216 ‫der dieses Token besitzt oder dessen Token länger als 323 00:19:03,216 --> 00:19:05,163 ‫10 Minuten zurückliegt. 324 00:19:06,600 --> 00:19:10,393 ‫Und so wollte ich tatsächlich das Passwort vergessen. 325 00:19:12,700 --> 00:19:14,073 ‫Warten wir also ab. 326 00:19:18,000 --> 00:19:19,980 ‫Also 8. 6 Sekunden, 327 00:19:19,980 --> 00:19:22,820 ‫aber das könnte an meiner Internetverbindung liegen. 328 00:19:22,820 --> 00:19:24,520 ‫Wenn Sie dies also auf einem 329 00:19:24,520 --> 00:19:26,373 ‫Server ausführen, wird es wahrscheinlich viel schneller sein. 330 00:19:27,440 --> 00:19:31,900 ‫Nehmen wir das hier, zurück zu Postman, und jetzt setzen 331 00:19:31,900 --> 00:19:36,740 ‫wir das Passwort zurück, wieder mit diesem Passwort, egal ob es 332 00:19:36,740 --> 00:19:39,823 ‫das gleiche wie das alte ist. 333 00:19:40,690 --> 00:19:43,580 ‫Und so haben wir jetzt unseren Erfolg hier. 334 00:19:43,580 --> 00:19:45,193 ‫Und nun zurück zum Kompass. 335 00:19:46,680 --> 00:19:51,210 ‫Lassen Sie uns neu laden, und tatsächlich erhalten wir das PasswortChangedAt. 336 00:19:51,210 --> 00:19:53,290 ‫Und das ist jetzt tatsächlich so. 337 00:19:53,290 --> 00:19:57,220 ‫Wenn wir also nun tatsächlich versuchen, dieses Token zu verwenden, um 338 00:19:57,220 --> 00:19:59,870 ‫beispielsweise auf diese geschützte Route zuzugreifen, dann 339 00:19:59,870 --> 00:20:02,130 ‫sollte das aufgrund dieses kleinen, 340 00:20:02,130 --> 00:20:04,633 ‫ein-zweiten-Tags, den wir gemacht haben, funktionieren. 341 00:20:06,090 --> 00:20:10,205 ‫So, und so haben wir jetzt 342 00:20:10,205 --> 00:20:12,840 ‫unsere Passwort-Reset-Funktionalität abgeschlossen. 343 00:20:12,840 --> 00:20:16,400 ‫Das war also ziemlich viel Code, aber es lohnt sich 344 00:20:16,400 --> 00:20:18,100 ‫natürlich auf jeden Fall. 345 00:20:18,100 --> 00:20:20,470 ‫Sie sollten diese Funktionalität also 346 00:20:20,470 --> 00:20:22,874 ‫immer in Ihrer Webanwendung anbieten, da 347 00:20:22,874 --> 00:20:26,750 ‫sonst ein Benutzer, der sein Passwort vergisst, völlig vermasselt wird, 348 00:20:26,750 --> 00:20:29,140 ‫er Ihre Anwendung nicht mehr verwenden 349 00:20:29,140 --> 00:20:31,940 ‫kann, und das ist natürlich eine schreckliche Praxis. 350 00:20:31,940 --> 00:20:34,020 ‫Wie auch immer, diese 351 00:20:34,020 --> 00:20:38,520 ‫Art beendet bereits den Authentifizierungs- und Autorisierungsteil dieses Abschnitts. 352 00:20:38,520 --> 00:20:40,510 ‫Es ist also wieder ziemlich 353 00:20:40,510 --> 00:20:43,250 ‫vollständig und ich hatte viel Spaß bei der Umsetzung. 354 00:20:43,250 --> 00:20:46,341 ‫Dieser Teil ist für mich also der Punkt, an 355 00:20:46,341 --> 00:20:48,560 ‫dem Webanwendungen wirklich zum Leben erwachen. 356 00:20:48,560 --> 00:20:51,280 ‫Ich weiß, dass es an dieser Stelle nicht wirklich 357 00:20:51,280 --> 00:20:54,280 ‫sichtbar ist, mit all diesen, nur Token und Token kopieren 358 00:20:54,280 --> 00:20:56,300 ‫und an anderer Stelle einfügen. 359 00:20:56,300 --> 00:20:59,630 ‫Das ist nicht die übliche Vorstellung, die wir beim Einloggen 360 00:20:59,630 --> 00:21:02,410 ‫haben, ich weiß, aber natürlich wieder, etwas später, wenn 361 00:21:02,410 --> 00:21:05,430 ‫wir endlich mit dem Aufbau der dynamischen Website beginnen, 362 00:21:05,430 --> 00:21:06,580 ‫dann werden wir 363 00:21:06,580 --> 00:21:09,220 ‫natürlich weiterhin diese Authentifizierung verwenden, die wir 364 00:21:09,220 --> 00:21:13,350 ‫gerade erstellt haben und dann es wird auch auf dieser dynamischen Website sichtbar. 365 00:21:13,350 --> 00:21:16,833 ‫Als nächstes werden wir Funktionen zum Aktualisieren 366 00:21:16,833 --> 00:21:19,620 ‫und Löschen des Benutzers implementieren 367 00:21:19,620 --> 00:21:22,990 ‫und danach auch über die Sicherheit sprechen. 368 00:21:22,990 --> 00:21:25,800 ‫Das ist, was für den Rest des Abschnitts vor 369 00:21:25,800 --> 00:21:28,323 ‫Ihnen liegt, also verpassen Sie das nicht.