[MUSIC]
Wir hatten bereits einen vollwertigen REST-API-Server mit Express und
MongoDB im Rahmen dieses Kurses entwickelt.
Damit der Server sinnvoll mit unserem Kunden kommunizieren kann,
werden wir einige kleinere Anpassungen vornehmen, damit er die richtige Art von Daten zurückgibt.
Damit unsere Client-Implementierung effizienter
mit den Daten arbeiten kann, die von unserer Serverseite zurückgegeben werden.
Um dies zu tun,
lassen Sie uns in dieser Übung an ein paar Anpassungen auf unserer Serverseite arbeiten.
Gehen Sie zu unserem Server im Editor, bevor wir mit der Arbeit auf dem Server beginnen,
würde ich vorschlagen, dass Sie alle Bilder herunterladen, die ich
als ZIP-Datei in den Übungsressourcen namens images.zip bereitgestellt habe.
Entpacken Sie die Datei und erhalten Sie dann alle Bilder von dort, und
kopieren Sie diese Bilder in den Ordner für öffentliche Bilder auf unserem Server.
So sehen Sie, dass ich
hier bereits alle Bilder in meinen Public Images Ordner kopiert habe.
Weil unser Server derjenige ist, der all diese Bilder für
unsere Client-Anwendung bereitstellen wird.
Als nächstes gehen wir zu den Cors und passen diese Whitelist an, hier.
Also für unsere Angular-Client-Anwendung, wenn wir es
mit dem Befehl ng serve starten, läuft es bei localhost: 4200.
Alle Anfragen, die von unserer
Angular-Anwendung an den Server kommen, tragen das als Ursprung dort.
Deshalb werde ich das in meine Whitelist hinzufügen, so
dass alle Probleme mit Cors automatisch behoben werden.
Also gehen Sie in diese cors.js Datei,
in meiner Whitelist, hier, lassen Sie mich in
der http://localhost:, 4200 hinzufügen.
Und das ist der Ursprung, von dem mein ganzer Angular-Client
die Anfrage stammt, die an diesen Server kommt.
Auf diese Weise werden meine Cors keine Probleme für den Angular Client verursachen.
Als nächstes müssen wir einige der Routen aktualisieren, um
die Abfrageparameter zu behandeln, und auch ein paar kleinere andere Anpassungen.
Lassen Sie mich mit den promoRouter.js Dateien beginnen.
Das ist also einfach aktualisiert zu werden.
Also gehe ich zur Datei promoRouter.js, in der promOuter Datei, für
die get Anfrage, die wir hier bekommen,
anstatt promotions.Find mit einem leeren JavaScript
zu tun, hier würde ich die req.query als Parameter für diese promotions.Finden Sie hier.
Das Gleiche mit dem LeaderRouter auch, also lass mich zur Datei leaderRouter.js gehen.
Und im LeaderRouter auch
hier, wo Sie Leaders.Find mit dem leeren JavaScript-Objekt finden.
Ersetzen Sie diese stattdessen durch diese req.query, so
dass die Abfrageparameter übergeben werden.
Dies ist also, wo wir in der Featured Spalte
durch als Abfrageparameter übergeben werden.
Nachdem wir diese beiden angepasst haben, lassen Sie uns nun an der Dish Route arbeiten,
also gehen Sie zur Datei dishRouter.js, sogar im DishRouter, das gleiche Update hier.
Also gehen Sie zu diesem Gerichte.Finden Sie in der get-Methode hier, ändern Sie das zu req.query.
Damit wurde mein DishRouter-Update abgeschlossen.
So haben wir nun den Promorouter, den ReaderRouter und
den DishRouter aktualisiert, dann werden wir fortfahren, um diesen FavoriterOuter zu aktualisieren.
Jetzt hätten Sie den bevorzugten Router als Teil Ihrer
vierten Aufgabe implementiert.
Jetzt im FavoritErouter werden Sie sehen, dass
ich Ihnen für den FavoritErouter nicht den verbleibenden Parter zeige, weil
Sie das als Teil Ihrer Zuweisung hätten tun sollen.
Lassen Sie mich zuerst Ihre Aufmerksamkeit auf die get-Methode für
die FavoritRouter.route („/:dishid') lenken.
Jetzt werde ich diese Get-Methode verwenden,
um sicherzustellen, dass das spezifische Gericht mit
einer DishiD bereits ein Favorit für den Benutzer ist.
Anstatt also einfach die GET-Operation nicht unterstützt
zu sagen, werde ich nur das Vorhandensein dieser Get-Operation nutzen.
Und dann werden wir sagen,
Favorites.Findone.
Und ich werde sagen,
Benutzer: req.user.id.
So finden wir die Favoriten für diesen bestimmten Benutzer.
Und dann werden wir sagen,. Dann, Favoriten.
Und, fangen ((err),
next (err)).
Und dann ähnlich hier werden wir den Fehler hier hinzufügen.
Weiter (äh)), hier.
Also in diesem. dann, wenn wir die Favoriten bekommen,
dann werden wir überprüfen, ob (! Favoriten).
Also, wenn es für diesen Benutzer keine Favoriten gibt,
dann gibt es offensichtlich das Gericht, nach dem wir suchen, nicht.
Also werden wir zurückkehren, Res.StatusCode, 200.
setHeader ('Content-Type
'' 'Anwendung/json').
Und dann werden wir zurückkehren,
Sprichwort, „existiert“: falsch.
Was wir hier angeben, ist, dass, wenn das Get
zu diesem Endpunkt mit einer DishID gemacht wird, dieses Existes-Flag hier
auf true gesetzt wird, wenn dieses Gericht Teil meiner Favoriten ist.
Wenn dieses Gericht nicht Teil meiner Favoriten ist, setze ich das Existes-Flag auf false.
Also hier sehen Sie, dass da ich keine Favoriten habe, also
existieren sollte automatisch falsch an dieser Stelle sein.
Also sagen wir „existiert“: false, und dann werden wir die Favoriten hier zurückgeben.
Nun, offensichtlich
wären die Favoriten in diesem Fall an dieser Stelle null, sonst.
Was bedeutet, dass Favoriten nicht null sind, also sagen wir, wenn,
(favorites.dishs.indexOf),
also werden wir nach req.params suchen.
Dishid, also werden wir das durchsuchen.
Favorites.Dishes.array, um zu sehen, ob Gericht dort existiert.
Und wenn es nicht existiert, wird dies hier natürlich einen negativen Index zurückgeben.
Also in diesem Fall werde ich auch genau das gleiche wie hier zurückgeben.
Wenn es also einen negativen Index zurückgibt,
dann bedeutet das, dass, obwohl dieser bestimmte Benutzer einen Mittelfavorit hat.
Dieses spezifische Gericht gibt es nicht in der Liste sein oder
ihr Favorit, also ist es, warum es gibt hier falsch zurück.
Nun, sonst bedeutet das, dass das Gericht in der Liste der Favoriten existieren.
Also in diesem Fall werde ich Statuscode zurückgeben 200 existiert ist wahr.
Auf diese Weise, wenn der Benutzer eine get Operation an
diesem Endpunkt mit der /favorite/dishid ausführt.
Wo die disHID als Parameter hier angegeben wird.
Als Records Parameter hier,
dann werden wir überprüfen, ob dieses Gericht in den Favoriten existiert.
Wenn keiner der Favoriten für diesen Benutzer vorhanden ist, geben wir eine existierende false zurück.
In ähnlicher Weise, wenn die Favoriten vorhanden sind,
aber dieses bestimmte Gericht nicht in den Favoriten existiert, wird es eine false zurückgeben.
Andernfalls wird es ein true zurückgeben.
Also diese existierende Flagge kann von meinem Client verwendet werden,
um zu überprüfen, ob dieses Gericht Teil der Liste der Lieblingsgerichte für diesen Benutzer ist oder nicht.
Schließlich werden wir die Datei users.js aktualisieren.
Jetzt in der Datei users.js müssen wir in
einem anderen Feld router.options hinzufügen, da
manchmal eine Post-Anfrage, wie Sie mit dem Login gesehen
haben, werden wir zuerst die Optionen senden, um zu überprüfen, vor allem mit Autos,
ob die Post-Anfrage erlaubt ist.
Deshalb überprüfen sie Autos, Autos mit Optionen hier und dann.
Wir werden einfach
eine Statusmeldung von 200 als Antwort darauf zurückgeben.
Also für jeden Endpunkt unter Benutzern, wenn wir
die Optionen erhalten haben, wird einfach einen Status zurückgeben 200 hier.
Jetzt die Login-Funktion, die wir früher implementiert hatten.
Wir haben hier einfach passport.authenticate ('local') gemacht und
dann überprüfen wir hier die restlichen Werte.
Jetzt gibt diese passport.authenticate ('local'), wenn der Benutzer nicht
authentifiziert wird, einfach eine Unautorisierte in der Antwortnachricht zurück.
Nun, das ist möglicherweise nicht sehr sinnvoll für
die Client-Seite, um diese Informationen anzuzeigen.
Deshalb werden wir diese Router-Post-Login-Methode
so verbessern, dass die Authentifizierung aussagekräftigere Informationen an diesem Teil zurückgibt.
Also, um das zu tun, werden wir nicht tun, dass der Pass
hier drin authentifiziert wird.
Stattdessen werden wir nehmen, also lassen Sie mich das von dort entfernen,
und dann werden Sie sehen, wie ich den Routerpost hier aktualisieren werde.
Also werden wir CarsWithOptions sehen.
Und dann werden wir die req, res und das nächste hier einschließen.
Und innerhalb der req, res, und
weiter hier, passport.authenticate,
Wir nennen dies mit „local'.
Nun, wenn wir dies mit lokalen aufrufen, wenn ein
Authentifizierungsfehler auftritt, kann die passport.authenticate gemacht werden, um den Fehlerwert zurückzugeben,
und es wird auch den Benutzer zurückgeben, wenn kein Fehler vorliegt.
Und es könnte Parameter namens info,
die zusätzliche Informationen enthält, die an den Benutzer zurückgegeben werden könnten.
Dieser Fehler wird zurückgegeben, wenn ein echter Fehler auftritt,
der in der möglichen Authentifizierung auftritt.
Wenn jedoch die Benutzerinformationen an passport.authenticate gesendet werden,
der Benutzer jedoch nicht existiert, wird dies nicht als Fehler gezählt.
Stattdessen wird es als Benutzer nicht existiert gezählt.
Und diese Information wird in dem Info-Objekt zurückgegeben, das hereinkommt.
Daher wird der Fehler zurückgegeben, wenn ein echter Fehler auftritt, der während
des Authentifizierungsprozesses auftritt.
Aber die Info, sie enthalten Informationen, wenn der Benutzer nicht existiert und daher
die passport.authenticate eine Nachricht zurückgibt, die besagt, dass der Benutzer nicht
existiert oder entweder der Benutzername falsch ist oder das Kennwort falsch ist.
Und so weiter, damit Informationen in der Info-Nachricht weitergegeben werden.
Nun werden wir sehen, wie das für uns nützlich ist, wenn wir uns ein
wenig später auf die Client-Seite schauen.
In dieser Situation
werden wir das wie folgt behandeln.
Und nicht nur, dass, wenn wir nennen diesen Pass authentifizieren,
wir müssen auch in einem übergeben (req, res,
next) wie diese drei Parameter-Streifen.
Das ist also die Struktur.
Wenn Sie Pass-Authentifizierung anrufen müssen,
erwarten Sie, dass es Ihnen Informationen wie diese als Rückrufmethode hier zurückgibt.
Also müssen Sie auch diese Req liefern, res nächstes gleich dort.
Nun, wenn das passiert.
Also werden wir sagen, wenn (äh).
Wenn also ein Fehler auftritt,
sagen wir return next (err) und lassen Sie sich dann den
Fehler-Handler unseres Express-Routers darum kümmern.
Jetzt werden wir andere Situationen betrachten.
Wenn (! Benutzer), also wenn wir diesen Punkt erreicht haben, bedeutet das, dass es
kein Fehler war, der aufgetreten ist, sondern vielleicht konnte der Benutzer nicht gefunden werden.
Wenn der Benutzer nicht gefunden wird, wird der Benutzer hier in diesem Fall auf null gesetzt.
Also, in dieser Situation, wenn der Benutzer nicht existiert,
müssen wir in der Lage sein, Informationen zurück an die Serverseite zu übergeben.
Was wir also tun werden, ist, dass wir diese Informationen in diesem Format übergeben werden,
also werde ich das hier ausschneiden, und
dann fügen Sie es hier ein und dann werden wir es bearbeiten.
Wenn der Benutzer null ist, dann werden wir einen StatusCode
von 401 zurücksenden, was nicht autorisiert bedeutet, und
dann senden wir Informationen Erfolg, false zurück.
Und dann geben wir das Token nicht zurück, wir geben die Statusmeldung zurück.
Also hier sagen wir Login, Erfolglos.
Und dann wird die dritte Information diese Information übergeben,
das Objekt, das wir hier als dritter Teil dieser
Antwortnachricht erhalten haben, die wir von unserem Server hier zurücksenden.
Das Erfolgsflag wird also auf false zurückgesetzt.
Der Status wird Login fehlgeschlagen gesetzt und die Fehlerinformationen,
die in der Info übergeben werden, werden zurückgegeben.
Beachten Sie nun, dass diese Situation auftritt, wenn entweder der Benutzername und
das Passwort falsch sind.
Und so ist dies kein Fehler, im Fehlersinn, aber die Tatsache, dass die Authentifizierung
weder den Benutzer noch das Passwort des Benutzers finden konnte, ist falsch.
So werden die Informationen in den Zufluss codiert, der hereinkommt, und
damit ich als Fehler an meine Client-Seite weitergebe.
Andernfalls wird Teil
als Req.login behandelt.
Wenn dies also erfolgreich ist, fügt
die passport.authenticate dem Benutzer diese Methode namens Req.login hinzu.
Also an dieser Stelle werden wir nur das Benutzerobjekt übergeben, das wir erhalten haben.
Also, hier, wenn wir diesen Punkt erreicht haben,
dann bedeutet das, dass das Benutzerobjekt nicht null ist und
auch kein Fehler aufgetreten ist, so dass
der Benutzer eingeloggt werden kann und so sagen wir irr.
So wird es versuchen, den Benutzer anzumelden.
Also werden wir sagen, wenn irrtümlich.
Und dann werden wir die gleiche Art von Fehlerinformationen zurückgeben, die wir hier gemacht haben.
Also in diesem Fall, wenn der Fehler.
Wenn Fehler, dann werden wir den Statuscode 401 zurückgeben und
wir sagen, dass Erfolg falsch ist und der Status Login fehlgeschlagen ist.
Und dann die Fehlerinformationen, die
wir übergeben werden, da anstelle von
Informationen, die wir übergeben werden, konnte sich nicht in Benutzer anmelden.
Das ist also die Nachricht, die hier zurückgegeben wird, wenn der Fehler auftritt.
Sonst wären wir hier unten.
Und so würden wir an dieser Stelle in der Lage sein, das Token zu generieren.
Also, wenn wir bis zu diesem Punkt erreicht haben, bedeutet das, dass der Benutzer sich
erfolgreich angemeldet hat und so können wir jetzt das Token generieren.
Also werden wir das Token basierend auf der Benutzer-ID generieren und
dann werden wir dieses Token an den Benutzer zurückgeben.
Also hier werden wir var Token sagen.
Und dann können wir res.StatusCode = 200 sagen, und dann res.json (Erfolg) ist wahr,
was bedeutet, dass der Benutzer erfolgreich angemeldet ist.
Und so wäre der Status Login Erfolgreich, und
dann der dritte Teil anstelle des Fehlers werde ich das Token zurück an den Benutzer übergeben.
Also sagen wir Token, Token,
dieses Token, das wir gerade früher erhalten haben, so dass to-Token
als Token-Eigenschaft der rip light Nachricht übergeben wird.
Beachten Sie hier, dass diese Achse auf true gesetzt ist.
Das bedeutet, dass sich der Benutzer erfolgreich angemeldet hat.
Und so kann der Benutzer an dieser Stelle vorwärts gehen.
Und das muss innerhalb der Req.login hier getan werden.
Also an dieser Stelle werden wir die Req.login schließen.
Beachten Sie also, dass dies in diesem Req.login hier ist.
Also da drinnen werden wir diese drei zurückgeben.
Also lassen Sie mich einfach drei Zeilen einrücken.
Und so würden wir mit der Benutzeranmeldung umgehen.
Also nochmals, diesen Code noch einmal zu überprüfen.
Also werden wir Router-Post tun, aber
statt Pass authentifizieren genau dort, werden wir sagen, req, res,
nächste und dann innen hier werden wir einen Pass zu tun.authenticate für die lokale.
Und diese Authentifizierung wird zurückübergeben, so dass wir eine Callback-Funktion liefern können.
Und diese Callback-Funktion gibt entweder den Fehler, den Benutzer oder
die Info hier zurück.
Und wenn es einen Fehler verursacht, erlauben wir dem Express-Fehler-Handler,
sich darum zu kümmern.
Wenn der Benutzer null ist, bedeutet dies, dass die Benutzeranmeldung fehlgeschlagen war,
und der Grund dafür wird in der Info sein, so dass es als
Infofehler in der Planmeldung hier zurückgegeben wird.
Wenn wir zu diesem Punkt kommen, dann wird der Benutzer erfolgreich verifiziert.
Also dann werden wir den Benutzer einloggen.
So wird die passport.authenticate in dieser Methode namens Login zur
Anforderungsnachricht hinzufügen, so dass wir die Anmeldung mit dem Benutzer aufrufen können und
wenn dies einen Fehler zurückgibt, dann werden wir den Fehler hier entsprechend zurückgeben.
Wenn nicht, hätten wir den Punkt erreicht, an dem der Benutzer erfolgreich
authentifiziert wurde, damit er das JSON-Web-Token hier generieren und das
JSON-Web-Token an den Benutzer zurückgeben kann, um zu bestätigen, dass der Benutzer erfolgreich angemeldet ist.
Das ist also die Reihe von Schritten, die wir hier verwenden werden.
Jetzt ist der Grund, warum ich eine aufwändigere Art und Weise mache, dass ich
zwischen der Situation unterscheiden möchte, in der ein echter Fehler während
des Anwendungsprozesses auftritt, im Gegensatz zu der Situation, in der der Benutzername ungültig ist
oder das Passwort ungültig ist.
Diese beiden Fälle werden also von dieser Situation behandelt, in der
die Informationen zu uns zurückführen werden.
Das ist also kein Fehler, aber das ist eine Situation, in
der der Benutzer kein gültiger Benutzer ist oder das Passwort des Benutzers ungültig ist.
So werden sie mit dem Anmeldeprozess des Benutzers umgehen.
Darüber hinaus werde ich hier eine weitere Methode namens
checkJWToken hinzufügen.
Es ist durchaus möglich, dass, während der Client sich angemeldet und
das JSON-Web-Token erhalten hat, irgendwann später das JSON-Web-Token ablaufen kann.
Und wenn der Benutzer versucht, von der Clientseite mit einem abgelaufenen Token
auf den Server zuzugreifen, kann der Server den Benutzer nicht authentifizieren.
In regelmäßigen Abständen möchten wir daher möglicherweise eine Kreuzprüfung durchführen, um sicherzustellen, dass das
JSON-Web-Token immer noch gültig ist.
Das ist der Grund, warum ich einen anderen Endpunkt namens
checkJWTToken einschließe, also wenn Sie einen get to checkJWTToken machen.
Indem Sie das Token in den Autorisierungsheader
aufnehmen, gibt dieser Aufruf einen true oder false zurück, um Ihnen anzuzeigen,
ob das JSON-Web-Token noch gültig ist oder nicht.
Wenn es ungültig ist, kann die Clientseite bei
Bedarf eine weitere Anmeldung für den Benutzer initiieren, um ein neues JSON-Web-Token zu erhalten.
Um dies zu tun, sagen wir cors, corsWithOptions und,
req, res, hier, wie erwartet.
Und hier werden wir sagen,
passport.authenticate ('jwt',
Und, {session: false}).
Und das würde irr, user, info zurückgeben.
Also erinnern Sie sich, wie wir den Passport-Authentifikator früher verwendet haben.
Also fällt die JWT-Sitzung hier.
Also früher hier sagen wir, passport.authentifizieren lokale.
Dies ist also für die lokale Authentifizierung.
Dies ist also für die JSON-Web-Token-Authentifizierung.
Also, wenn wir das aufrufen, da dies das JSON-Web-Token überprüfen wird,
also werde ich sagen, wenn (err), als nächstes zurückgeben (err).
Und dann lassen Sie sich der Express-Fehlerbehandler um diese Situation kümmern.
Und dann werden wir sagen, wenn (! Benutzer),
Wenn der Benutzer nicht existiert, dann ähnlich, sonst.
Was bedeutet, dass, wenn das Benutzerobjekt aus dem JSON-Web-Token gefunden und
dann auf den req.user geladen wurde, bedeutet das, dass der Benutzer ein gültiger Benutzer ist.
Und so kann erlaubt werden, vorwärts zu gehen.
Andernfalls werden wir sagen, dass der Benutzer nicht existiert.
Wir müssen also folgern, dass das JSON-Web-Token abgelaufen ist.
Also an diesem Punkt senden wir ein res mit dem Statuscode von,
401, also nicht autorisiert.
setHeader (, 'Content-Type',
'application/json').
Und dann werden wir res,
.json zurückgeben, wir sagen, {status:,
'JWT ungültig! '.
Und dann werden Wir eine Flagge namens Erfolg zurückgeben: false.
Und dann, Wir werden die Informationen zurückgeben,
die wir erhalten, wenn der Benutzer nicht als Fehler an dieser Stelle authentifiziert.
Andernfalls bedeutet das, dass wir diesen Punkt erreichen, wenn der Benutzer ein gültiger Benutzer ist.
Also lassen Sie mich in diesem Fall einfach diesen Code hier kopieren,
wir werden einen Statuscode von 200 senden, und
dann wird der res.json JWT senden,
gültig! , und Erfolg wird wahr sein.
Und im dritten Teil werden wir die Informationen des Benutzers senden.
Wenn dieser Endpunkt
mit der get-Methode aufgerufen wird, überprüft dies, ob das Token gültig ist oder nicht.
Wenn das Token gültig ist, erhalten Sie diese Antwort.
Und aus dem Erfolgsflag in der Antwort
können Sie überprüfen, ob das JSON-Web-Token gültig ist oder nicht.
Und das ist auf der Client-Seite nützlich.
Nun
muss dieser Pass hier, passport.authenticate hier, mit req und res als die beiden Parameter hier geliefert werden.
So nennen wir diesen passport.authenticate.
Beachten Sie, dass, wenn Sie passport.authenticate aufrufen und
diese Callback-Funktion hier erwarten, Sie diesen Punkt, req,
.res, an diesen passport.authenticate und dann wieder hier anhängen müssen.
Damit haben wir alles auf der Serverseite aktualisiert.
Lassen Sie uns also alle Änderungen auf der Serverseite speichern.
Jetzt ist unser Server bereit,
die eingehenden Anfragen von unserem Angular-Client zu bearbeiten.
Damit schließen wir diese Übung ab.
In dieser Übung haben wir nun unseren Express-Server vorbereitet, um
eingehende Anfragen von unserem Angular-Client zu bearbeiten.
In der nächsten Übung werden wir uns den Angular-Client genauer ansehen, um zu
verstehen, wie er mit diesem zusätzlichen Server kommuniziert.
Dies ist ein guter Zeitpunkt für Sie, ein Git-Commit mit der Nachricht zu machen, indem Sie
Client und Server integrieren.
( MUSIK)