1 00:00:01,140 --> 00:00:03,050 ‫Jonas: Lassen Sie uns jetzt 2 00:00:03,050 --> 00:00:04,773 ‫unsere Middleware-Schutzfunktion weiterschreiben. 3 00:00:06,420 --> 00:00:08,910 ‫In der letzten Vorlesung haben wir also den 4 00:00:08,910 --> 00:00:10,990 ‫Token aus dem Authorization Header 5 00:00:10,990 --> 00:00:14,080 ‫gelesen und dann überprüft, ob der Token tatsächlich existiert. 6 00:00:14,080 --> 00:00:15,023 ‫Also gleich hier. 7 00:00:15,880 --> 00:00:19,890 ‫Und als nächstes haben wir den Verifizierungsschritt für das Token. 8 00:00:19,890 --> 00:00:21,880 ‫Und ich hoffe, Sie erinnern sich 9 00:00:21,880 --> 00:00:24,520 ‫daran, dass wir in diesem Schritt überprüfen, ob jemand die 10 00:00:24,520 --> 00:00:27,500 ‫Daten manipuliert hat oder auch, ob der Token bereits abgelaufen ist. 11 00:00:27,500 --> 00:00:31,840 ‫Wir haben also bereits aus dem JSON-Webtoken-Paket die Funktion zum 12 00:00:31,840 --> 00:00:33,180 ‫Zuweisen verwendet, 13 00:00:33,180 --> 00:00:35,623 ‫und jetzt verwenden wir die Verifizierungsfunktion. 14 00:00:36,820 --> 00:00:39,333 ‫Also genau wie zuvor, jwt. Verifizieren, und dann 15 00:00:43,000 --> 00:00:46,630 ‫übergeben wir dort, wie Sie sich vorstellen können, das Token, damit der 16 00:00:46,630 --> 00:00:49,160 ‫Algorithmus die Nutzlast lesen kann, und erinnern uns 17 00:00:49,160 --> 00:00:52,133 ‫dann daran, dass dieser Schritt auch das Geheimnis benötigt. 18 00:00:53,250 --> 00:00:56,870 ‫Also im Grunde, um die Testsignatur zu erstellen. 19 00:00:56,870 --> 00:01:00,743 ‫Dieses Geheimnis ist also der Prozess. env. JWT_SECRET. 20 00:01:03,470 --> 00:01:04,610 ‫Erinnere dich daran? 21 00:01:04,610 --> 00:01:05,860 ‫Als drittes 22 00:01:05,860 --> 00:01:09,003 ‫Argument erfordert diese Funktion nun tatsächlich eine Callback-Funktion. 23 00:01:10,090 --> 00:01:12,180 ‫Dieser Rückruf wird also 24 00:01:12,180 --> 00:01:14,850 ‫ausgeführt, sobald die Verifizierung abgeschlossen ist. 25 00:01:14,850 --> 00:01:16,840 ‫Sie sehen also, dass diese 26 00:01:16,840 --> 00:01:19,564 ‫Überprüfung hier eigentlich eine asynchrone Funktion ist. 27 00:01:19,564 --> 00:01:22,540 ‫Es wird also ein Token überprüfen und danach, 28 00:01:22,540 --> 00:01:23,620 ‫wenn es 29 00:01:23,620 --> 00:01:27,040 ‫fertig ist, die Callback-Funktion aufrufen, die wir angeben können. 30 00:01:27,040 --> 00:01:29,910 ‫Wir haben die ganze Zeit mit Versprechen 31 00:01:29,910 --> 00:01:33,159 ‫gearbeitet, und ich möchte dieses Muster hier nicht wirklich durchbrechen. 32 00:01:33,159 --> 00:01:37,000 ‫Und so werden wir diese Funktion tatsächlich versprechen. 33 00:01:37,000 --> 00:01:40,370 ‫Also im Grunde, um es zu einem Versprechen zurückzugeben. 34 00:01:40,370 --> 00:01:42,660 ‫Auf diese Weise können wir dann async-await 35 00:01:42,660 --> 00:01:45,613 ‫verwenden, genau wie jede andere async-Funktion, die wir verwendet haben. 36 00:01:46,820 --> 00:01:48,050 ‫Um dies zu 37 00:01:48,050 --> 00:01:51,050 ‫tun, verfügt Node tatsächlich über eine integrierte Versprechensfunktion. 38 00:01:51,050 --> 00:01:53,650 ‫Alles, was wir tun müssen, um 39 00:01:53,650 --> 00:01:56,663 ‫es zu verwenden, ist das eingebaute util-Modul. 40 00:01:58,695 --> 00:02:00,895 ‫Also lass uns das ganz oben machen. 41 00:02:02,900 --> 00:02:07,900 ‫Dadurch wird ein Objekt namens util erstellt, erfordern... 42 00:02:10,740 --> 00:02:13,400 ‫Alles klar, das steht also für Nützlichkeit. 43 00:02:13,400 --> 00:02:15,420 ‫Das war nicht das, was ich wollte. 44 00:02:15,420 --> 00:02:16,960 ‫Das steht also für Nutzwert. 45 00:02:16,960 --> 00:02:20,300 ‫Und dann werden wir die Versprechensmethode verwenden. 46 00:02:20,300 --> 00:02:22,900 ‫Aber da wir nur diese eine Methode verwenden werden, können 47 00:02:22,900 --> 00:02:24,603 ‫wir es tatsächlich einfacher machen. 48 00:02:25,578 --> 00:02:26,990 ‫Anstatt dies zu 49 00:02:26,990 --> 00:02:30,610 ‫tun, können wir dieses Objekt einfach destrukturieren und direkt 50 00:02:30,610 --> 00:02:32,823 ‫von dort aus Promisify nehmen. 51 00:02:35,388 --> 00:02:38,453 ‫Auch hier wird nur die ES6-Destrukturierung verwendet. 52 00:02:41,182 --> 00:02:43,230 ‫Okay, so und jetzt ist es sehr einfach zu bedienen. 53 00:02:43,230 --> 00:02:46,127 ‫Alles, was wir tun müssen, ist Versprechen zu nennen. 54 00:02:47,434 --> 00:02:51,463 ‫Versprechen Sie es also und übergeben Sie die Funktion dort. 55 00:02:53,500 --> 00:02:56,080 ‫All dies hier ist also eine Funktion, die 56 00:02:56,080 --> 00:02:56,970 ‫wir aufrufen 57 00:02:56,970 --> 00:02:59,190 ‫müssen, die dann ein Promise zurückgibt. 58 00:02:59,190 --> 00:03:01,810 ‫Also rufen wir hier die Funktion tatsächlich auf. 59 00:03:01,810 --> 00:03:03,900 ‫Und dies wird dann ein Promise 60 00:03:03,900 --> 00:03:08,300 ‫zurückgeben, und so können wir darauf warten und das Ergebnis in einer Variablen speichern. 61 00:03:08,300 --> 00:03:10,390 ‫Der Ergebniswert des Versprechens sind 62 00:03:10,390 --> 00:03:12,350 ‫also tatsächlich die 63 00:03:12,350 --> 00:03:15,823 ‫decodierten Daten, also die decodierten Nutzdaten dieses JSON-Webtokens. 64 00:03:17,600 --> 00:03:19,360 ‫Also lassen Sie es mich hier dekodiert nennen. 65 00:03:19,360 --> 00:03:20,193 ‫Gut. 66 00:03:20,193 --> 00:03:23,490 ‫Und wir können warten, weil wir bereits gesagt haben, dass es 67 00:03:23,490 --> 00:03:25,453 ‫sich um eine asynchrone Funktion handelt. 68 00:03:27,670 --> 00:03:30,850 ‫Und jetzt, nur um zu sehen, dass es tatsächlich 69 00:03:30,850 --> 00:03:34,730 ‫funktioniert, loggen wir diese entschlüsselten Daten auch in die Konsole ein. 70 00:03:34,730 --> 00:03:38,143 ‫Und tatsächlich können wir diese Konsole entfernen. das Token abmelden. 71 00:03:39,050 --> 00:03:40,400 ‫Den brauchen wir nicht mehr. 72 00:03:42,140 --> 00:03:46,560 ‫Versuchen wir also, diese Anfrage erneut zu senden, und ja, 73 00:03:46,560 --> 00:03:49,990 ‫aber diesmal schalten wir diesen Autorisierungsheader 74 00:03:49,990 --> 00:03:54,850 ‫tatsächlich ein, damit wir zusammen mit der Anfrage ein JSON-Webtoken senden. 75 00:03:54,850 --> 00:03:55,940 ‫Das hat es also geschickt. 76 00:03:55,940 --> 00:03:58,540 ‫Und nun bekommen wir tatsächlich Zugriff auf die 77 00:03:58,540 --> 00:04:02,070 ‫Daten und somit haben wir nun Zugriff auf den geschützten Weg. 78 00:04:02,070 --> 00:04:02,903 ‫Okay? 79 00:04:02,903 --> 00:04:06,203 ‫Aber was ich sehen wollte, ist dieses entschlüsselte Objekt hier. 80 00:04:07,230 --> 00:04:09,910 ‫Dies sollte hier also die Benutzer-ID sein. 81 00:04:09,910 --> 00:04:12,530 ‫Schauen wir uns das noch einmal in Postman an. 82 00:04:12,530 --> 00:04:13,423 ‫Also 62a42. 83 00:04:15,520 --> 00:04:18,740 ‫Und so, in der Tat, gut, wo haben wir das? 84 00:04:18,740 --> 00:04:20,193 ‫Werfen wir einen Blick auf Kompass. 85 00:04:21,240 --> 00:04:24,813 ‫Und tatsächlich ist die ID dieses Benutzers diese 62a42. 86 00:04:27,160 --> 00:04:29,347 ‫Und das bedeutet, dass wir hier 87 00:04:29,347 --> 00:04:31,340 ‫tatsächlich unsere richtige Nutzlast haben. 88 00:04:31,340 --> 00:04:33,420 ‫Also im Grunde die richtige Benutzer-ID. 89 00:04:33,420 --> 00:04:36,460 ‫Wir haben dann auch den Zeitstempel des 90 00:04:36,460 --> 00:04:39,500 ‫Erstellungsdatums und des Ablaufdatums des Tokens. 91 00:04:39,500 --> 00:04:40,700 ‫Das funktioniert also. 92 00:04:40,700 --> 00:04:43,710 ‫Aber jetzt versuchen wir tatsächlich, die Nutzlast dieses Tokens 93 00:04:43,710 --> 00:04:44,563 ‫zu manipulieren. 94 00:04:47,088 --> 00:04:49,090 ‫Also kopieren wir es hier noch einmal. 95 00:04:49,090 --> 00:04:52,443 ‫Aber dann gehe ich zum JWT-Debugger. 96 00:04:54,640 --> 00:04:57,023 ‫Also nochmal bei jwt. io. 97 00:05:00,290 --> 00:05:02,363 ‫Nehmen wir das also weg. 98 00:05:03,310 --> 00:05:06,010 ‫Und jetzt werde ich hier einige Daten ändern, 99 00:05:06,010 --> 00:05:09,260 ‫und das ändert dann den codierten Token hier, den 100 00:05:09,260 --> 00:05:11,010 ‫ich dann kopieren kann. 101 00:05:12,420 --> 00:05:14,693 ‫Also lasst uns einfach ersetzen, 102 00:05:15,580 --> 00:05:19,050 ‫eigentlich werde ich diese beiden Zahlen hier einfach 103 00:05:19,050 --> 00:05:20,940 ‫durch etwas anderes ersetzen. 104 00:05:20,940 --> 00:05:23,590 ‫Und wie Sie sehen, hat dies hier den Token geändert. 105 00:05:23,590 --> 00:05:26,040 ‫Und jetzt werde ich tatsächlich versuchen, 106 00:05:26,040 --> 00:05:27,470 ‫mit diesem manipulierten 107 00:05:27,470 --> 00:05:30,373 ‫JSON-Webtoken Zugriff auf diese geschützte Route zu erhalten. 108 00:05:31,460 --> 00:05:33,133 ‫Okay, sinnvoll? 109 00:05:34,100 --> 00:05:37,023 ‫Also nur um zu sehen, ob es richtig funktioniert. 110 00:05:38,632 --> 00:05:39,970 ‫Also kopiere ich 111 00:05:39,970 --> 00:05:42,660 ‫jetzt diesen hier und füge diesen anderen anderen ein. 112 00:05:42,660 --> 00:05:47,310 ‫Also, wenn ich jetzt diese Anfrage sende, dann bekommen wir einen Fehler. 113 00:05:47,310 --> 00:05:48,250 ‫So großartig. 114 00:05:48,250 --> 00:05:50,843 ‫Wir sehen also, dass der Fehlername JsonWebTokenError ist 115 00:05:51,840 --> 00:05:54,220 ‫und wir eine ungültige Signatur haben. 116 00:05:54,220 --> 00:05:55,160 ‫So großartig. 117 00:05:55,160 --> 00:05:57,650 ‫Genau das haben wir gesucht. 118 00:05:57,650 --> 00:06:00,210 ‫Das ist also einer der beiden Fehler, die auftreten können. 119 00:06:00,210 --> 00:06:02,853 ‫Der andere ist, dass der Token bereits abgelaufen ist. 120 00:06:04,359 --> 00:06:07,180 ‫Dieser heißt also JsonWebTokenError, und 121 00:06:07,180 --> 00:06:10,890 ‫lassen Sie uns diesen Fehler jetzt behandeln. 122 00:06:10,890 --> 00:06:12,240 ‫Und wir 123 00:06:12,240 --> 00:06:16,470 ‫könnten dies tun, indem wir hier einen Try-Catch-Block hinzufügen. 124 00:06:16,470 --> 00:06:17,460 ‫Richtig? 125 00:06:17,460 --> 00:06:19,600 ‫Also könnten wir direkt nach der 126 00:06:19,600 --> 00:06:21,510 ‫Ausführung dieses Codes einen 127 00:06:21,510 --> 00:06:24,260 ‫try-Block einführen und dann im Catch Fehler erzeugen, 128 00:06:24,260 --> 00:06:26,290 ‫die an den Client gesendet werden. 129 00:06:26,290 --> 00:06:28,070 ‫Anstatt es so zu machen, 130 00:06:28,070 --> 00:06:30,970 ‫möchte ich jetzt eigentlich unsere globale Middleware zur Fehlerbehandlung 131 00:06:30,970 --> 00:06:33,290 ‫verwenden, um das für uns zu tun. 132 00:06:33,290 --> 00:06:35,850 ‫Daher möchten wir die Fehlerbehandlung nicht gleich hier 133 00:06:35,850 --> 00:06:37,220 ‫in unserer Middleware-Funktion durchführen. 134 00:06:37,220 --> 00:06:41,140 ‫Stattdessen delegieren wir es normalerweise an den Fehlercontroller. 135 00:06:41,140 --> 00:06:43,940 ‫Und so machen wir hier genau das Gleiche. 136 00:06:43,940 --> 00:06:46,710 ‫Also Fehlercontroller. 137 00:06:46,710 --> 00:06:48,600 ‫Und dann ist es eigentlich 138 00:06:48,600 --> 00:06:50,930 ‫genau dasselbe wie bei unseren anderen Fehlern hier. 139 00:06:50,930 --> 00:06:54,210 ‫So kommt zum Beispiel der Validierungsfehler von Mongoose, also 140 00:06:54,210 --> 00:06:55,670 ‫von einer anderen Bibliothek. 141 00:06:55,670 --> 00:06:59,060 ‫Und jetzt kommt dieser Fehler tatsächlich von einer anderen 142 00:06:59,060 --> 00:07:02,180 ‫Bibliothek und hat auch einen eigenen Namen. 143 00:07:02,180 --> 00:07:03,470 ‫Also lass uns das bekommen. 144 00:07:03,470 --> 00:07:04,820 ‫Und es ist JsonWebTokenError. 145 00:07:06,900 --> 00:07:07,940 ‫Gut. 146 00:07:07,940 --> 00:07:09,923 ‫Also, lassen Sie uns hier ganz ähnlich vorgehen. 147 00:07:11,850 --> 00:07:12,683 ‫Also wenn. name 148 00:07:15,477 --> 00:07:19,310 ‫ist dies, dann sollte error gleich handle error sein. 149 00:07:19,310 --> 00:07:23,463 ‫Okay. 150 00:07:27,010 --> 00:07:27,843 ‫Lassen Sie uns 151 00:07:27,843 --> 00:07:30,430 ‫also weitermachen und diese Funktion tatsächlich irgendwo hier oben erstellen. 152 00:07:30,430 --> 00:07:31,953 ‫Und dieser ist eigentlich ganz einfach. 153 00:07:35,782 --> 00:07:37,810 ‫Alles, was es tut, ist, einen Fehler zu 154 00:07:37,810 --> 00:07:39,760 ‫akzeptieren und dann einen neuen AppError zurückzugeben. 155 00:07:39,760 --> 00:07:41,433 ‫Okay? 156 00:07:44,480 --> 00:07:45,320 ‫In dieser 157 00:07:45,320 --> 00:07:48,950 ‫ES6-Pfeilfunktion können wir, wie Sie hoffentlich wissen, diese Einzeiler schreiben, bei 158 00:07:48,950 --> 00:07:50,790 ‫denen wir nicht einmal die 159 00:07:50,790 --> 00:07:53,610 ‫geschweiften Klammern und auch das Schlüsselwort return angeben müssen. 160 00:07:53,610 --> 00:07:55,610 ‫Dies wird also automatisch 161 00:07:55,610 --> 00:07:58,670 ‫und implizit alles zurückgeben, was wir hier eingeben. 162 00:07:58,670 --> 00:08:00,123 ‫Richtig? 163 00:08:01,010 --> 00:08:01,843 ‫Was wir 164 00:08:01,843 --> 00:08:04,763 ‫hier also einfach sagen möchten, ist ungültiges Token, bitte loggen 165 00:08:05,980 --> 00:08:07,273 ‫Sie sich erneut ein. 166 00:08:09,580 --> 00:08:12,640 ‫Und dann ist der Fehlercode wie zuvor 167 00:08:12,640 --> 00:08:15,000 ‫ein 401 für Unauthorized. 168 00:08:15,000 --> 00:08:17,463 ‫Nun, das funktioniert nur in der Produktion, denken Sie daran. 169 00:08:19,497 --> 00:08:22,410 ‫Und wenn wir das jetzt noch einmal machen 170 00:08:22,410 --> 00:08:24,883 ‫würden, würden wir genau dasselbe bekommen. 171 00:08:24,883 --> 00:08:27,730 ‫Lassen Sie uns also tatsächlich hierher zurückkehren und 172 00:08:27,730 --> 00:08:29,890 ‫dies in der Produktion ausführen. 173 00:08:29,890 --> 00:08:32,340 ‫Also npm run start:production. 174 00:08:32,340 --> 00:08:37,340 ‫Ja, einfach so. 175 00:08:39,470 --> 00:08:40,733 ‫Wenn wir dies jetzt noch 176 00:08:41,650 --> 00:08:43,890 ‫einmal versuchen, sehen wir, ob wir unseren Fehler erhalten. 177 00:08:43,890 --> 00:08:45,630 ‫Und das tun wir tatsächlich. 178 00:08:45,630 --> 00:08:47,840 ‫Wenn also gerade ein Benutzer in der 179 00:08:47,840 --> 00:08:50,040 ‫Produktion versucht, mit einem ungültigen Token 180 00:08:50,040 --> 00:08:52,930 ‫auf unsere App zuzugreifen, erhält er nur diese Fehlermeldung. 181 00:08:52,930 --> 00:08:55,890 ‫Gut? 182 00:08:55,890 --> 00:08:57,120 ‫Das ist also der erste Fehler, den wir bekommen können. 183 00:08:57,120 --> 00:08:59,920 ‫Ein anderer ist jedoch, dass der Benutzer versucht, 184 00:08:59,920 --> 00:09:01,560 ‫mit einem bereits abgelaufenen 185 00:09:01,560 --> 00:09:03,500 ‫Token auf die Anwendung zuzugreifen. 186 00:09:03,500 --> 00:09:06,147 ‫Versuchen wir nun, diesen Fehler zu erstellen. 187 00:09:06,147 --> 00:09:08,733 ‫Und um dies zu tun, werde 188 00:09:09,683 --> 00:09:13,080 ‫ich die Zeit bis zum Ablauf des Tokens ändern. 189 00:09:13,080 --> 00:09:14,943 ‫Im Moment haben wir also 90 Tage Zeit. 190 00:09:17,811 --> 00:09:19,190 ‫Sagen wir mal fünf Sekunden. 191 00:09:19,190 --> 00:09:22,183 ‫Okay. 192 00:09:23,078 --> 00:09:23,911 ‫Sparen Sie. 193 00:09:23,911 --> 00:09:24,870 ‫Und jetzt versuchen Sie sich erneut anzumelden. 194 00:09:24,870 --> 00:09:26,823 ‫Also lasst uns das hier auch tatsächlich speichern. 195 00:09:28,090 --> 00:09:30,943 ‫Also, in Benutzer und dann einloggen. 196 00:09:32,920 --> 00:09:37,043 ‫Wir können uns also einloggen und erhalten dann einen neuen 197 00:09:39,060 --> 00:09:43,100 ‫Token, der jedoch nur fünf Sekunden gültig ist. 198 00:09:43,100 --> 00:09:46,100 ‫Und so sollten diese fünf Sekunden zu diesem Zeitpunkt verstrichen sein. 199 00:09:46,100 --> 00:09:49,550 ‫Also werde ich jetzt dieses Token kopieren und versuchen, mit diesem 200 00:09:49,550 --> 00:09:51,690 ‫Token auf unsere geschützte Route zuzugreifen. 201 00:09:51,690 --> 00:09:55,713 ‫Also füge es hier ein. 202 00:09:58,529 --> 00:09:59,362 ‫Und jetzt wollen wir sehen, was wir bekommen. 203 00:09:59,362 --> 00:10:01,630 ‫Und tatsächlich hat es aus irgendeinem Grund funktioniert. 204 00:10:01,630 --> 00:10:04,280 ‫Werfen wir also noch einmal einen Blick auf unseren JWT-Debugger. 205 00:10:04,280 --> 00:10:08,593 ‫Und es heißt, erstellt am 2. Mai, läuft aber 206 00:10:11,620 --> 00:10:14,160 ‫erst am 31. Juli ab. 207 00:10:14,160 --> 00:10:16,720 ‫Also ist bei dieser Token-Erstellung etwas schief gelaufen, denke ich. 208 00:10:16,720 --> 00:10:21,023 ‫Also ändern wir das hier noch einmal. 209 00:10:22,140 --> 00:10:23,810 ‫Und ich werde nur fünf hier setzen. 210 00:10:23,810 --> 00:10:25,993 ‫Und so, dass fünf dann für 211 00:10:27,270 --> 00:10:30,340 ‫fünf Millisekunden stehen sollte, oder ich kann sogar 5000 212 00:10:30,340 --> 00:10:32,630 ‫sagen, was dann fünf Sekunden sein sollten. 213 00:10:32,630 --> 00:10:34,733 ‫Okay. 214 00:10:37,680 --> 00:10:38,890 ‫Lassen Sie mich es jetzt noch einmal speichern, um den Server neu zu starten. 215 00:10:38,890 --> 00:10:42,363 ‫Versuchen Sie es erneut. 216 00:10:43,240 --> 00:10:44,570 ‫Melden Sie sich also hier erneut an. 217 00:10:44,570 --> 00:10:46,113 ‫Gut. 218 00:10:47,680 --> 00:10:48,600 ‫Jetzt müssen wir 219 00:10:48,600 --> 00:10:52,930 ‫also nur noch fünf Sekunden warten, und diese Zeit sollte zu diesem Zeitpunkt bereits vergangen sein. 220 00:10:52,930 --> 00:10:56,933 ‫Fügen Sie es hier wieder ein. 221 00:11:00,230 --> 00:11:01,500 ‫Und los geht's. 222 00:11:01,500 --> 00:11:03,560 ‫Und tatsächlich erhalten wir einen Fehler. 223 00:11:03,560 --> 00:11:05,860 ‫Denken Sie jetzt daran, dass 224 00:11:05,860 --> 00:11:09,850 ‫dies im Grunde der Standardfehler ist, den wir erhalten, falls 225 00:11:09,850 --> 00:11:13,230 ‫wir diesen Fehler in unserer Fehlerbehandlung nicht richtig behandeln. 226 00:11:13,230 --> 00:11:14,700 ‫Richtig? 227 00:11:14,700 --> 00:11:15,750 ‫Schauen wir uns also den Fehler einmal an. 228 00:11:15,750 --> 00:11:18,840 ‫Und tatsächlich haben wir es hier in der Konsole. 229 00:11:18,840 --> 00:11:21,350 ‫Mal sehen, woher das kommt. 230 00:11:21,350 --> 00:11:24,620 ‫Und ja, es kommt von diesem Ort. 231 00:11:24,620 --> 00:11:26,673 ‫Dies ist also der Fall, wenn wir einen unbekannten Fehler haben. 232 00:11:27,760 --> 00:11:31,690 ‫Denken Sie daran, dass ein Fehler, der nicht 233 00:11:31,690 --> 00:11:34,090 ‫als Betriebsfehler gekennzeichnet ist, daher 234 00:11:34,090 --> 00:11:35,640 ‫protokolliert wird. 235 00:11:35,640 --> 00:11:37,543 ‫Also loggen wir es hier ein und 236 00:11:38,500 --> 00:11:39,650 ‫senden dann diese generische Fehlermeldung 237 00:11:39,650 --> 00:11:42,150 ‫an den Client, also die, die wir gerade in 238 00:11:42,150 --> 00:11:43,270 ‫Postman gesehen haben. 239 00:11:43,270 --> 00:11:45,610 ‫Aber hier haben wir eigentlich die Details zu diesem Fehler. 240 00:11:45,610 --> 00:11:48,100 ‫Dieser hat den Namen TokenExpiredError. 241 00:11:48,100 --> 00:11:51,480 ‫Gut. 242 00:11:51,480 --> 00:11:52,313 ‫Also lassen Sie uns jetzt auch mit diesem umgehen. 243 00:11:52,313 --> 00:11:55,360 ‫Also kopiere ich es jetzt und erstelle dann einfach 244 00:11:55,360 --> 00:11:57,171 ‫ein anderes, wenn hier. 245 00:11:57,171 --> 00:12:02,171 ‫Also wenn der Fehler. name ist gleich diesem, also nehmen wir 246 00:12:02,300 --> 00:12:07,300 ‫an, behandeln Sie JWTExpiredError 247 00:12:08,980 --> 00:12:10,343 ‫mit 248 00:12:12,711 --> 00:12:14,461 ‫dem Pfeil. 249 00:12:18,640 --> 00:12:20,233 ‫Lass es uns kopieren und gleich hier ablegen. 250 00:12:22,568 --> 00:12:25,750 ‫Und so ist dies natürlich dem vorherigen sehr ähnlich. 251 00:12:33,186 --> 00:12:37,770 ‫Ihr Token ist abgelaufen. 252 00:12:37,770 --> 00:12:40,493 ‫Bitte melden Sie sich erneut an. 253 00:12:43,940 --> 00:12:45,193 ‫Und wieder mit einem 401 Fehlercode. 254 00:12:48,670 --> 00:12:51,423 ‫Okay, versuchen wir es noch einmal. 255 00:12:52,360 --> 00:12:54,270 ‫Und genau das ist die Fehlermeldung, die 256 00:12:54,270 --> 00:12:56,043 ‫wir jetzt hier sehen sollten. 257 00:12:56,043 --> 00:12:58,023 ‫Gut. 258 00:12:59,430 --> 00:13:00,263 ‫Und tatsächlich ist es so. 259 00:13:00,263 --> 00:13:01,263 ‫Toll. 260 00:13:02,480 --> 00:13:03,520 ‫Lassen Sie uns den 261 00:13:03,520 --> 00:13:04,980 ‫Vorgang hier beenden und natürlich im Dev-Modus starten. 262 00:13:04,980 --> 00:13:07,560 ‫Also npm 263 00:13:07,560 --> 00:13:10,213 ‫starten und in Ordnung. 264 00:13:11,700 --> 00:13:13,740 ‫Also dieses hier brauchen wir nicht mehr, also schließen wir es. 265 00:13:13,740 --> 00:13:17,460 ‫Oder lassen Sie uns diesen kleinen Fehler hier beheben, denn tatsächlich 266 00:13:17,460 --> 00:13:19,880 ‫verwenden wir diesen Fehler hier überhaupt nicht. 267 00:13:19,880 --> 00:13:23,113 ‫Also lass es uns loswerden. 268 00:13:24,170 --> 00:13:25,423 ‫Und dann hier unten, wir brauchen es dort nicht weiterzugeben. 269 00:13:29,260 --> 00:13:32,063 ‫Cool. 270 00:13:39,290 --> 00:13:40,123 ‫Wir müssen dies natürlich auch wieder auf 90 Tage ändern. 271 00:13:41,060 --> 00:13:44,423 ‫Gut. 272 00:13:47,200 --> 00:13:48,040 ‫Um ganz 273 00:13:48,040 --> 00:13:51,560 ‫sicher zu gehen, loggen wir uns also noch einmal hier ein, 274 00:13:51,560 --> 00:13:52,803 ‫kopieren den Token 275 00:13:53,830 --> 00:13:55,513 ‫und legen ihn hier ab. 276 00:13:56,680 --> 00:13:59,050 ‫Nun, dieser Vorgang hier, den Token zu 277 00:13:59,050 --> 00:14:01,750 ‫kopieren und dann hier in diesen Header einzufügen, 278 00:14:01,750 --> 00:14:04,190 ‫mag etwas seltsam erscheinen, und wir werden das 279 00:14:04,190 --> 00:14:05,640 ‫in einem der 280 00:14:05,640 --> 00:14:07,230 ‫zukünftigen Videos beheben, sodass dieser 281 00:14:07,230 --> 00:14:09,030 ‫Vorgang im Grunde automatisch abläuft. 282 00:14:09,030 --> 00:14:12,070 ‫Aber jetzt ist es wichtig, dass es 283 00:14:12,070 --> 00:14:13,970 ‫jetzt tatsächlich wieder funktioniert. 284 00:14:13,970 --> 00:14:16,750 ‫Wir können diese Konsole also tatsächlich loswerden. Melden Sie sich hier an und fahren Sie 285 00:14:16,750 --> 00:14:21,027 ‫mit dem nächsten Schritt fort. 286 00:14:21,027 --> 00:14:24,250 ‫Und wir könnten jetzt tatsächlich hier aufhören, wenn wir wollten. 287 00:14:24,250 --> 00:14:27,010 ‫Und wieder würden die meisten Tutorials, 288 00:14:27,010 --> 00:14:30,130 ‫die Sie dort finden werden, tatsächlich hier aufhören. 289 00:14:30,130 --> 00:14:32,420 ‫Aber das ist noch nicht wirklich sicher genug. 290 00:14:32,420 --> 00:14:35,210 ‫Was ist also beispielsweise, wenn der 291 00:14:35,210 --> 00:14:37,550 ‫Benutzer zwischenzeitlich gelöscht wurde? 292 00:14:37,550 --> 00:14:39,840 ‫Das Token wird also noch existieren, aber wenn 293 00:14:39,840 --> 00:14:41,800 ‫der Benutzer nicht mehr existiert, dann 294 00:14:41,800 --> 00:14:43,900 ‫wollen wir ihn eigentlich nicht einloggen, oder? 295 00:14:43,900 --> 00:14:47,780 ‫Oder noch schlimmer, was ist, wenn der Benutzer sein 296 00:14:47,780 --> 00:14:50,070 ‫Passwort nach der Ausgabe des 297 00:14:50,070 --> 00:14:52,130 ‫Tokens tatsächlich geändert hat? 298 00:14:52,130 --> 00:14:54,360 ‫Nun, das sollte auch nicht funktionieren, oder? 299 00:14:54,360 --> 00:14:56,950 ‫Stellen Sie sich beispielsweise vor, 300 00:14:56,950 --> 00:15:00,750 ‫dass jemand das JSON-Webtoken von einem Benutzer gestohlen hat. 301 00:15:00,750 --> 00:15:01,870 ‫Um sich davor 302 00:15:01,870 --> 00:15:04,380 ‫zu schützen, ändert der Benutzer dann aber sein Passwort. 303 00:15:04,380 --> 00:15:06,770 ‫Und so sollte natürlich das alte Token, das 304 00:15:06,770 --> 00:15:09,270 ‫vor der Passwortänderung ausgestellt wurde, nicht mehr gültig sein. 305 00:15:09,270 --> 00:15:12,940 ‫Es sollte daher nicht akzeptiert werden, auf geschützte Routen zuzugreifen. 306 00:15:12,940 --> 00:15:16,906 ‫Und das ist die Art von Sachen, die wir hier in 307 00:15:16,906 --> 00:15:19,550 ‫Schritt drei und Schritt vier implementieren werden. 308 00:15:19,550 --> 00:15:22,060 ‫Als erstes ist also zu prüfen, ob der Benutzer 309 00:15:22,060 --> 00:15:23,120 ‫tatsächlich noch existiert. 310 00:15:23,120 --> 00:15:26,060 ‫Und so sollte das am einfachsten sein. 311 00:15:26,060 --> 00:15:28,690 ‫Sagen wir einfach Benutzer. findById. 312 00:15:28,690 --> 00:15:32,463 ‫Aus diesem Grund haben wir die ID 313 00:15:36,568 --> 00:15:38,440 ‫jetzt tatsächlich in der Nutzlast, 314 00:15:38,440 --> 00:15:40,540 ‫weil wir jetzt diese ID verwenden und 315 00:15:40,540 --> 00:15:42,767 ‫den Benutzer nur mit dieser ID abfragen können. 316 00:15:42,767 --> 00:15:46,530 ‫Also entschlüsselt. Ich würde. 317 00:15:46,530 --> 00:15:49,390 ‫Gut? 318 00:15:49,390 --> 00:15:50,223 ‫Damit sollte dann der neue Benutzer gefunden werden. 319 00:15:50,223 --> 00:15:53,110 ‫Und natürlich müssen wir das abwarten und 320 00:15:53,110 --> 00:15:55,860 ‫dann in einer Variablen speichern. 321 00:15:55,860 --> 00:15:59,560 ‫Ich nenne es den freshUser. 322 00:15:59,560 --> 00:16:01,480 ‫Gut? 323 00:16:03,148 --> 00:16:03,981 ‫Weil es nicht wirklich ein neuer Benutzer ist. 324 00:16:03,981 --> 00:16:05,460 ‫Das ist nur, wenn wir eine erstellen. 325 00:16:05,460 --> 00:16:07,300 ‫Aber das ist nicht wirklich neu, es ist wirklich 326 00:16:07,300 --> 00:16:09,030 ‫nur der Benutzer anhand der entschlüsselten ID. 327 00:16:09,030 --> 00:16:12,980 ‫Okay? 328 00:16:12,980 --> 00:16:13,870 ‫Und wir 329 00:16:13,870 --> 00:16:16,833 ‫können dies tun, um 100% sicher zu sein, dass die 330 00:16:16,833 --> 00:16:18,990 ‫ID tatsächlich korrekt ist, denn wenn wir es 331 00:16:18,990 --> 00:16:22,460 ‫bis zu diesem Punkt des Codes hier geschafft haben, bedeutet dies, dass der 332 00:16:22,460 --> 00:16:25,110 ‫Überprüfungsprozess, den wir zuvor hier durchgeführt haben, erfolgreich war. 333 00:16:25,110 --> 00:16:28,200 ‫Andernfalls hätte dies einen Fehler verursacht, der 334 00:16:28,200 --> 00:16:30,220 ‫die Fortsetzung der Funktion 335 00:16:30,220 --> 00:16:31,490 ‫verhindert hätte. 336 00:16:31,490 --> 00:16:33,410 ‫Auch hier ist dieser 337 00:16:33,410 --> 00:16:36,660 ‫Überprüfungsprozess für die Überprüfung verantwortlich, wenn niemand die 338 00:16:36,660 --> 00:16:38,620 ‫ID geändert hat, die sich 339 00:16:38,620 --> 00:16:40,900 ‫in der Nutzlast dieses Tokens befindet. 340 00:16:40,900 --> 00:16:43,033 ‫Aus diesem Grund können wir 341 00:16:43,970 --> 00:16:46,970 ‫100% sicher sein, dass der Benutzer, für den wir 342 00:16:46,970 --> 00:16:50,600 ‫das JWT ausgestellt haben, genau derjenige ist, dessen ID jetzt in 343 00:16:50,600 --> 00:16:52,790 ‫der decodierten Nutzlast enthalten ist, also dieser. 344 00:16:52,790 --> 00:16:56,810 ‫Okay? 345 00:16:56,810 --> 00:16:57,690 ‫Der Verifizierungsprozess ist also wirklich der Schlüssel. 346 00:16:57,690 --> 00:17:00,440 ‫Es ist wirklich das, was all dies funktioniert. 347 00:17:00,440 --> 00:17:02,440 ‫Wie auch immer, jetzt müssen wir überprüfen, ob 348 00:17:04,730 --> 00:17:06,410 ‫es tatsächlich einen freshUser gibt. 349 00:17:06,410 --> 00:17:09,570 ‫Und wenn nicht, dann geben wir natürlich 350 00:17:09,570 --> 00:17:11,570 ‫einen neuen Fehler zurück. 351 00:17:11,570 --> 00:17:13,844 ‫Wenn also kein freshUser vorhanden ist, kehren 352 00:17:13,844 --> 00:17:16,577 ‫Sie von dieser Middleware zurück und rufen Sie 353 00:17:19,880 --> 00:17:22,100 ‫die nächste mit einem Fehler auf. 354 00:17:22,100 --> 00:17:24,083 ‫Dies ist also ein Muster, das 355 00:17:24,920 --> 00:17:27,100 ‫wir an dieser Stelle immer wieder sehen, oder? 356 00:17:27,100 --> 00:17:29,403 ‫Der Token existiert also nicht 357 00:17:30,350 --> 00:17:31,490 ‫mehr. 358 00:17:35,470 --> 00:17:39,173 ‫Und eigentlich ist es umgekehrt. 359 00:17:40,810 --> 00:17:42,750 ‫Der zum Token gehörende 360 00:17:42,750 --> 00:17:45,200 ‫Benutzer existiert also tatsächlich nicht mehr. 361 00:17:47,170 --> 00:17:48,680 ‫Richtig? 362 00:17:48,680 --> 00:17:49,513 ‫Und dann die 401. 363 00:17:49,513 --> 00:17:51,297 ‫Okay. 364 00:17:53,780 --> 00:17:54,920 ‫Lassen Sie uns das also noch einmal testen. 365 00:17:54,920 --> 00:17:57,860 ‫Und lassen Sie uns dafür tatsächlich einen neuen Benutzer erstellen. 366 00:17:57,860 --> 00:18:00,843 ‫Testen Sie also einfach mit demselben Passwort, damit wir hier 367 00:18:02,620 --> 00:18:04,880 ‫immer das gleiche Passwort verwenden, nur um unser 368 00:18:04,880 --> 00:18:06,590 ‫Testen etwas einfacher zu machen. 369 00:18:06,590 --> 00:18:09,160 ‫Und ich weiß, dass all diese Tests hier das 370 00:18:09,160 --> 00:18:11,070 ‫Video ziemlich lange dauern lassen, aber 371 00:18:11,070 --> 00:18:14,440 ‫natürlich ist es wirklich wichtig, dass wir alles testen, was wir 372 00:18:14,440 --> 00:18:15,900 ‫tun, insbesondere bei 373 00:18:15,900 --> 00:18:17,950 ‫einem so wichtigen Thema wie der Authentifizierung. 374 00:18:17,950 --> 00:18:21,713 ‫Also verwende ich jetzt dieses JWT hier, also füge 375 00:18:23,071 --> 00:18:27,780 ‫ich es hier ein, aber vor dem Senden der Anfrage werde 376 00:18:27,780 --> 00:18:30,630 ‫ich diesen Benutzer natürlich sofort löschen. 377 00:18:30,630 --> 00:18:33,573 ‫Okay? 378 00:18:34,650 --> 00:18:35,690 ‫Nehmen wir also noch einmal 379 00:18:35,690 --> 00:18:37,690 ‫an, dass jemand einen Benutzer erstellt und sich dann angemeldet 380 00:18:37,690 --> 00:18:40,020 ‫hat, und nehmen wir an, der Benutzer wurde nach einiger Zeit gelöscht. 381 00:18:40,020 --> 00:18:43,500 ‫Aber in der Zwischenzeit könnte jemand Zugang zu diesem 382 00:18:43,500 --> 00:18:44,333 ‫JWT 383 00:18:44,333 --> 00:18:47,410 ‫erhalten und nun versuchen, sich als dieser Benutzer 384 00:18:47,410 --> 00:18:50,030 ‫anzumelden, der tatsächlich bereits gelöscht wurde. 385 00:18:50,030 --> 00:18:52,580 ‫Und so sollten wir das wiederum nicht zulassen. 386 00:18:52,580 --> 00:18:55,520 ‫Lassen Sie mich diesen Benutzer jetzt hier löschen. 387 00:18:55,520 --> 00:18:57,713 ‫Und los gehts. 388 00:18:59,010 --> 00:18:59,943 ‫Und so testen wir es jetzt. 389 00:19:01,720 --> 00:19:03,630 ‫Denken Sie auch hier daran, dass der Benutzer, 390 00:19:03,630 --> 00:19:07,060 ‫der zu der ID gehört, die sich in dieser Nutzlast befindet, jetzt nicht mehr vorhanden ist. 391 00:19:07,060 --> 00:19:10,690 ‫Also mal sehen. 392 00:19:10,690 --> 00:19:12,040 ‫Und tatsächlich erhalten wir diese Fehlermeldung, die wir gerade erstellt haben. 393 00:19:12,040 --> 00:19:16,313 ‫Damit funktioniert es auch. 394 00:19:17,520 --> 00:19:20,200 ‫Und gehen wir zum letzten. 395 00:19:20,200 --> 00:19:22,400 ‫Schritt Nummer vier, überprüfen Sie, ob der Benutzer 396 00:19:22,400 --> 00:19:23,830 ‫kürzlich sein Passwort geändert hat. 397 00:19:23,830 --> 00:19:27,070 ‫Also im Grunde nach der Ausgabe des Tokens. 398 00:19:27,070 --> 00:19:30,100 ‫Und um diesen Test zu implementieren, werden wir tatsächlich 399 00:19:30,100 --> 00:19:31,550 ‫eine weitere Instanzmethode erstellen. 400 00:19:31,550 --> 00:19:34,260 ‫Im Grunde also eine Methode, 401 00:19:34,260 --> 00:19:37,030 ‫die für alle Dokumente verfügbar sein wird. 402 00:19:37,030 --> 00:19:38,330 ‫Dokumente sind also Instanzen eines Modells. 403 00:19:38,330 --> 00:19:41,410 ‫Gut? 404 00:19:41,410 --> 00:19:42,243 ‫Und wir tun 405 00:19:42,243 --> 00:19:44,490 ‫dies, weil wir für diese Überprüfung ziemlich viel Code benötigen. 406 00:19:44,490 --> 00:19:46,540 ‫Dieser Code gehört also 407 00:19:46,540 --> 00:19:50,040 ‫eigentlich zum Benutzermodell und nicht wirklich zum Controller. 408 00:19:50,040 --> 00:19:51,970 ‫Okay? 409 00:19:51,970 --> 00:19:52,803 ‫Machen wir das also 410 00:19:52,803 --> 00:19:55,050 ‫genau so, wie wir es zuvor bei der Überprüfung des Passworts getan haben. 411 00:19:55,050 --> 00:19:57,270 ‫Im Benutzermodell haben wir diese statische 412 00:19:57,270 --> 00:19:59,840 ‫Instanzmethode korrektPassword bereits implementiert, erinnern Sie sich? 413 00:19:59,840 --> 00:20:04,710 ‫Und so erstellen wir jetzt einen weiteren. 414 00:20:04,710 --> 00:20:06,903 ‫Also userSchema. Methoden. geändertPasswortNach. 415 00:20:08,339 --> 00:20:13,339 ‫Funktionieren Sie also, und 416 00:20:22,390 --> 00:20:24,550 ‫in diese Funktion übergeben wir den JWT-Zeitstempel. 417 00:20:24,550 --> 00:20:27,530 ‫Im Grunde also der Zeitstempel, der angibt, wann 418 00:20:27,530 --> 00:20:29,630 ‫das Token ausgestellt wurde. 419 00:20:29,630 --> 00:20:32,190 ‫Nennen wir das also JWTTimestamp. 420 00:20:32,190 --> 00:20:34,437 ‫Gut. 421 00:20:40,310 --> 00:20:41,143 ‫Und standardmäßig geben wir von dieser Methode false zurück. 422 00:20:41,143 --> 00:20:44,600 ‫Und das bedeutet dann, dass der Benutzer sein Passwort 423 00:20:44,600 --> 00:20:45,720 ‫nach der 424 00:20:45,720 --> 00:20:48,320 ‫Ausgabe des Tokens nicht geändert hat. 425 00:20:48,320 --> 00:20:50,410 ‫Okay? 426 00:20:50,410 --> 00:20:51,860 ‫Lassen Sie uns das hier setzen, geben wir im Grunde standardmäßig false zurück. 427 00:20:51,860 --> 00:20:56,860 ‫Okay. 428 00:20:58,470 --> 00:20:59,303 ‫Aber dann 429 00:20:59,303 --> 00:21:02,987 ‫haben wir auch if this, und denken Sie daran, dass in einer Instanzmethode 430 00:21:02,987 --> 00:21:05,827 ‫das Schlüsselwort this immer auf das aktuelle Dokument zeigt. 431 00:21:05,827 --> 00:21:09,477 ‫Und so haben wir hier also Zugriff auf die Eigenschaften. 432 00:21:09,477 --> 00:21:13,210 ‫Nun müssen wir tatsächlich in unserem Schema ein Feld für das 433 00:21:13,210 --> 00:21:16,280 ‫Datum erstellen, an dem das Passwort geändert wurde. 434 00:21:16,280 --> 00:21:18,750 ‫Das haben wir also noch nicht. 435 00:21:18,750 --> 00:21:20,050 ‫Also fügen wir es hier schnell hinzu. 436 00:21:21,200 --> 00:21:23,713 ‫Also passwordChangedAt, und der Typ davon 437 00:21:25,980 --> 00:21:27,813 ‫ist ein Datum. 438 00:21:31,320 --> 00:21:34,520 ‫Nun wird diese Eigenschaft passwordChangedAt 439 00:21:34,520 --> 00:21:37,890 ‫hier natürlich immer geändert, wenn jemand 440 00:21:37,890 --> 00:21:40,160 ‫das Passwort ändert. 441 00:21:40,160 --> 00:21:42,910 ‫Im Moment haben wir diese Logik nirgendwo, und 442 00:21:42,910 --> 00:21:45,270 ‫daher definieren wir diese Eigenschaft nirgendwo. 443 00:21:45,270 --> 00:21:48,743 ‫Und so haben die meisten Dokumente, 444 00:21:49,630 --> 00:21:53,230 ‫also die meisten Benutzer, diese Eigenschaft einfach nicht 445 00:21:53,230 --> 00:21:56,720 ‫in ihren Daten, also in ihrem Objekt, oder? 446 00:21:56,720 --> 00:21:58,600 ‫Und das müssen wir natürlich testen. 447 00:21:58,600 --> 00:22:01,363 ‫Okay? 448 00:22:03,430 --> 00:22:04,610 ‫Wenn also die 449 00:22:04,610 --> 00:22:07,740 ‫Eigenschaft passwordChangedAt vorhanden ist, möchten wir den Vergleich nur dann durchführen. 450 00:22:07,740 --> 00:22:11,510 ‫Okay? 451 00:22:11,510 --> 00:22:12,343 ‫Aber wenn 452 00:22:12,343 --> 00:22:16,010 ‫nicht, also wenn passwordChanged nicht existiert, bedeutet dies, dass der Benutzer das 453 00:22:16,010 --> 00:22:17,640 ‫Passwort nie wirklich geändert hat, 454 00:22:17,640 --> 00:22:20,020 ‫und daher können wir einfach false zurückgeben. 455 00:22:20,020 --> 00:22:23,171 ‫Dies ist also wieder unsere Standardeinstellung, was bedeutet, 456 00:22:23,171 --> 00:22:25,560 ‫dass der Benutzer das Passwort 457 00:22:25,560 --> 00:22:28,190 ‫nach diesem Zeitstempel nicht geändert hat. 458 00:22:28,190 --> 00:22:30,540 ‫Okay. 459 00:22:30,540 --> 00:22:31,373 ‫Und jetzt, 460 00:22:31,373 --> 00:22:35,760 ‫nur um zu beginnen, lassen Sie uns dies tatsächlich in die Konsole einloggen. passwordChangedAt und natürlich auch der JWTTimestamp, nur damit wir 461 00:22:35,760 --> 00:22:37,933 ‫sehen können, 462 00:22:39,370 --> 00:22:42,010 ‫wie wir sie vergleichen können. 463 00:22:42,010 --> 00:22:44,950 ‫Gut. 464 00:22:44,950 --> 00:22:45,783 ‫Und jetzt müssen 465 00:22:47,560 --> 00:22:49,690 ‫wir tatsächlich einen Benutzer erstellen, der diese Eigenschaft hat, okay? 466 00:22:49,690 --> 00:22:52,720 ‫Und später in dem Abschnitt, in dem wir die 467 00:22:52,720 --> 00:22:54,260 ‫Logik zum Ändern des 468 00:22:54,260 --> 00:22:57,280 ‫Passworts implementieren, werden wir dann diese Eigenschaft festlegen. 469 00:22:57,280 --> 00:22:59,760 ‫Okay? 470 00:22:59,760 --> 00:23:00,593 ‫Aber jetzt werden 471 00:23:00,593 --> 00:23:04,140 ‫wir es im Grunde künstlich hier setzen, wenn wir einen neuen Benutzer erstellen. 472 00:23:04,140 --> 00:23:06,260 ‫Okay? 473 00:23:06,260 --> 00:23:07,093 ‫Stellen wir das also hier. 474 00:23:08,690 --> 00:23:10,130 ‫Und hier wird jedes Datum tatsächlich dienen. 475 00:23:10,130 --> 00:23:12,810 ‫Sagen wir also den 30. April 2019 hier. 476 00:23:12,810 --> 00:23:17,810 ‫Und das sollte dann problemlos in MongoDB geparst werden. 477 00:23:18,430 --> 00:23:21,313 ‫Lassen Sie uns das versuchen, sehen, ob es funktioniert. 478 00:23:22,460 --> 00:23:24,293 ‫Und das hat nicht funktioniert. 479 00:23:25,210 --> 00:23:26,520 ‫Sagen wir, es konnte das Datum nicht wirklich analysieren. 480 00:23:26,520 --> 00:23:29,913 ‫Und eigentlich muss ich mit dem Jahr beginnen und 481 00:23:30,980 --> 00:23:33,710 ‫dann mit dem Tag am Ende. 482 00:23:33,710 --> 00:23:36,400 ‫Also 2019 und dann 30. April. 483 00:23:36,400 --> 00:23:41,050 ‫Versuchen Sie das noch einmal. 484 00:23:41,050 --> 00:23:42,103 ‫Und Sie sehen, dass es jetzt tatsächlich funktioniert. 485 00:23:43,190 --> 00:23:45,300 ‫Wir haben also dieses geparste Datum hier. 486 00:23:45,300 --> 00:23:48,210 ‫Okay? 487 00:23:48,210 --> 00:23:49,350 ‫Um das Ergebnis 488 00:23:49,350 --> 00:23:51,910 ‫tatsächlich zu sehen, müssen wir diese Methode natürlich aufrufen. 489 00:23:51,910 --> 00:23:55,040 ‫Okay? 490 00:23:55,040 --> 00:23:56,560 ‫Das machen wir hier in Schritt vier. 491 00:23:56,560 --> 00:23:59,033 ‫Okay? 492 00:24:00,010 --> 00:24:01,110 ‫Denken Sie also 493 00:24:01,110 --> 00:24:04,630 ‫daran, dass wir diese Instanzmethode für ein Benutzerdokument aufrufen können. 494 00:24:04,630 --> 00:24:06,200 ‫Also freshUser. changePasswordAfter und dann 495 00:24:06,200 --> 00:24:09,197 ‫dieser Zeitstempel. 496 00:24:14,837 --> 00:24:17,370 ‫Das ist also bei dekodiert. iat, also im Grunde ausgestellt. 497 00:24:17,370 --> 00:24:22,370 ‫Gut. 498 00:24:25,450 --> 00:24:26,350 ‫Sehen wir uns also einfach das Ergebnis davon an. 499 00:24:26,350 --> 00:24:29,130 ‫Und so sollte dies jetzt natürlich nicht hier 500 00:24:29,130 --> 00:24:32,953 ‫sein, also sollte dies nun diese beiden Werte in die Konsole einloggen. 501 00:24:33,870 --> 00:24:37,123 ‫Okay. 502 00:24:39,320 --> 00:24:40,153 ‫Jetzt muss 503 00:24:40,153 --> 00:24:43,170 ‫ich mich natürlich mit genau diesem Benutzer einloggen, also mit 504 00:24:43,170 --> 00:24:44,223 ‫Test, also los geht's. 505 00:24:47,780 --> 00:24:48,853 ‫Einloggen. 506 00:24:50,250 --> 00:24:51,173 ‫Kopieren Sie dieses Token erneut hierher. 507 00:24:53,090 --> 00:24:56,200 ‫Und wieder werden wir das 508 00:24:56,200 --> 00:24:59,580 ‫im nächsten Video im Grunde automatisieren. 509 00:24:59,580 --> 00:25:01,233 ‫Okay. 510 00:25:02,740 --> 00:25:03,700 ‫Fügen Sie es hier ein. 511 00:25:03,700 --> 00:25:04,673 ‫Und jetzt bekommen wir diesen Fehler hier tatsächlich. 512 00:25:05,670 --> 00:25:08,312 ‫Also habe ich diesen Funktionsnamen hier einfach falsch geschrieben. 513 00:25:08,312 --> 00:25:13,312 ‫Nun, kopieren wir es einfach. 514 00:25:13,670 --> 00:25:14,920 ‫Versuchen Sie es erneut. 515 00:25:16,410 --> 00:25:17,403 ‫Oh Mann. 516 00:25:18,780 --> 00:25:20,150 ‫Was läuft jetzt schief? 517 00:25:20,150 --> 00:25:21,823 ‫Und wie ich sehe, habe ich dieses Protokoll hier einfach vergessen. 518 00:25:25,420 --> 00:25:27,633 ‫Also noch ein blöder Fehler. 519 00:25:28,752 --> 00:25:30,090 ‫Habe das wahrscheinlich kommen sehen. 520 00:25:30,090 --> 00:25:32,320 ‫Aber jetzt geht es los. 521 00:25:32,320 --> 00:25:33,550 ‫Es hat also 522 00:25:33,550 --> 00:25:35,120 ‫alles gut geklappt und alles, was 523 00:25:35,120 --> 00:25:37,450 ‫wir jetzt wirklich sehen wollten, sind diese beiden Ergebnisse. 524 00:25:37,450 --> 00:25:39,560 ‫Wir haben also im Grunde dieses eine 525 00:25:39,560 --> 00:25:43,110 ‫hier dieses Datumsformat und dann das andere in diesem Millisekunden- oder zweiten 526 00:25:43,110 --> 00:25:43,943 ‫Zeitstempel hier. 527 00:25:43,943 --> 00:25:47,600 ‫Also müssen wir dieses passwordChangedAt 528 00:25:47,600 --> 00:25:51,670 ‫jetzt auch in einen solchen Zeitstempel konvertieren. 529 00:25:51,670 --> 00:25:54,240 ‫Gut? 530 00:25:54,240 --> 00:25:55,073 ‫Lassen Sie uns dafür eine neue Variable erstellen. 531 00:25:55,073 --> 00:25:57,853 ‫Also geänderter Zeitstempel. 532 00:25:59,560 --> 00:26:01,330 ‫Und das können wir gebrauchen. passwordChangedAt. Zeit kriegen. 533 00:26:03,800 --> 00:26:06,100 ‫Okay? 534 00:26:12,730 --> 00:26:13,563 ‫Das ist 535 00:26:13,563 --> 00:26:16,913 ‫also eine der vielen, vielen Datumsfunktionen, die uns JavaScript bietet. 536 00:26:16,913 --> 00:26:18,563 ‫Gut. 537 00:26:19,450 --> 00:26:20,960 ‫Und jetzt lassen Sie uns 538 00:26:20,960 --> 00:26:23,760 ‫diese beiden schnell vergleichen, denn wir sind noch nicht ganz fertig. 539 00:26:23,760 --> 00:26:26,253 ‫Senden Sie es einfach, um die Ergebnisse hier zu sehen. 540 00:26:28,770 --> 00:26:31,930 ‫Was wir hier also im Grunde sehen, ist, dass 541 00:26:31,930 --> 00:26:33,610 ‫dieser hier jetzt im 542 00:26:33,610 --> 00:26:36,580 ‫Grunde in Sekunden ist und dieser in Millisekunden. 543 00:26:36,580 --> 00:26:38,210 ‫Also 1000 mal mehr. 544 00:26:38,210 --> 00:26:40,540 ‫Wir wissen also, dass wir dies durch 1000 545 00:26:40,540 --> 00:26:43,340 ‫teilen und dann das Ganze als ganze Zahl analysieren müssen. 546 00:26:45,630 --> 00:26:48,583 ‫Und dafür verwenden wir parseInt. 547 00:26:50,550 --> 00:26:52,820 ‫Also eine weitere JavaScript-Funktion, die für Zahlen verfügbar ist. 548 00:26:52,820 --> 00:26:57,180 ‫Und dann müssen wir eigentlich auch noch die Basis angeben. 549 00:26:57,180 --> 00:27:00,320 ‫Dies ist also eine Zahl zur Basis 10. 550 00:27:00,320 --> 00:27:02,920 ‫Gut? 551 00:27:02,920 --> 00:27:03,970 ‫Und nun sehen wir uns das Ergebnis noch einmal genauer an. 552 00:27:03,970 --> 00:27:07,373 ‫Und das sieht jetzt viel freundlicher aus. 553 00:27:10,120 --> 00:27:13,360 ‫Okay. 554 00:27:13,360 --> 00:27:14,193 ‫Lassen Sie uns nun unser Ergebnis zurückgeben. 555 00:27:14,193 --> 00:27:17,040 ‫Und denken Sie noch einmal daran, dass falsch bedeutet, dass sich nichts geändert hat. 556 00:27:17,040 --> 00:27:22,040 ‫Okay? 557 00:27:24,500 --> 00:27:25,520 ‫Und nicht geändert 558 00:27:25,520 --> 00:27:30,207 ‫bedeutet im Grunde, dass der Tag oder die Uhrzeit, zu der der Token ausgestellt wurde, 559 00:27:32,300 --> 00:27:34,240 ‫kleiner ist als der geänderte Zeitstempel. 560 00:27:34,240 --> 00:27:37,893 ‫Okay? 561 00:27:40,280 --> 00:27:41,113 ‫Nehmen wir hier nur als 562 00:27:44,330 --> 00:27:45,830 ‫Beispiel an, dass der Token zum Zeitpunkt 100 ausgestellt wurde. 563 00:27:45,830 --> 00:27:49,327 ‫Aber dann haben wir das Passwort geändert, sagen wir zum Zeitpunkt 200. 564 00:27:50,460 --> 00:27:53,843 ‫Okay? 565 00:27:55,240 --> 00:27:56,073 ‫Daher haben 566 00:27:56,073 --> 00:27:57,609 ‫wir das Passwort nach der Ausgabe 567 00:27:57,609 --> 00:27:59,840 ‫des Tokens geändert, und daher ist dies jetzt wahr. 568 00:27:59,840 --> 00:28:01,940 ‫Gut? 569 00:28:01,940 --> 00:28:03,379 ‫Und genau das wollen wir 570 00:28:03,379 --> 00:28:04,810 ‫hier zurückgeben, denn falsch 571 00:28:04,810 --> 00:28:06,910 ‫bedeutet nicht geändert, und wahr bedeutet natürlich geändert. 572 00:28:06,910 --> 00:28:09,200 ‫Und genau das haben wir hier. 573 00:28:09,200 --> 00:28:11,980 ‫Aber jetzt, sagen wir, das Passwort wurde zuletzt 574 00:28:11,980 --> 00:28:13,410 ‫um 200 geändert, 575 00:28:13,410 --> 00:28:15,810 ‫aber erst danach haben wir das 576 00:28:15,810 --> 00:28:18,640 ‫Token ausgegeben, also sagen wir zum Zeitpunkt 300. 577 00:28:18,640 --> 00:28:21,260 ‫Also 300, weniger als 200? 578 00:28:21,260 --> 00:28:23,660 ‫Nein, das ist falsch. 579 00:28:23,660 --> 00:28:25,160 ‫Und so geben wir false zurück, was wiederum nicht geändert bedeutet. 580 00:28:25,160 --> 00:28:29,200 ‫Deshalb verwenden wir hier dieses weniger Zeichen. 581 00:28:29,200 --> 00:28:32,720 ‫Okay? 582 00:28:32,720 --> 00:28:33,553 ‫Kehren wir zu unserem Controller zurück und verwenden diesen tatsächlich. 583 00:28:36,800 --> 00:28:41,800 ‫Wenn also das Passwort tatsächlich geändert wurde, nun, in 584 00:28:45,480 --> 00:28:49,910 ‫diesem Fall wollen wir eigentlich einen Fehler. 585 00:28:49,910 --> 00:28:53,030 ‫Geben Sie also als nächstes wieder einen neuen AppError zurück. 586 00:28:53,030 --> 00:28:57,623 ‫Vor kurzem... 587 00:29:02,970 --> 00:29:04,220 ‫Bitte melden Sie sich erneut an. 588 00:29:11,790 --> 00:29:13,620 ‫Okay. 589 00:29:13,620 --> 00:29:15,030 ‫Und noch einmal Code 401. 590 00:29:15,030 --> 00:29:18,363 ‫Gut. 591 00:29:19,770 --> 00:29:20,820 ‫Auch hier wird 592 00:29:20,820 --> 00:29:23,220 ‫true zurückgegeben, wenn der Benutzer sein Passwort tatsächlich geändert hat. 593 00:29:23,220 --> 00:29:25,790 ‫Also, wenn all dies hier wahr ist, 594 00:29:25,790 --> 00:29:28,540 ‫nun, dann wollen wir genau in diesem Fall, 595 00:29:28,540 --> 00:29:30,600 ‫dass dieser Fehler passiert. 596 00:29:30,600 --> 00:29:33,220 ‫Gut? 597 00:29:33,220 --> 00:29:34,820 ‫Das war also eigentlich der letzte Schritt. 598 00:29:34,820 --> 00:29:37,510 ‫Okay. 599 00:29:37,510 --> 00:29:38,952 ‫Also im Grunde, wenn der Code hier alles 600 00:29:38,952 --> 00:29:41,030 ‫bis zum Ende dieses Codes schafft, wird nur dann der nächste ausgeführt. 601 00:29:41,030 --> 00:29:45,410 ‫Und dann gehen wir mit next zum nächsten Route-Handler, 602 00:29:45,410 --> 00:29:49,100 ‫was effektiv bedeutet, den Zugriff auf diese 603 00:29:49,100 --> 00:29:51,470 ‫geschützte Route zu gewähren. 604 00:29:51,470 --> 00:29:52,783 ‫Lassen Sie uns das hier wirklich setzen. 605 00:29:53,750 --> 00:29:55,740 ‫Gewähren Sie Zugriff auf die geschützte Route. 606 00:29:55,740 --> 00:30:00,740 ‫Okay? 607 00:30:02,340 --> 00:30:03,597 ‫Denn das ist wirklich alles, was das nächste tut. 608 00:30:03,597 --> 00:30:05,310 ‫Weiter führt uns zur 609 00:30:05,310 --> 00:30:08,070 ‫nächsten Middleware, die dann normalerweise der Route-Handler selbst 610 00:30:08,070 --> 00:30:10,880 ‫ist, also diejenige, die die geschützten Daten zurücksendet. 611 00:30:10,880 --> 00:30:14,550 ‫Okay. 612 00:30:14,550 --> 00:30:15,383 ‫Nur als 613 00:30:15,383 --> 00:30:18,540 ‫letztes wollen wir hier tatsächlich die gesamten Nutzerdaten auf die Anfrage stellen. 614 00:30:18,540 --> 00:30:22,930 ‫Wir können also einfach sagen, req, also bitte, . user wird dem freshUser gleich 615 00:30:22,930 --> 00:30:27,100 ‫sein. 616 00:30:27,100 --> 00:30:30,510 ‫Okay. 617 00:30:30,510 --> 00:30:31,343 ‫Und auch 618 00:30:31,343 --> 00:30:32,430 ‫hier erreicht der Code 619 00:30:32,430 --> 00:30:34,930 ‫natürlich immer nur diesen Punkt, wenn alles stimmt. 620 00:30:34,930 --> 00:30:37,470 ‫Okay? 621 00:30:37,470 --> 00:30:38,303 ‫Und so könnte 622 00:30:38,303 --> 00:30:40,710 ‫dies hier vielleicht irgendwann in der Zukunft nützlich sein. 623 00:30:40,710 --> 00:30:42,110 ‫Toll. 624 00:30:43,150 --> 00:30:43,983 ‫Lass uns das einfach noch einmal testen. 625 00:30:43,983 --> 00:30:46,450 ‫Und im Grunde ist diese Veränderung jetzt Vergangenheit. 626 00:30:46,450 --> 00:30:51,450 ‫Also dieses Token, das wir hier haben, oder eigentlich hätte 627 00:30:51,820 --> 00:30:53,840 ‫ich nur dieses 628 00:30:53,840 --> 00:30:56,890 ‫wiederverwenden können, anstatt es erneut zu protokollieren. 629 00:30:56,890 --> 00:30:58,520 ‫Aber egal, dieses Token 630 00:30:58,520 --> 00:31:00,500 ‫wurde ausgegeben, nachdem das Passwort geändert wurde. 631 00:31:00,500 --> 00:31:02,344 ‫Dieses Token sollte nun funktionieren. 632 00:31:02,344 --> 00:31:04,920 ‫Loggen wir uns also noch einmal 633 00:31:04,920 --> 00:31:07,500 ‫ein und versuchen es mit diesem Token. 634 00:31:10,900 --> 00:31:13,203 ‫Und tatsächlich bekommen wir Zugang. 635 00:31:18,020 --> 00:31:20,030 ‫Wechseln Sie nun zu Compass, um dieses Datum zu ändern. 636 00:31:20,030 --> 00:31:22,853 ‫Okay. 637 00:31:24,511 --> 00:31:26,010 ‫Sagen wir einen Monat später. 638 00:31:26,010 --> 00:31:27,657 ‫Und das wird tatsächlich in Zukunft 639 00:31:27,657 --> 00:31:30,780 ‫so sein, also zumindest in meiner Zukunft, wenn ich dieses Video aufnehme. 640 00:31:30,780 --> 00:31:34,150 ‫Natürlich werden Sie dies zu einem späteren Zeitpunkt tun. 641 00:31:34,150 --> 00:31:36,640 ‫Um dies zu testen, legen Sie dies bitte in Ihre Zukunft. 642 00:31:36,640 --> 00:31:40,373 ‫Also in der Zukunft des Datums, an dem Sie 643 00:31:41,420 --> 00:31:43,060 ‫dieses Video ansehen. 644 00:31:43,060 --> 00:31:44,710 ‫Also wenn ich jetzt 645 00:31:45,960 --> 00:31:50,960 ‫zurück zu Postman gehe und mich wieder einlogge, okay, also wenn ich mich jetzt 646 00:31:53,860 --> 00:31:56,430 ‫wieder einlogge und versuche, auf diese Route 647 00:31:56,430 --> 00:31:58,710 ‫zuzugreifen, nun, dann wird dieser Token 648 00:31:58,710 --> 00:32:01,420 ‫im Grunde nach der Änderung des Passworts ausgestellt. 649 00:32:01,420 --> 00:32:03,553 ‫Oder tatsächlich bevor das Passwort geändert wurde. 650 00:32:08,680 --> 00:32:10,590 ‫Also sorry für diese Verwirrung. 651 00:32:10,590 --> 00:32:12,610 ‫Das Passwort wurde also am 30. Mai 652 00:32:12,610 --> 00:32:15,800 ‫geändert, aber dieses Token wurde am 2. Mai ausgestellt und so zuvor. 653 00:32:15,800 --> 00:32:19,650 ‫Im Grunde ist es jetzt so, als ob der Benutzer sein Passwort 654 00:32:19,650 --> 00:32:21,950 ‫nach der Ausgabe des Tokens geändert hätte. 655 00:32:21,950 --> 00:32:25,880 ‫Und genau das ist die Situation, in der wir den Zugang zum geschützten 656 00:32:25,880 --> 00:32:27,341 ‫Weg nicht gewähren wollen. 657 00:32:27,341 --> 00:32:31,070 ‫Und so sollte dies nun auch das widerspiegeln. 658 00:32:31,070 --> 00:32:35,170 ‫Und tatsächlich, der Benutzer hat kürzlich das Passwort geändert, 659 00:32:35,170 --> 00:32:38,740 ‫bitte melden Sie sich erneut an. 660 00:32:38,740 --> 00:32:40,280 ‫Toll. 661 00:32:40,280 --> 00:32:41,240 ‫Also das funktioniert jetzt. 662 00:32:41,240 --> 00:32:42,953 ‫Damit ist unsere Protect Middleware nun vollständig implementiert. 663 00:32:43,870 --> 00:32:48,000 ‫Lassen Sie uns diese Konsole einfach loswerden. hier einloggen. 664 00:32:48,000 --> 00:32:51,620 ‫Brauche das nicht mehr. 665 00:32:51,620 --> 00:32:53,820 ‫Und okay. 666 00:32:53,820 --> 00:32:55,800 ‫Fassen wir also kurz zusammen, und 667 00:32:55,800 --> 00:32:57,230 ‫dieses Video dauert sehr 668 00:32:57,230 --> 00:32:59,520 ‫lange, etwas länger als ich erwartet hatte. 669 00:32:59,520 --> 00:33:01,330 ‫Aber es ist wirklich 670 00:33:01,330 --> 00:33:03,820 ‫wichtig zu verstehen und zu erklären, wie 671 00:33:03,820 --> 00:33:06,700 ‫das alles funktioniert und warum es wichtig ist. 672 00:33:06,700 --> 00:33:07,810 ‫Und deshalb bevorzuge ich das, als dieses Video viel kürzer zu machen. 673 00:33:07,810 --> 00:33:12,710 ‫Natürlich könnte ich einfach den Code schreiben, aber dann würdest du nicht wirklich verstehen, 674 00:33:12,710 --> 00:33:14,127 ‫was los ist. 675 00:33:14,127 --> 00:33:17,330 ‫Diesen Teil haben wir also bereits verstanden. 676 00:33:17,330 --> 00:33:19,410 ‫Dann, glaube ich, auch dieser Teil, 677 00:33:19,410 --> 00:33:21,680 ‫hier findet also die Verifizierung statt, also 678 00:33:21,680 --> 00:33:24,060 ‫im Grunde genommen, um zu sehen, ob die 679 00:33:24,060 --> 00:33:26,570 ‫Token-Nutzlast nicht von einem böswilligen Dritten manipuliert wurde. 680 00:33:26,570 --> 00:33:30,900 ‫Okay? 681 00:33:30,900 --> 00:33:31,733 ‫Und da wir 682 00:33:31,733 --> 00:33:33,730 ‫diesen Code dann hier erreichen, bedeutet dies, dass 683 00:33:33,730 --> 00:33:36,790 ‫niemand den JSON-Webtoken geändert hat und wir daher einen neuen Benutzer bekommen können. 684 00:33:36,790 --> 00:33:39,350 ‫Im Grunde können wir also den aktuellen Benutzer 685 00:33:39,350 --> 00:33:41,690 ‫abrufen, nennen wir ihn eigentlich currentUser. 686 00:33:41,690 --> 00:33:43,650 ‫Warum nicht? 687 00:33:43,650 --> 00:33:44,483 ‫Also hier, hier und auch hier. 688 00:33:45,450 --> 00:33:47,993 ‫Okay? 689 00:33:49,670 --> 00:33:50,503 ‫So können wir 690 00:33:50,503 --> 00:33:53,020 ‫den aktuellenBenutzer von dieser ID abrufen, die gerade aus der Nutzlast entschlüsselt wurde. 691 00:33:53,020 --> 00:33:55,023 ‫Wenn der currentUser nicht vorhanden 692 00:33:56,100 --> 00:33:58,260 ‫ist, testen wir hier darauf, nun, 693 00:33:58,260 --> 00:34:00,660 ‫in diesem Fall möchten wir keinen Zugriff 694 00:34:00,660 --> 00:34:01,990 ‫auf die Route 695 00:34:01,990 --> 00:34:04,290 ‫gewähren und stattdessen diesen neuen Fehler erstellen. 696 00:34:04,290 --> 00:34:06,343 ‫Aber wenn der Benutzer existiert, gut, 697 00:34:07,400 --> 00:34:08,870 ‫dann schaffen wir es 698 00:34:08,870 --> 00:34:12,030 ‫zu Punkt Nummer vier, wo wir dann überprüfen, ob nach 699 00:34:12,030 --> 00:34:15,060 ‫der Ausgabe des Tokens eine Passwortänderung stattgefunden hat, oder? 700 00:34:15,060 --> 00:34:18,060 ‫Und wenn dies der Fall ist, erstellen wir erneut einen neuen Fehler. 701 00:34:18,060 --> 00:34:21,200 ‫Und wenn nicht, gut, dann schaffen wir es 702 00:34:21,200 --> 00:34:22,720 ‫bis zum Ende 703 00:34:22,720 --> 00:34:24,460 ‫der Middleware-Funktion, wo wir 704 00:34:24,460 --> 00:34:26,750 ‫dann den currentUser zum Request zuweisen. user, damit wir es dann in 705 00:34:26,750 --> 00:34:30,640 ‫einer nächsten Middleware-Funktion verwenden können. 706 00:34:30,640 --> 00:34:33,860 ‫Okay? 707 00:34:33,860 --> 00:34:34,693 ‫Denken Sie 708 00:34:34,693 --> 00:34:37,030 ‫daran, dass dieses Anforderungsobjekt im Grunde 709 00:34:37,030 --> 00:34:38,950 ‫von Middleware zu Middleware wandert. 710 00:34:38,950 --> 00:34:40,660 ‫Wenn wir also Daten von einer 711 00:34:40,660 --> 00:34:42,330 ‫Middleware zur nächsten weitergeben 712 00:34:42,330 --> 00:34:44,600 ‫möchten, können wir einfach etwas auf das Anforderungsobjekt 713 00:34:44,600 --> 00:34:47,860 ‫legen, und diese Daten stehen zu einem späteren Zeitpunkt zur Verfügung. 714 00:34:47,860 --> 00:34:51,220 ‫Gut. 715 00:34:51,220 --> 00:34:52,053 ‫So, das wars. 716 00:34:52,053 --> 00:34:52,886 ‫Dies ist 717 00:34:52,886 --> 00:34:54,560 ‫im Grunde ein sehr ausgeklügelter und 718 00:34:54,560 --> 00:34:58,300 ‫sehr vollständiger Routenschutzalgorithmus, aber ich denke, es ist wirklich wichtig, ihn so gut 719 00:34:58,300 --> 00:34:59,740 ‫wie möglich zu machen. 720 00:34:59,740 --> 00:35:02,820 ‫Wie auch immer, ich freue mich zu sehen, dass du es 721 00:35:02,820 --> 00:35:04,990 ‫bis zum Ende dieses großen Videos geschafft hast, 722 00:35:04,990 --> 00:35:07,050 ‫und wir sehen uns im nächsten.