[MUSIC]
Nun, da wir die Notwendigkeit einer grundlegenden Authentifizierung in unserer
Express-Anwendung verstanden haben, fahren wir mit der Übung fort, in der wir dem
ConFusion-Server, den wir bisher entwickelt haben,
dem Express REST API-Server, die grundlegende Authentifizierung hinzufügen.
Wir werden auf dem Weg
lernen, wie wir die grundlegende Authentifizierung innerhalb unseres Servers verwenden können.
Und dann in den nachfolgenden Übungen werden wir diese Idee weiter erweitern,
um einen vollwertigen Authentifizierungsdienst für unseren Express REST API-Server hinzuzufügen.
In dieser Übung gehen wir zum ConFusion-Server,
woran wir bisher gearbeitet haben.
Sie müssen also die Umsetzung des zweiten Auftrags bereits abgeschlossen
haben, wo Sie die Promotions und das Leaders-Modell entwickelt hätten.
Außerdem wurden die Routen für den Leader Router und
den Promo-Router in Ihrer ConFusion Server-Anwendung aktualisiert.
In diesem Code gehen wir also zu app.js und
fügen Sie dann die grundlegende Authentifizierung in app.js hinzu.
Also in app.js, wie wir über die Art und Weise verstanden haben, wie
der mittlere Weg es in Express-Anwendung funktioniert.
Also beginnen wir hier in der app.js,
indem wir hier alle verschiedenen Knotenmodule importieren.
Und danach beginnen wir hier, indem wir zuerst app.use logger dev sagen.
All diese werden also auf unsere Anwendung angewendet werden.
Und dann ist dieser Aufruf hier app.use (express.static),
was es uns ermöglicht, statische Daten aus dem öffentlichen Ordner zu liefern.
Jetzt wollen sie die Authentifizierung durchführen, bevor wir
dem Client erlauben, Daten von unserem Server abzurufen.
Also genau dort werden wir hineingehen und ein Authentifizierungs-Badge hinzufügen.
So bemerken Sie, dass alles, was danach kommt,
all die Middleware, die montiert ist und nach diesem bestimmten Punkt kommt.
Wir müssen die Autorisierungsphase durchlaufen
, bevor diese Middleware Zugriff haben kann.
Also genau dort werde ich in app.use hinzufügen und
dann eine Funktion namens auth hinzufügen, die ich jetzt implementieren werde.
Also, indem wir dies tun, was wir angeben, ist die Standardeinstellung,
der Client kann auf alle dieser zugreifen,
entweder auf ihre statischen Ressourcen im Öffentlichen Ordner, oder
auf eine der Ressourcen, Gerichte, Aktionen, oder Führer oder sogar Benutzer, wie wir später sehen werden.
Der Kunde muss zuerst autorisiert werden.
Also, genau dort, werden wir in der Auth hinzufügen.
Also lassen Sie mich die Funktion hier auth direkt dort hinzufügen.
Und dann verwenden Sie es sofort innerhalb unserer
Express-Anwendung als Middleware dort.
Diese Funktion, auth wird also drei Parameter annehmen,
das Anforderungsobjekt, das Ressourcenobjekt und das nächste Objekt, ja.
Lassen Sie mich also innerhalb dieser Funktion
zuerst wissen, was im Anfrage-Header enthalten ist.
Lassen Sie mich einfach die Request-Header dort protokollieren, nur um Ihnen zu demonstrieren,
denn sobald Sie den Autorisierungs-Header hinzufügen,
möchten wir ihn direkt dort sehen können.
Also werden wir zuerst ein Konsolenprotokoll machen,
nur um zu sehen, was von der Client-Seite kommt.
Dann lassen Sie mich ihren
Autorisierungs-Header erhalten, indem Sie
req.headers .authorisierung sagen.
Hier bekommen wir den Autorisierungs-Header, der
von unserer Client-Seite hinzugefügt wird.
Wenn es nicht da ist, dann müssen wir natürlich entsprechend handeln.
Wenn also der AuthHeader null ist,
was bedeutet, dass es in unserer eingehenden
Anfrage keinen Authentifizierungsheader gibt, dann hat unser Client offensichtlich nicht den Benutzernamen und das
Passwort in den Authentifizierungsheader aufgenommen.
Daher müssen wir unseren Kunden herausfordern, diese Informationen zu liefern.
Also, wenn der Autorisierungs-Header null ist, dann werden wir sehen,
var irr neuen Fehler,
so dass wir nicht zulassen, dass unsere Client-Anfrage weiter über diesen Punkt hinaus geht.
Also werden wir sagen, Sie sind nicht authentifiziert,
und dann werden wir Kunden dort herausfordern.
Wir werden also res.setHeader sagen, also
werden wir den Header in der
Antwortnachricht setzen, die WWW-Authenticate sagt,
und aus der Vorlesung früher
werden Sie sehen, warum wir dies
in den Antwort-Header einfügen.
Und dann werden wir sagen, err status.401.
401 ist nicht autorisierter Zugriff.
Und dann werden wir einfach unseren Aufruf als nächstes mit dem Header generieren.
Das bedeutet, dass es all dies überspringt und zum Fehlerhandler wechselt,
wo der Fehlerbehandler die Antwortnachricht konstruiert und
dort an meinen Client zurücksendet.
Also, wenn der Client den Authentifizierungsheader oder
den Autorisierungs-Header nicht enthalten hat, werde ich den Client herausfordern,
ihn zu bitten, mir den Autorisierungs-Header dort bereitzustellen.
Wenn nicht, dann weiß ich, dass der Autorisierungs-Header existiert.
Über diesen Punkt hinaus werden wir var auth sagen,
und ich werde den Autorisierungs-Header extrahieren.
Und da der AuthHeader eine Zeichenfolge ist,
werde ich diesen Wert und
diesen Autorisierungs-Header teilen, werde ich den Wert aufteilen.
Wie Sie sehen können, ermöglicht der Puffer Ihnen, den Wert zu teilen und
dann geben wir auch die Codierung des Puffers, der Base64-Codierung hier ist.
Also werden wir das in einen Puffer konvertieren, indem wir diesen in zwei Teile teilen und
den Raum als Splitting Teil verwenden.
Wenn Sie sich also den Autorisierungs-Header anschauten, haben Sie gesehen, warum
der Leerraum den Wert „basic“ trennt, und dann gibt es Ihnen
den Rest der Base64-codierten Zeichenfolge, die den Benutzernamen und das Passwort enthält.
Und daraus möchten wir den Benutzernamen und das Passwort extrahieren.
Also werden wir diesen Wert teilen, und dann werden wir nur berücksichtigen,
wenn Sie die Zeichenfolge teilen, indem Sie dies verwenden, wird es das in ein Array aufteilen.
Und das erste Element des Arrays enthält Basic.
Das zweite Element des Arrays ist, wo diese base64-codierte Zeichenfolge vorhanden ist.
Deshalb schauen wir uns nur das zweite Element dieses Arrays an.
Diese Aufteilung bewirkt also, dass die Zeichenfolge in ein Array von zwei Elementen aufgeteilt wird.
Also könnten wir, wir nehmen die base64-codierte Zeichenfolge davon auf.
Und dann werden wir in diesen Puffer, und dann werden wir das in String konvertieren.
Und dann noch einmal, teilen Sie die Zeichenfolge noch einmal, da die Zeichenfolge
selbst den Benutzernamen und das Kennwort enthält, getrennt durch einen Doppelpunkt.
Also, ich werde es mit dem Doppelpunkt als
Aufteilungspunkt für diese Zeichenfolge hier teilen.
Beachten Sie also, dass ich hier zwei Splits lade, eine auf das Leerzeichen und
die zweite, mit dem Doppelpunkt, der den Benutzernamen und das Passwort trennt.
Am Ende dieser Variablen auth sollte also ein Array sein, das zwei Elemente enthält,
den Benutzernamen und das Passwort, das aus der base64-Zeichenfolge extrahiert wird.
Also an diesem Punkt, was ich tun werde, ist,
nur zu Ihrer Klarheit,
werde ich einfach var
username = auth [0] sagen und dann
var password = auth [1].
Jetzt habe ich den Benutzernamen und das Passwort aus meinem Autorisierungs-Header extrahiert.
Jetzt werde ich einen Standardwert für den Benutzernamen und das
Passwort in dieser Implementierung verwenden.
Später werden wir sehen, dass wir den Benutzern erlauben können, ihren eigenen Benutzernamen und ihr
Passwort zu erstellen.
Aber im Moment werde ich nur verwenden,
Der codierte Benutzername und Passwort als Admin.
Und das Passwort wird nur Passwort sein.
Für diese grundlegende Übung
verwenden wir dies als Standard-Benutzername und Passwort.
Wenn der Benutzername, den ich erhalte, admin ist und das Passwort das String-Passwort ist.
Dann bin ich alles in Ordnung zu erlauben, dass die
Client-Anfrage an die nächste Middleware weitergegeben wird, also werde ich als nächstes sagen.
Also, wenn ich als nächstes sage, bedeutet dies, dass von der Authentifizierung
ihre Anfrage den nächsten Satz von Middleware hier weitergegeben wird und
Express dann versuchen wird, die spezifische Anfrage zu entsprechen, um
bestimmte Middleware zu sein, die diese Anfrage bearbeitet.
Das ist also, wo wir zulassen, dass es durchgeht.
Wenn nicht, bedeutet das, dass der Benutzername und
das Passwort nicht mit der Anfrage,
dem Standard-Benutzernamen und dem Passwort übereinstimmen, die ich einrichte.
Das bedeutet also, dass es einen Fehler gibt.
Also in diesem Fall werde ich hier wieder einen Fehler verursachen,
also sagen wir sonst, Fehler.
Wir werden also wieder einen Fehler generieren und dann den Client auffordern,
hier die richtigen Autorisierungsinformationen, den Benutzernamen und das Passwort einzugeben.
Das war's also.
Dieses kleine bisschen Middleware, die wir gerade hier implementiert haben,
Autorisierungs-Middleware, die wir gerade hier implementiert haben.
Reicht aus, um die grundlegende Authentifizierung innerhalb der Out-Anwendung zu implementieren.
Nachdem wir diese Änderungen vorgenommen haben,
speichern wir die Änderungen und dann werden wir sehen, wie das tatsächlich in der Praxis funktioniert.
Speichern wir die Änderungen.
Und dann starten wir unseren Server.
Nun, gehen Sie zum Terminal, natürlich,
stellen Sie sicher, dass Sie MongoDB-Server sind und läuft.
Andernfalls wird der Express-Server nicht gestartet.
Also habe ich die Eingabeaufforderung npm start eingeben, und
dann wird Ihr Express-Server betriebsbereit sein.
Öffnen Sie nun im Inkognito-Fenster in Ihrem Browser.
Der Grund, warum ich Sie bitten, ein Inkognito-Fenster zu verwenden, ist, dass, wenn Sie
den Benutzernamen und das Passwort eingeben, es von Ihrem Browser zwischengespeichert wird.
Wenn Sie also ein Inkognito-Fenster verwenden, wenn Sie den Browser neu starten...
Dann wird der Cache automatisch gelöscht,
so dass diese Informationen nicht gespeichert werden.
Was passiert nun, wenn Sie den Benutzernamen und das Kennwort eingeben, wird es zwischengespeichert.
Wenn Sie also versuchen, auf den Server zuzugreifen,
werden die zwischengespeicherten Informationen automatisch in der von Ihnen generierten Anfrage gesendet.
Deshalb ist es wichtig,
ein Inkognito-Fenster zu verwenden, nur um Ihnen zu zeigen, dass die grundlegende Authentifizierung funktioniert.
Geben Sie also in der Adressleiste Ihres Browsers localhost:3000 ein und sehen Sie, was passiert.
Wenn Sie also localhost:3000 eingeben, sehen Sie sofort, dass Ihr Browser
diesen Dialog oben öffnet und Sie auffordert, den Benutzernamen und das Passwort einzugeben.
Wenn Sie es nicht eingeben, lassen Sie mich einen zufälligen Benutzernamen eingeben und dann sehen, was passiert.
Wenn ich also einen zufälligen Benutzernamen und ein Passwort eingebe,
sehen Sie, dass die Anfrage abgelehnt wird.
Ich darf nicht auf den Server zugreifen, und
dann, wenn der Server wieder sagt, dass der Client nicht autorisiert ist.
Und so wird es wieder kommen und uns wieder für die richtige Authentifizierung herausfordern.
Lassen Sie mich also die aktuelle Authentifizierung eingeben.
Also lassen Sie mich admin und das Passwort als Passwort eingeben.
Und dann melden Sie sich an, und Sie werden sehen, dass jetzt die
Express-Anwendung Ihnen erlaubt, auf den Standardwert zuzugreifen, der
in diesem Fall die Datei Index.html aus diesem statischen öffentlichen Ordner ist.
Nun, das gleiche, wenn Sie versuchen, auf localhost: Gerichte
ohne die Autorisierung zuzugreifen, dann funktioniert es nicht.
Und ich werde Ihnen das in einer Minute mit dem Postboten zeigen.
Nachdem wir nun gesehen haben, wie die Authentifizierung funktioniert,
schauen wir uns an, was auf der Konsole auf unserer Serverseite passiert ist. Wenn Sie
zur Konsole auf unserer Serverseite gehen, sehen Sie, dass
hier eine ganze Reihe von Informationen ausgedruckt wurde, so wie Sie gesehen
haben, haben wir die Anforderungskopfzeilen hier abgemeldet.
Dies ist also die erste Anfrage, die mit dem Anforderungsheader einging.
Und hier sehen Sie, dass es keinen Autorisierungsheader in der Anfrage gibt.
Und so hat Ihr Server das abgelehnt, mit einer 401 bat unseren Client, sich selbst zu autorisieren.
Das zweite Mal auch, da wir nicht in die richtige Autorisierung eingegeben haben, dass der
Server abgelehnt.
Natürlich bemerken Sie jetzt, dass in der Kopfzeile, genau dort, die Autorisierung
tatsächlich enthalten ist, und Sie sehen, wie die Autorisierung enthalten ist.
Es sagt Basic durch ein Leerzeichen
getrennt und durch die 64-Bit-codierte Zeichenfolge getrennt, die den Benutzernamen und das Passwort enthält.
Und dann sehen wir, dass der Server
dies abgelehnt hat, weil die Autorisierung zu diesem Zeitpunkt falsch war.
Später haben wir den korrekten Benutzernamen und das Passwort eingegeben.
Also genau dort in der dritten Anfrage, die hereinkam, haben wir den richtigen Benutzernamen und
das Passwort eingegeben.
Deshalb sehen Sie, dass der Anforderungsheader die Autorisierung enthält,
und diese Zeichenfolge verwendet die korrekte Kodierung des Benutzernamens und des Passworts.
Woher weiß ich das?
Nun, ich habe gekreuzt und weiß,
dass, das ist die grundlegende fremd codierte Version der Zeichenfolge dort.
Wir werden das auch von unserem Postbotenbild sehen oder was.
Nun sehen Sie, dass die Anforderung akzeptiert wurde und
der Wert korrekt zurückgegeben wurde.
Und dann natürlich, später, forderte der Kunde nach einem Favicon, dem Symbol.
Und da wir das Favicon nicht auf unserer Serverseite haben, antwortet es mit dem 404 und
natürlich wird Ihr Lieblings-Icon nicht in der Adressleiste angezeigt.
Also, das ist in Ordnung, aber beachten Sie insbesondere.
Diese speziellen angeforderten kamen,
wo der korrekte Autorisierungs-Header enthalten war.
Und so war es damals erfolgreich.
Lassen Sie uns mal sehen, wie wir das Gleiche mit Postmap machen können.
Also hier habe ich mein Postkarten-Fenster geöffnet.
Und so in meinem Postman-Fenster werde ich
ein get to localhost eingeben: an meinen Server, und dann die Anfrage senden und
Sie werden sofort bemerken, dass es herausfordert, zu sagen 401 nicht autorisiert.
Dies ist also die Antwortnachricht von der Serverseite,
so beachten Sie, was es speichert, 401 Unauthorized.
Und es sagt, dass die Antwort ein WWW-Authenticate-Header-Feld enthalten muss.
Und dies wird den Client herausfordern, die Autorisierungsinformationen, den
Benutzernamen und das Passwort einzugeben.
So sehen wir in der Vorschau, dass der Satz, den Sie nicht authentifiziert sind und
dann der Code 401 hier.
Betrachten Sie nun die Kopfzeilen der Antwortnachricht.
Wenn Sie sich die Kopfzeile der Antwortnachricht ansehen, können Sie insbesondere
diesen dort enthaltenen Header sehen, der www.authenticatebasic ist.
Nun, wie machen wir Authentifizierung oder Autorisierung in der Post?
Dies ist also, wo sie zu diesem direkt unter diesem Feld hier gehen würden,
Sie werden diese Autorisierung hier sehen.
Und wenn Sie auf die Autorisierung klicken, sagt es jetzt NO AUTH..
Lassen Sie uns die grundlegende Authentifizierung verwenden.
Wenn ich also grundlegende Authentifizierung sage,
gibt es mir diese beiden Felder hier, in denen ich den Benutzernamen und das Passwort eingeben kann.
Lassen Sie mich den richtigen Benutzernamen und das Passwort eingeben.
Also werde ich sagen Benutzername admin, Passwort ist Passwort P-A-S-S-W-O-R-D.
So können Sie das sehen, das ist genau das Passwort, das wir hier haben.
Sobald Sie also den Benutzernamen und das Passwort eingeben, werden sie Update Request (Update Request) sagen.
Wenn ich also auf Update-Anfrage klicke, würden Sie sehen, dass sofort in der Kopfzeile,
werden Sie sehen, dass
es dieses Feld hier gibt, das hier hinzugefügt wurde und die Autorisierung sagt.
Und dann werden Sie sehen, was dieser zweite Teil, der Wert, den Sie nehmen können.
Es sagt einfach und ein Leerzeichen, und dann diese bestimmte Zeichenfolge.
Wenn Sie also diese bestimmte Zeichenfolge hier überprüfen, wird dies die genaue
Zeichenfolge sein, die Sie in der Kopfzeile der erfolgreichen Anforderungsnachricht sehen werden.
Beachten Sie, was diese Zeichenfolge sagt.
Es sagt YWR etwas, und endet dann mit einem Q gleich. Wenn Sie
zu unserem Terminal gehen, sehen Sie, dass die erfolgreiche Anfrage
tatsächlich genau diese Zeichenfolge hier enthielt.
Es sagt YWR und endet dann mit Q gleich dort.
Indem Sie also die Informationen in die Autorisierung eingeben und dann auf
die Update-Anfrage klicken, werden diese Informationen in die Autorisierungs-Header eingefügt.
Also, jetzt ist dies eine Get-Anfrage,
ich brauche den Inhaltstyp dort nicht, weil er keinen Körper enthält.
Nun, da die Autorisierung eingeschlossen wurde,
lassen Sie uns die Anfrage jetzt korrekt senden und dann werden Sie sehen, dass
die Antwort von der Server-Site die Indexdatei enthält, wie Sie es erwarten.
Lassen Sie mich die Autorisierung löschen.
Dies ist der Grund, warum Postmap mir hilft, diese Dinge viel
einfacher zu überprüfen, ich kann die Autorisierung löschen und dann die Anfrage senden.
Und es wird immer noch diese Autorisierung enthalten,
weil ich dies in das Autorisierungsfeld eingegeben habe.
Also lassen Sie mich die Autorisierung von dort löschen und dann die Anfrage hier senden.
Und dann steht, dass Sie nicht authentifiziert sind.
Ebenso, wenn ich die Anfrage an das Geschirr schicke.
Zuvor funktionierte das gut, aber
jetzt sehen Sie, dass wir daran gehindert werden, auch auf den Endpunkt /Gerichte zuzugreifen.
Und das gleiche mit allen anderen Rest APR Endpunkte auch.
Sie haben keinen Zugriff, da die Autorisierungs-Middleware kommt, bevor
Sie Zugriff auf einen dieser Endpunkte
in der Liste der Middleware für Ihren Express-Server erhalten.
Also, wenn ich jetzt die Autorisierung
einschließe, und dann meine Anfrage aktualisieren und dann die Anfrage an den Server senden,
dann wird der Server antworten.
Jetzt ist offensichtlich in diesem Moment meine Datenbank leer, also
antwortet sie dort mit einem leeren Array.
Aber jetzt ging die Anfrage erfolgreich durch, und
ich bin in der Lage, die Informationen von der Serversocke abzurufen.
Dies ist also eine schnelle Demonstration der
Grundberechtigung in unserer Express Rest APR Anwendung.
Damit schließen wir diese Übung ab.
Dies ist ein guter Zeitpunkt für
Sie, einen get Kommentar mit der Nachricht der grundlegenden Authentifizierung zu tun.
( MUSIK)