[MUSIC]
Der Express REST API-Server, den wir im vorherigen
Modul implementiert haben, ermöglicht es jedem Benutzer, eine der GET- oder POST- oder DELETE-Operationen auszuführen.
Es gibt keine Kontrolle darüber, wer diesen Vorgang ausführen kann.
Was bedeutet, dass,
wenn Sie einen Server so ausführen, jeder auf Ihren Server kommen kann und
anfangen kann, die Informationen zu manipulieren, die in Ihrer Datenbank vorhanden sind.
Dies ist offensichtlich eine gefährliche Situation.
Die Art und Weise, wie der Server implementiert werden sollte, ist, dass
Sie eine Art von Einschränkung haben müssen
, welche Arten von Benutzern erlaubt werden, welche Arten von Operationen auszuführen.
Vielleicht würden Sie erlauben und
einem autorisierten Benutzer nur GET-Operationen auszuführen.
Zum Beispiel, wenn Sie möchten, dass ein Gast in der Lage sein, Informationen
über die Gerichte in Ihrem Restaurant oder die Speisekarte Ihres Restaurants zu sehen und
so weiter, das ist durchaus akzeptabel.
Sie können jedoch nur einem Administrator erlauben,
die Informationen über das Gericht zu ändern oder ein Gericht aus dem Menü zu löschen.
Und aktualisieren Sie auch ein vorhandenes Gericht im Menü, eine Promotion,
oder die Informationen über die Führer auf Ihrer Server-Seite.
Jetzt könnten Sie auch eine andere Gruppe von Benutzern haben, die registrierte Benutzer sein werden
, die berechtigt sein können, einige ihrer Gerichte als ihre Lieblingsgerichte zu speichern,
und nur sie würden in der Lage, die Liste ihrer Lieblingsgerichte zu manipulieren.
Das ist also eine weitere Autorisierungs- oder
Authentifizierungsstufe, die Sie durchführen müssen.
Sie haben also verschiedene Arten von Benutzern und
auch, je nachdem, welche Art von Operationen sie ausführen dürfen.
All dies bedeutet also, dass Sie irgendeine Art von Sicherheit benötigen, um
in Ihre Serverseite eingebaut zu werden.
Wir werden uns ansehen, wie wir Benutzer authentifizieren können, und
dann entscheiden, welche Art von Benutzer dieser Client ist.
Und dann
können Sie abhängig vom Typ des Benutzers dem Benutzer erlauben, bestimmte Arten von Operationen auszuführen.
Wir beginnen mit dem grundlegenden Verständnis dessen, was wir als
Basic Authentication auf einer serverseitigen Seite für
einen Client nennen, und bauen dann auf dem gesamten Rest dieses Moduls.
Und dann am Ende dieses Moduls werden wir mit einem Mechanismus enden, der es den
Benutzern ermöglicht, sich zu registrieren.
Außerdem können registrierte Benutzer bestimmte Vorgänge ausführen
, die ein nicht registrierter Benutzer nicht durchführen kann usw.
Daher werden wir verschiedene Arten von Zugriffskontrollen für
verschiedene Operationen auf der Serverseite basierend auf der Art des Benutzers auferlegen.
Das setzt Sie also die Perspektive, oder
vielmehr die Idee dessen, was Sie in diesem Modul begegnen werden.
Beginnen wir mit der grundlegenden Authentifizierung,
dem sehr einfachen Mechanismus, der es uns ermöglicht, Benutzer zu authentifizieren. Die
Standardauthentifizierung in HTTP ist ein sehr einfacher Mechanismus
, der den Benutzer nach einem Benutzernamen und
Passwort fragt, die mit einer Anfrage gesendet werden.
Und es gibt eine spezifische Struktur,
wie diese Informationen vom Client zum Server gesendet werden.
Dies ist also eine Sache, die grundlegende Zugriffsauthentifizierung, die HTTP unterstützt,
ist eine Angelegenheit, die es einem Server ermöglicht, einen Client herauszufordern und
den Benutzernamen und das Passwort vom Client zu übermitteln.
So kann der Server den Client auffordern, sich zu authentifizieren, indem er diese
Informationen eingibt.
Der Client muss den Benutzernamen und das
Passwort als Antwort auf die Herausforderung von der Serverseite senden.
Daher
sollte jede Anforderungsnachricht, die von einem Client stammt, die codierte Form des Benutzernamens und des
Kennworts in den Anforderungsheader enthalten, der vom Client zur Serverseite geht.
Wenn der Server die Anforderung erhält,
extrahiert der Server diese Informationen aus dem Anforderungsheader des Clients.
Verwenden Sie das dann für die Authentifizierung des Clients, bevor Sie
den Zugriff auf die verschiedenen Operationen auf der Serverseite zulassen.
Also, wie funktioniert diese Authentifizierung?
Wenn ein Client eine Anforderung an den Server sendet und
diese Clientanforderung die Autorisierungsformation nicht enthält, fordert der Server
den Client heraus, er fordert den Client auf, um diese Informationen zu übermitteln.
Der Server fordert den Client heraus, indem er
einen Header in die Antwortnachricht einfügt.
Der Header mit dem Typ WWW-Authenticate, und
dann der zweite Teil, in dem er den Typ angibt, ist, wo er
angeben wird, welche Art von Authentifizierung der Client gesendet werden muss.
Und wir werden hier mit dem Verständnis der grundlegenden Authentifizierung beginnen.
Beachten Sie auch, dass die Antwortnachricht einen 401-Fehlercode enthält
, der nicht autorisiert ist, der für nicht autorisiert steht.
Wenn die Antwort also von der Serverseite zurückkommt,
muss der Client als Antwort auf diese Antwort, der Client seine Anfrage senden,
einschließlich eines bestimmten Header-Feldes in der Anforderungsnachricht der Typautorisierung.
Und dieses Autorisierungs-Header-Feld enthält einige Informationen darin.
Für eine grundlegende Authentifizierung wäre diese Information in Form von,
wie das erste Wort hier, wird Basic sein.
Und dann gefolgt von einem Leerzeichen hier und gefolgt von einer Base64-codierten Zeichenfolge hier.
Diese Base64-codierte Zeichenfolge codiert den Benutzernamen und
das Kennwort in einem bestimmten Format und schließt diese dann in die Kopfzeile ein.
Jetzt sagen Sie, wenn Sie eine Anforderungsnachricht wie diese senden,
einschließlich dieser, in der Kopfzeile, dann jemand in der Mitte.
Wenn Sie also etwas über Sicherheit wissen und
wie man in der Mitte Angriffe gestartet werden können, dann
kann dies offensichtlich von einem Eindringling dazwischen abgerufen werden
und dann verwendet werden, um den echten Client zu fälschen.
Auch hier kommen wir im Moment nicht auf diese Frage ein.
Wenn ich im nächsten Modul über HTTPS spreche,
werde ich zurückkommen, um dieses Problem etwas detaillierter anzugehen.
Aber im Moment werden die Informationen im Header gesendet,
ohne in der Header zu diesem Zeitpunkt verschlüsselt zu werden.
Nun, ein weiterer Grund, warum ich das tue, ist, dass wir
den Header direkt betrachten und dann diese Informationen in der Kopfzeile selbst sehen können.
Wenn der Client diese Anforderung sendet, extrahiert der Server
die Informationen aus diesem Autorisierungs-Header im Anforderungs-Header.
Und dann verwenden Sie diese Informationen, um zu überprüfen, ob es sich um
eine autorisierte Clientanfrage handelt oder nicht.
Nun wäre Ihre nächste Frage natürlich,
was genau enthält dieser Autorisierungs-Header?
Der Autorisierungs-Header selbst wird wie folgt aufgebaut.
Wenn Sie einen Benutzernamen und ein Kennwort haben, sind dies die beiden
Informationen, die Sie verwenden, um einen Client zu authentifizieren.
Der Benutzername und das Passwort werden also zu einer einzigen Zeichenfolge verkettet
, indem Benutzername und Doppelpunkt und das Passwort selbst gesagt werden.
Der Benutzername, der Doppelpunkt und
das Passwort werden hier zu einer ganzen Zeichenfolge verkettet.
Diese resultierende Zeichenfolge, die wir hier bekommen, ist, dass, kodiert mit Base64-Codierung.
Wenn Sie wissen, wie die Codierung Grundlagen für die Codierung durchgeführt wird,
konvertieren Sie diese in einen ASCII-Header wie in diesem Beispiel hier gezeigt,
so dass dies nichts anderes als eine Zeichenfolge von ASCII-Headern ist.
Wenn Sie nun nicht viel über grundlegende steife Codierung wissen, machen Sie sich keine Sorgen darüber,
es hat keinen Einfluss auf Ihr Verständnis dessen, was hier vor sich geht.
Also diese Basic64-codierten Strings, so dass
diese spezielle Information in eine Zeichenfolge wie diese codiert und
dann in den Anforderungsheader eingeschlossen wird, der vom Client zum Server geht.
Der Request-Header selbst ist von der Typautorisierung,
und dann folgt der tatsächliche Wert hier, der besagt
, Basic, und ein Leerzeichen hier, und die Base64-codierte Zeichenfolge hier.
Wenn dies von unserem Server empfangen wird, extrahiert der Server diese Informationen,
und dann extrahiert er den Benutzernamen und das Passwort und
überprüft dann, ob dies einem autorisierten Benutzer entspricht oder nicht auf der Serverseite.
Um Ihnen zu helfen, besser zu verstehen, wie wir die Express-Anwendung tatsächlich organisieren
und wie die Authentifizierung selbst durchgeführt wird, wie wir bereits gelernt haben,
sind Express-Anwendungen selbst in einer Reihe von Middleware organisiert.
Und die Art und Weise der Express-Anwendung funktioniert, ist, dass die Middleware
auf die Anfrage und die Antwortnachricht
in der Reihenfolge angewendet wird, in der sie in meiner Express-Anwendung deklariert wird.
Also, wenn Sie eine express.use haben und
dann den ersten haben, der einen statischen Server sagt, dann
haben Sie danach eine andere Middleware, dann haben Sie eine andere Middleware.
Die Reihenfolge, in der sie
beispielsweise in der Datei „Express server app.js“ deklariert werden, ist die genaue Reihenfolge, in der die Middleware angewendet wird.
Eine eingehende Anfrage von der Serverseite, wie Sie sich in Ihrer
Express-Anwendung zurückrufen, wird die eingehende Anfrage als Anforderungsobjekt behandelt.
Das Antwortobjekt ist das, was
der Express-Server konstruiert, und dann können Sie mit der nächsten Middleware
fortfahren, die Sie anwenden werden, usw.
Also, eine eingehende Anfrage wie diese, wenn sie hereinkommt, wird die erste Middleware angewendet.
Und sobald diese Middleware sowohl die Anfrage als auch
die Antwort transformiert hat, geht sie zur nächsten Middleware über, die dann auf sie angewendet wird.
So haben wir zum Beispiel gesehen, dass wir Morgan zuerst angewendet haben,
dann haben wir Body Parser auf die Middleware angewendet.
Sie müssen also bereits die Anforderung und die Antwortobjekte transformiert haben.
Und danach können wir dort eine Authentifizierungs-Middleware einbinden.
Die Authentifizierungs-Middleware wird die Anforderung authentifizieren.
Wenn Sie also die Standardauthentifizierung verwenden,
muss Ihre Anfrage im Header den Autorisierungsheader enthalten, der dort vorhanden ist.
Daher wird der Autorisierungs-Header von der Authentifizierungs-Middleware extrahiert
und dann überprüft, ob der Benutzer autorisiert ist.
Und wenn die Authentifizierungs-Middleware erkennt, dass Sie ein autorisierter Benutzer sind,
können Sie mit dem nächsten Satz
Middleware fortfahren, der dem Authentifizierungsschritt folgt.
Und Ihre Unterlagen werden von der nachfolgenden Middleware verarbeitet.
Andererseits,
wenn Ihre Authentication Middleware entscheidet, dass Sie kein autorisierter Benutzer sind,
dann wird die Authentication Middleware Sie auf einen anderen Weg führen.
Und dann generieren Sie einen Fehler, und senden Sie dann
eine entsprechende Fehlerantwort an diese Client-Seite zurück und
wird an den Fehlerbehandler umgeleitet.
Diese Umleitung zum Fehlerhandler wird also durch Aufrufen von Next
mit dem Fehler als Parameter zu diesem Next hier durchgeführt.
Also der Nächste ist genau dieser Nächste, den wir in der Anforderungsressource sehen Weiter hier.
Und das führt Sie den ganzen Weg bis zum Fehlerhandler, der Fehler behandelt
und dann die Fehlermeldung zurück an die Client-Seite sendet,
was auf den Fehler der Authentifizierung hinweist.
So
funktioniert Ihre typische grundlegende Autorisierung oder Standardauthentifizierung in Ihrer serverseitigen Anwendung.
Nachdem wir dies verstanden haben, gehen wir zu der Übung über, wo
wir die grundlegende Authentifizierung in unserer Anwendung implementieren und
sehen, wie sie Benutzer authentifiziert.
( MUSIK)