‫Jonas: In
‫diesem Vortrag implementieren wir also die
‫Funktionalität des Einloggens von Benutzern basierend auf einem gegebenen Passwort
‫und einer gegebenen E-Mail-Adresse.
‫Und genau wie zuvor bedeutet das Konzept des Anmeldens
‫eines Benutzers im Wesentlichen, einen JSON-Webtoken zu signieren
‫und an den Client zurückzusenden.
‫Aber in diesem Fall stellen wir das Token
‫nur dann aus, wenn der Benutzer tatsächlich
‫existiert und das Passwort korrekt ist.
‫Beginnen wir also mit der Umsetzung.
‫Exporte. Login ist...
‫anfordern, antwortet und weiter.
‫Und das erste ist, dass wir die
‫E-Mail und das Passwort tatsächlich aus dem Text lesen.
‫Nehmen wir an, const email ist gleich req. Karosserie. Email.
‫Okay, und jetzt gibt uns eslint diese Warnung oder
‫eigentlich diesen Fehler und sagt,
‫dass wir die Objektdestrukturierung verwenden sollten, okay?
‫Und so habe ich dies hier absichtlich
‫geschehen lassen, nur damit ich Ihnen zeigen kann, wie
‫wir es mit ES6-Destrukturierung machen können.
‫Und ich glaube, darüber habe ich im Kurs schon einmal
‫gesprochen, und ich hoffe auch, dass Sie
‫mit dem Konzept bereits vertraut sind,
‫aber trotzdem, da der Name
‫dieser Eigenschaft hier der gleiche ist wie
‫der Variablenname, können wir es einfach
‫so machen das und den Namen der Eigenschaft hier loswerden, okay?
‫Und auch wir wollen das Passwort bekommen.
‫Und damit wäre das gleich, also
‫entspricht das Passwort im Grunde einer Anfrage. Karosserie. Passwort.
‫Und
‫stattdessen können wir einfach E-Mail und Passwort eingeben.
‫Und so erstellen wir
‫im Grunde diese beiden Variablen des Körperobjekts, okay?
‫Im Grunde sendet der
‫Benutzer also die Anmeldedaten zur Überprüfung durch uns ein.
‫Okay, und dieser Prüfprozess besteht aus ein paar Schritten. Lassen Sie
‫uns sie also hier darstellen,
‫bevor wir mit dem Codieren beginnen.
‫Zuerst müssen wir also prüfen,
‫ob E-Mail und Passwörter tatsächlich existieren, in Ordnung?
‫Dann Nummer zwei, prüfen Sie, ob der Benutzer
‫existiert und gleichzeitig das Passwort korrekt ist.
‫Und dann drittens, wenn alles
‫in Ordnung ist, senden Sie das Token, also das JSON-Webtoken, zurück an den Client.
‫Okay, der erste ist also ganz einfach.
‫Wenn also keine E-Mail oder kein Passwort vorhanden ist, möchten
‫wir unserem Kunden eine Fehlermeldung senden.
‫Wie sollen wir das jetzt machen?
‫Nun, wir werden das mit den
‫Tools machen, die wir gleich im letzten Abschnitt implementiert haben.
‫Also im Grunde unser App-Fehler, erinnerst du dich daran?
‫Wir werden hier also einfach einen neuen
‫Fehler erstellen, und unsere globale
‫Middleware zur Fehlerbehandlung wird ihn dann aufnehmen und an den Client zurücksenden.
‫Beginnen wir also mit dem Importieren dieses Fehlers.
‫Denken Sie also daran,
‫dass es dieser hier aus unserer AppError-Klasse ist, richtig?
‫Sagen wir also AppError und dann require.
‫Also eine Ebene höher von hier, dann in den Dienstprogrammen und
‫dann appError.
‫Okay, also müssen wir die nächste Middleware aufrufen,
‫und dann übergeben wir hier den Fehler, erinnern Sie sich daran?
‫Also neuer AppError, und
‫die Meldung lautet: Bitte E-Mail und Passwort angeben.
‫Und der HTTP-Fehlercode ist 400 für eine fehlerhafte Anfrage, okay?
‫Und jetzt habe ich
‫hier einige Fehler, und so hilft mir eslint wieder, einige Fehler zu beheben.
‫So sehe ich das
‫hier oben wieder, ich habe es mit einem T statt
‫D verwendet, und wenn ich es jetzt speichere, ist alles richtig.
‫Okay, also lasst uns gleich mit dem Testen beginnen.
‫Und dafür
‫werde ich hier erstmal einfach einen gefälschten Token erstellen, okay.
‫Sagen wir also res. Status 200 für ok.
‫JSON, und dann natürlich wie
‫immer der Status auf Erfolg gesetzt und dann auch noch unser Token.
‫Und das ist eigentlich alles, was
‫wir als Antwort auf die Anmeldung senden, okay?
‫Also kein Benutzerobjekt, weil das gar nicht nötig ist.
‫Alles, was wir als Antwort für die Anmeldung benötigen,
‫ist eigentlich das Token.
‫Das ist alles, was zählt, wenn sich der Benutzer anmeldet.
‫Als nächstes müssen wir die Route
‫implementieren, also machen wir das noch einmal in unserem Benutzerrouter, okay?
‫Und dieser ist diesem tatsächlich ziemlich ähnlich.
‫Lass es uns einfach duplizieren und dann
‫die Anmeldung in beiden Fällen hier durch die Anmeldung ersetzen, okay?
‫Und das gilt wiederum nur für eine
‫Postanfrage, denn natürlich wollen
‫wir die Zugangsdaten im Body mitschicken.
‫Es ist also wieder
‫ein Post, aber kein Get, kein Patch und kein Delete,
‫denn das macht in diesem Fall keinen Sinn.
‫Also lass es uns gleich testen.
‫Ich werde diese URL auch hier kopieren.
‫Es wird posten, einloggen und dann natürlich
‫der Text.
‫Also wieder Raw und JSON.
‫Lassen Sie uns hier also einen einfachen Körper erstellen.
‫Alles klar, also versuchen wir, dies
‫ohne Passwort zu senden und sehen, was passiert.
‫Und tatsächlich funktioniert es, daher erhalten wir hier unsere Nachricht:
‫Bitte geben Sie E-Mail und Passwort an.
‫Und wieder, da wir
‫noch in der Entwicklung sind, bekommen wir
‫hier den ganzen Fehlerstack und den kompletten Fehler mit
‫unserem Statuscode, den Status und natürlich auch, dass
‫es sich um einen Betriebsfehler handelt.
‫Also genau wie im vorherigen Abschnitt definiert, okay?
‫Jetzt versuchen wir das gleiche mit dem Passwort.
‫Also Passwort, setze es auf Ich glaube, das war das Richtige,
‫und dann lösche die E-Mail.
‫Und das löst natürlich das gleiche aus.
‫Okay, und mit allem korrekten sollte das dann funktionieren,
‫und tatsächlich bekommen wir hier unseren Fake-Token.
‫Jetzt sollten wir nur noch eines hier
‫tun, um auch zurückzukehren.
‫Das haben wir schon oft gemacht, und lassen
‫Sie es mich noch einmal erklären.
‫Es liegt einfach daran, dass wir nach dem
‫Aufruf der nächsten Middleware sicherstellen möchten,
‫dass diese Login-Funktion hier sofort beendet wird, in Ordnung?
‫Und da wir das vorher
‫nicht hatten, sehen Sie diesen Fehler jetzt hier wieder.
‫Das kommt mir jetzt schon irgendwie bekannt vor, oder?
‫Daher können keine Header gesetzt werden, nachdem sie an den Client
‫gesendet wurden, da wir wiederum zwei Antworten gesendet haben.
‫Erst die Fehlerantwort und dann auch dieser Code hier laufen, was
‫natürlich nicht hätte gehen sollen.
‫Und so verwenden wir hier wieder return, um das zu beheben.
‫Okay, als nächstes prüfen wir, ob es tatsächlich einen
‫Benutzer für die gepostete E-Mail gibt.
‫Also const user, und verwenden wir jetzt tatsächlich findOne, denn diesmal
‫wählen wir einen Benutzer nicht nach der ID
‫aus, sondern nach seiner E-Mail, oder?
‫Also müssen wir dieses Filterobjekt übergeben,
‫in dem wir sagen können, dass E-Mail gleich E-Mail ist, okay?
‫Das Feld heißt also
‫E-Mail und die Variable heißt auch E-Mail.
‫In ES6 können wir das einfach so abkürzen.
‫Bevor wir hier
‫weitermachen, muss ich noch
‫etwas Wichtiges für die Sicherheit tun.
‫Lassen Sie mich Ihnen das in Postman zeigen,
‫wo wir uns für ein neues Konto angemeldet haben.
‫Und Sie sehen hier, dass wir
‫in der Benutzerausgabe tatsächlich das Passwort erhalten, okay?
‫Es ist tatsächlich verschlüsselt,
‫aber es ist trotzdem keine gute Praxis,
‫die Passwortdaten an den Client weiterzugeben, okay?
‫Wenn wir zum Beispiel alle Benutzer hierher bekommen hätten
‫und diese Route noch nicht implementiert
‫ist, aber wenn wir alle Benutzer aus der Sammlung holen
‫würden, dann hätten alle das
‫Passwort sichtbar, und das wollen wir nicht , okay?
‫Und so ist es eigentlich ganz einfach, es zu reparieren,
‫weil wir es vorher gemacht haben.
‫Alles, was wir tun müssen, ist,
‫das Passwort zu sagen und es dann auszuwählen und auf false zu setzen.
‫Und so wird es automatisch in keiner
‫Ausgabe angezeigt.
‫Und damit ich Ihnen das
‫tatsächlich beweisen kann, indem ich mich als etwas anderes anmelde, also so.
‫Und mal sehen, oh, tatsächlich haben wir
‫bereits einen Benutzer mit dieser E-Mail, also machen wir einfach test3.
‫Und jetzt ist das Passwort eigentlich immer noch hier, aber ich
‫denke, das liegt einfach daran, dass wir es einfach erstellen
‫konnten, dieses neue
‫Dokument hier, und daher wird es nicht
‫wirklich ausgewählt, weil wir es nicht wirklich aus der Datenbank lesen.
‫Also lass uns
‫diese Route hier ganz schnell
‫tatsächlich umsetzen, das dauert nur eine Minute.
‫Also nur um zu sehen, ob das hier wirklich funktioniert.
‫Denn dieser Schritt ist eigentlich
‫wichtig für das, was wir als nächstes tun werden, okay?
‫Also lassen Sie uns diesen Code aus getAllTours kopieren
‫und nicht wirklich kopieren, aber was wir
‫tun werden, ist natürlich ziemlich ähnlich.
‫Also kopiere ich das
‫einfach, aber ohne die API-Funktionen.
‫Das interessiert mich also nicht wirklich, okay?
‫Und so werde ich
‫dieses hier tatsächlich im Benutzer-Controller tun, weil das Abrufen aller Benutzer
‫nichts mit der Authentifizierung zu tun hat.
‫In diesem Fall ist
‫die Benutzersteuerung also der perfekte Ort dafür.
‫Jetzt muss ich natürlich auch
‫noch schnell das Benutzermodell hier importieren, also
‫kopieren wir das auch vom tourController, der nicht gleich aber ähnlich ist.
‫Also lassen Sie uns all dies in
‫unseren Benutzer-Controller packen.
‫Diesen brauchen wir nicht, aber wir müssen auch catchAsync.
‫Okay, Tour wird also user
‫sein, und hier wird es userModel sein, in Ordnung?
‫Dann haben wir hier Touren und hier unten und hier
‫unten, also drücke ich Befehl + D, um
‫alle auszuwählen und in Benutzer zu ändern.
‫Und dann erwarten wir hier natürlich User. finden.
‫Da wir hier
‫ein Async haben, brauchen wir async, dann brauchen wir auch next, und da
‫wir hier ein Async
‫haben, sollten wir das Ganze dann in ein Catch-Async einpacken.
‫Also machen wir das.
‫Okay, und an dieser
‫Stelle ist das für dich nichts
‫Neues mehr, wir sind schon daran gewöhnt, solche Sachen zu machen, oder?
‫Das sollte zu diesem Zeitpunkt bereits funktionieren, also
‫probieren wir es aus.
‫Holen Sie sich also alle Benutzer, und jetzt sehen wir tatsächlich,
‫dass ihr Passwort nicht in der Ausgabe enthalten ist.
‫Und das ist wichtig, denn eigentlich wird im Find, also
‫zurück hier im AuthController,
‫dieser hier nun auch nicht das Passwort enthalten, okay?
‫Und so wird
‫die Ausgabe hier nun auch kein Passwort enthalten.
‫Aber wir brauchen das Passwort, um zu überprüfen,
‫ob es richtig ist, oder?
‫Also müssen wir es auch explizit auswählen.
‫Erinnern Sie sich also daran, wie wir zuvor select
‫verwendet haben, um im Grunde einfach ein paar
‫Felder aus der Datenbank auszuwählen, nur die, die wir brauchten?
‫Wenn wir in diesem Fall das
‫standardmäßig nicht ausgewählte Feld möchten, müssen wir
‫den Benutzer plus und dann den Namen des Felds eingeben.
‫Also Passwort in diesem Fall.
‫Und so wird es wieder in der Ausgabe erscheinen, okay?
‫Natürlich müssen wir diese Abfrage
‫abwarten und dann die Funktion als asynchron markieren.
‫Um diesen
‫hässlichen try-catch-Block zu vermeiden, wickeln Sie diese
‫gesamte Funktion wie zuvor in catchAsync ein.
‫Alles klar, macht Sinn?
‫Lassen Sie uns den Benutzer jetzt schnell an der Konsole anmelden, um zu
‫sehen, ob es funktioniert.
‫Also dieser hier.
‫Wir bekommen unseren Erfolg, und tatsächlich bekommen wir hier den Benutzer.
‫Also mit genau der E-Mail, die ich gerade gepostet
‫habe, und dann ist das Passwort jetzt auch wieder
‫in der Ausgabe enthalten, okay?
‫Das liegt wiederum daran, dass wir es hier explizit ausgewählt haben.
‫Jetzt ist es also an der Zeit, die Passwörter,
‫die wir in der Datenbank haben, mit dem Passwort
‫zu vergleichen, das der Benutzer gerade gepostet hat.
‫Aber wie sollen wir das machen?
‫Denn zum Beispiel könnte das Passwort
‫pass1234 lauten oder ist es in diesem Beispiel, aber
‫das, das wir im Dokument gespeichert haben, sieht so aus.
‫Wie sollen wir das vergleichen?
‫Es gibt nicht wirklich eine Möglichkeit, es zu tun, oder?
‫Aber eigentlich müssen
‫wir nur noch das bcrypt-Paket verwenden, okay?
‫Wir haben also bcrypt verwendet, um dieses gehashte Passwort zu generieren, und
‫wir können das gleiche Paket auch
‫verwenden, um ein Original-Passwort wie dieses hier im Grunde mit dem gehashten
‫Passwort zu vergleichen.
‫Natürlich dieses Passwort hier, da es verschlüsselt ist, gibt
‫es keine Möglichkeit, das alte, also
‫das ursprüngliche Passwort aus dieser Zeichenfolge zurückzubekommen, richtig?
‫Das ist also der
‫springende Punkt beim eigentlichen Verschlüsseln eines Passworts.
‫Die einzige Möglichkeit für
‫dieses Paket für diesen Algorithmus besteht
‫also darin, dieses Passwort auch tatsächlich zu verschlüsseln
‫und es dann mit dem verschlüsselten zu vergleichen, in Ordnung?
‫Lassen Sie uns also eine Funktion implementieren, die
‫das tut, und dafür verwenden wir wieder das bcrypt-Paket.
‫Und das werden wir im Benutzermodell tun.
‫Und Sie könnten sich fragen: "Warum machen wir
‫das in einem Modell" und nicht nur hier", aber
‫das liegt wiederum daran, dass dies wirklich mit den Daten selbst zusammenhängt.
‫Außerdem haben wir dieses Paket bereits drin, und so
‫ist es einfacher, es einfach dort zu machen.
‫Lassen Sie uns diese Zeichenfolge einfach loswerden
‫und erstellen Sie hier
‫eine Funktion, die überprüft, ob das
‫angegebene Passwort mit dem im Dokument gespeicherten übereinstimmt.
‫Also erstellen wir jetzt zum ersten
‫Mal eine sogenannte Instanzmethode.
‫Eine Instanzmethode ist also im Grunde eine Methode,
‫die für alle Dokumente einer bestimmten
‫Sammlung verfügbar sein wird, okay?
‫Und es funktioniert so.
‫Also noch einmal, es ist
‫in einem userSchema definiert, und dann sagen wir Methoden, und in diesem
‫Fall möchten wir jetzt die Funktion correctPassword aufrufen, in Ordnung?
‫Funktion, jetzt akzeptiert diese Funktion ein CandidatePassword,
‫also das Passwort,
‫das der Benutzer im Hauptteil
‫übergibt, und dann auch das userPassword, okay?
‫Da diese instanzierten Methoden
‫im Dokument verfügbar sind, verweist das
‫Schlüsselwort this nun tatsächlich auf das aktuelle Dokument.
‫Aber in diesem Fall haben
‫wir das Passwort auf false gesetzt, also das hier, erinnerst du dich?
‫Okay, und
‫deswegen das hier. Passwort wird nicht verfügbar sein.
‫Idealerweise würden wir es so machen, und
‫auf diese Weise
‫müssten wir nur das CandidatePassword und nicht das userPassword übergeben.
‫Aber auch das ist im Moment
‫nicht möglich, da das Passwort in der Ausgabe nicht verfügbar ist.
‫Und deshalb
‫müssen wir eigentlich auch userPassword eingeben.
‫Das Ziel dieser Funktion
‫besteht also darin, wirklich nur wahr oder falsch zurückzugeben.
‫Also grundsätzlich wahr, wenn die Passwörter gleich sind,
‫und falsch, wenn nicht.
‫Also kehren Sie zurück und dann bcrypt, was wir bereits
‫kennen, und dann werden wir die Vergleichsfunktion verwenden, okay?
‫Und die Vergleichsfunktion ist
‫wirklich einfach, wir müssen nur das
‫CandidatePassword und das userPassword übergeben, nicht userSchema, userPassword, okay?
‫Und genau wie die Hash-Funktion
‫hier oben ist auch diese eine asynchrone Funktion.
‫Und so wie zuvor verwenden wir await und dann hier async.
‫Okay, sinnvoll?
‫Auch hier gibt diese Vergleichsfunktion hier
‫ganz einfach true zurück,
‫wenn diese beiden Passwörter hier gleich sind, und false, wenn nicht.
‫Und wieder können wir sie
‫nicht manuell vergleichen, weil das Kandidatenpasswort nicht
‫gehasht ist, also das ursprüngliche Passwort
‫des Benutzers ist, aber userPassword ist
‫natürlich gehasht, und ohne diese Funktion
‫hier hätten wir keine Möglichkeit, sie zu vergleichen, okay?
‫Hier geben wir also true oder
‫false zurück, jetzt müssen wir diese Funktion nur
‫noch im authController aufrufen.
‫Lassen Sie uns ein paar davon schließen.
‫In Ordnung, das hier war also nur zur Demonstration hier.
‫Nennen wir dies hier einfach richtig und
‫denken Sie daran, dass die Funktion, die wir gerade definiert
‫haben, eine instanzierte Methode ist.
‫Daher ist es in allen Benutzerdokumenten verfügbar.
‫Und diese Variable hier ist jetzt
‫also ein Benutzerdokument, oder?
‫Weil es ein Ergebnis der Abfrage des Benutzermodells ist.
‫Und so können wir jetzt Benutzer sagen. richtigesPasswort.
‫Jetzt müssen wir nur noch das Kandidatenpasswort eingeben, das
‫Passwort ist, denken Sie daran.
‫Also dieses hier und dann das userPassword.
‫Und das ist im Benutzer. Passwort, in Ordnung?
‫Und so wird dies hier nun entweder wahr oder falsch sein.
‫In Ordnung, und jetzt verwenden wir diese beiden
‫Variablen, um herauszufinden, ob der Benutzer existiert und
‫das Passwort korrekt ist.
‫Das haben wir
‫bereits herausgefunden, aber jetzt müssen wir tatsächlich unsere if-Anweisung schreiben.
‫Wenn also kein Benutzer vorhanden ist oder das Passwort falsch ist,
‫ist im Grunde richtig falsch, was dies bedeutet.
‫In diesem Fall möchten wir erneut zurückkehren und
‫mit einem neuen AppError direkt zu unserer nächsten Middleware
‫gehen.
‫Und in diesem Fall sagen Sie falsche E-Mail oder Passwort, okay?
‫Und dann ist der Statuscode
‫401, was bedeutet, nicht autorisiert, in Ordnung?
‫Jetzt hätten wir dies separat tun
‫können, also zuerst nach dem
‫Benutzer und dann nach dem richtigen Passwort suchen.
‫Aber in diesem Fall würden wir dann einem potenziellen
‫Angreifer Auskunft darüber geben, ob die E-Mail oder das Passwort falsch ist.
‫Und hier ist es etwas vage.
‫Wir spezifizieren also nicht wirklich, was hier falsch ist.
‫Also, ob es sich um eine E-Mail oder um das Passwort handelt.
‫Wenn also ein
‫Angreifer versucht, zufällige Daten einzugeben, weiß
‫er nicht, ob die E-Mail tatsächlich existiert
‫oder ob nur das Passwort falsch ist, in Ordnung?
‫Jetzt nur zwei Dinge hier, und das erste
‫ist, dass wir tatsächlich auf
‫diese asynchrone Funktion warten müssen, okay?
‫Denken Sie also daran, dass das richtige
‫Passwort eine asynchrone Funktion
‫ist, und hier müssen wir auch darauf warten.
‫Und dann gibt es
‫noch ein anderes Problem, weil dieser Benutzer
‫hier nicht existiert, dann kann diese nächste Codezeile nicht wirklich laufen, okay?
‫Denn zum Beispiel Benutzer. Passwort wird
‫nicht verfügbar sein.
‫Also müssen wir das alles oder eigentlich nur
‫diesen Code verschieben,
‫wir werden ihn hier in die if else-Anweisung verschieben.
‫In Ordnung, und so, wenn der
‫Benutzer nicht existiert, also wenn dies wahr ist, wird dieser
‫Code hier nicht einmal ausgeführt, und dann
‫wird es kein Problem geben.
‫Aber wenn der Benutzer existiert, dann wird er auch diesen Code
‫ausführen und prüfen, ob das Passwort tatsächlich richtig ist.
‫Wenn also das Passwort
‫korrekt ist, erreichen wir nur in diesem Fall jemals diesen Code hier.
‫Das ist also die ganze Idee dieser Funktion.
‫Im Grunde prüfen wir also auf die Negative.
‫Wenn also keine E-Mail und kein Passwort vorhanden
‫sind, erhalten wir diesen Fehler.
‫Wenn kein Benutzer oder ein falsches Kennwort vorhanden
‫ist, erstellen Sie diesen Fehler.
‫Aber wenn überhaupt kein Fehler aufgetreten
‫ist, dann erreichen wir in diesem Fall diesen Teil des Codes,
‫wo wir nun ein
‫Token generieren und dann an den Benutzer zurücksenden.
‫Das Erstellen dieses Tokens wird jetzt genau das Gleiche sein, wie wir
‫es zuvor hier getan haben.
‫Anstatt also den ganzen Code
‫zu wiederholen, erstellen wir eine Funktion dafür, okay?
‫Also kopiere ich
‫diesen Code, und dann hier ganz schnell
‫const signToken, das als einzige Eingabe die Benutzer-ID erhält.
‫Also ID, und dann wird das Token zurückgegeben, okay?
‫Es wird dies einfach unterschreiben und sofort zurücksenden.
‫In Ordnung, und hier
‫werden wir Token signieren und diese ID übergeben.
‫Und dann müssen wir es natürlich auch hier ändern, okay?
‫Setzen Sie diese ID also auf diese
‫ID, die, wie Sie bereits wissen, mit dieser identisch ist.
‫In Ordnung, und so lasst uns jetzt weitermachen und dasselbe hier tun.
‫signToken, und in diesem Fall ist es user. _Ich würde.
‫Puh, das war ein langer
‫Vortrag, lasst es uns jetzt mal ausprobieren.
‫Also sollte es jetzt funktionieren.
‫Denken Sie also daran, dies ist jetzt ein anderer Benutzer, aber ich weiß, dass
‫dies das Passwort ist, das ich verwendet habe.
‫Also lassen Sie uns für jetzt einen anderen
‫verwenden, also testen wir einfach 12 und sehen wir, was passiert.
‫Warten wir ab, und tatsächlich falsche E-Mail oder Passwort.
‫Und so bekommen wir natürlich auch unsere
‫401, und tatsächlich heißt das, dass unser Code derzeit schon auf
‫das Passwort testet.
‫Wenn wir also jetzt das richtige Passwort wählen, dann sollte
‫es passieren, also warten wir es ab.
‫Aber wir erhalten immer noch diesen Fehler.
‫Also lassen Sie uns einfach alle unsere Benutzer hier loswerden, nur
‫um sicherzustellen, dass es nichts mit
‫den Benutzern zu tun hat, und dann erstellen wir einen neuen, in Ordnung.
‫Also hallo@jonas und pass1234.
‫Machen wir weiter und kopieren es, ich schicke es jetzt.
‫Und so sind diese Anmeldeinformationen jetzt mit Sicherheit korrekt.
‫Wenn es jetzt nicht funktioniert, liegt ein Fehler vor.
‫Aber jetzt hat es tatsächlich funktioniert, super.
‫Hier ist also unser Token, und es sieht genauso aus wie zuvor, sodass wir
‫davon ausgehen können, dass es korrekt ist.
‫Jetzt versuchen wir es noch einmal und löschen das, okay.
‫Also mit dem falschen Passwort geht es nicht.
‫Geben wir jetzt das Passwort richtig und die E-Mail falsch ein, und dann
‫erhalten wir den gleichen Fehler.
‫Also falsche E-Mail oder Passwort.
‫Und wieder, wenn wir alles zurücklegen, dann
‫bekommen wir ein neues Token.
‫Und so sind wir jetzt wirklich in die Anwendung eingeloggt.
‫Und ich weiß, dass dies irgendwie abstrakt aussehen
‫könnte, also bekommen wir nur ein Token, und das bedeutet dann, dass
‫wir bei der Anwendung angemeldet sind, richtig?
‫Aber gut, so funktioniert es bei der zustandslosen Authentifizierung.
‫Später, wenn wir die dynamische Website wirklich erstellen,
‫wird es natürlich viel besser sichtbar
‫sein, wenn der Benutzer entweder eingeloggt oder ausgeloggt ist, oder?
‫Aber es funktioniert immer noch hinter
‫den Kulissen mit demselben Token.
‫Wenn also kein Token vorhanden ist, sieht die Website in eine
‫Richtung aus, und wenn ein Token
‫vorhanden ist, sieht die Website in eine andere
‫Richtung aus, zum Beispiel mit dem Benutzerbild und dem Benutzernamen direkt auf der Website.
‫Jedenfalls war dies ein ziemlich langer Vortrag.
‫Stellen Sie sicher, dass Sie hierher zurückkehren und wirklich
‫versuchen, den gesamten Code, den wir hier haben, zu verstehen, in Ordnung?
‫Weil ich weiß, dass
‫einiges davon etwas verwirrend sein kann.
‫Zum Beispiel diese korrekte Passwort-Funktion hier.
‫Und dann wird für Sie sicher alles Sinn ergeben.