[MUSIK]
In der vorherigen Lektion haben wir etwas über die grundlegende Authentifizierung erfahren.
Wir haben gesehen, dass der Client bei der Standardauthentifizierung explizit weiter
in das Autorisierungsfeld mit dem Benutzernamen und dem
Passwort für jede Anfrage hinzufügen muss, die der Client an die Serverseite sendet.
Jetzt ist das perfekt für die einfache Authentifizierung.
Cookies sind ein weiterer Mechanismus, der es Ihrem Server ermöglicht,
erwarten zu können, dass der Client einige Informationen auf der Client-Seite speichert und
diese Informationen explizit in jede ausgehende Anfrage einbezieht.
Anstatt also Ihren Base-64-codierten Benutzernamen und Ihr
Passwort wie bei der Basisauthentifizierung mit Cookies einzufügen,
kann Ihr Server eine explizite Information auf der Clientseite einrichten
, die dann in jeder ausgehenden Anfrage von der Clientseite enthalten wird.
Wenn Ihr Server Informationen über Ihren
Client verfolgen möchte, kann der Server explizit einen Sitzungsverfolgungsmechanismus einrichten.
Jetzt sind Cookies klein und können nicht viele Informationen darin speichern,
und dies kann natürlich nicht in die ausgehende Anfrage aufgenommen werden.
Cookies können einige grundlegende Informationen
in der Kopfzeile der ausgehenden Anfrage des Kunden enthalten.
Nun, wenn wir wollen, dass viel mehr Informationen über einen Client
auf der Serverseite verfolgt werden, dann ermöglichen Express-Sessions es uns, dies zu tun.
Lassen Sie uns
in dieser Lektion mehr über Cookies und Express-Sitzungen näher studieren und
sie auch in den Übungen, die dieser Vorlesung folgen, weiter untersuchen.
Was sind HTTP-Cookies?
HTTP-Cookies sind, wie ich bereits erwähnt habe, kleine Daten, die
von einem Webserver gesendet werden und auf der Client-Seite gespeichert werden.
Jetzt haben fast alle Browser die Möglichkeit,
das Speichern von Cookies auf der Clientseite zu unterstützen und sie automatisch
in die Anfrage aufzunehmen, wenn die Anfrage an einen bestimmten Server gesendet wird.
Jede nachfolgende Anfrage von der
Clientseite enthält also einen neuen Header
mit dem Cookie in der Anforderungskopfzeile.
Nun offensichtlich, wenn Sie gesehen haben, dass die Presse
dort einen schlechten Ruf bekommen hat, ist das natürlich nicht völlig unverdient.
Aber es ist weit aus dem Verhältnis geblasen, als das, was wirklich die Wahrheit ist.
Also nehmen Sie alles, was Sie in der populären Presse über Cookies und
ihren schlechten Ruf mit einem Korn Salz lesen.
Cookies sind sehr nützlich, um viele interessante Dinge zu tun.
Und wir können sicherstellen, dass Cookies eine ausreichende
Integrität aufweisen können, damit sie von niemandem manipuliert werden können.
Wie funktioniert diese Cookie-Einstellung Aufnahme in die ausgehende Anfrage?
Wenn ein Client eine Anforderung an den Serverstandort sendet,
wenn der Client am Serverstandort authentifiziert ist.
Zum Beispiel, mit der Basisauthentifizierung,
dann kann der Server im Gegenzug, ein Cookie einrichten.
Um nun ein Cookie auf der Website des Clients einzurichten, wird der Server in die
Antwortnachricht einen Header mit dem gesendeten Cookie-Header und
dem eigentlichen Cookie im Header aufnehmen.
Wenn der Client nun die Antwortnachricht von dem Server empfängt,
der den Set-Cookie-Header enthält, wird das Cookie auf der Clientseite eingerichtet.
So dass jede nachfolgende Anfrage, die von der Client-Seite geht,
explizit ein Header-Feld namens Cookie und
tatsächlichen Header enthält, der als Wert
die Cookie-Informationen enthält, die vom Server in der Antwortnachricht gesendet wurden.
Daher wird jede nachfolgende Anforderungsnachricht dieses Cookie in der Kopfzeile tragen.
Wenn der Server diese Anforderungsnachricht erhält, ist er in der Lage,
den Cookie zu untersuchen und zu vermuten, von wem diese Anfrage kommt.
So ist es in der Lage, den Client durch Blick auf die Cookie-Informationen zu erkennen.
Hier erweisen sich Cookies als sehr nützlich, um
Autorisierungsinformationen senden zu können.
Also in der Bereitstellung einschließlich Benutzername und Passwort als Teil der grundlegenden
Authentifizierung Header in jeder laufenden Anfrage.
Wenn Sie sich das erste Mal authentifizieren, senden Sie Ihren Benutzernamen und Ihr Passwort und
der Server richtet das Cookie auf Ihrer Seite ein.
Anschließend müssen Sie das Cookie nur in die ausgehende Anfrage aufnehmen.
Jetzt können Cookies auch ein Ablaufdatum mit ihnen verbunden sein.
Somit gilt der Cookie zu diesem Zeitpunkt als abgelaufen und ist
nicht mehr gültig.
Das ist also eine Möglichkeit, die Dauer zu kontrollieren
, für die eine Autorisierung gültig ist.
Wie unterstützt Express Cookies?
Jetzt, wie wir verstehen, verwendet Express eine Menge Middleware.
Dies ist, wo einer der Middlewares, die als Cookie-Parser
kommt, um acht Uhr zu unserer App kommt.
Der Cookie-Parser ermöglicht es dem Server, ein Cookie im Antwort-Header einzurichten.
Dies geschieht also durch die Verwendung von res.cookie und den Namen und
bestimmte Werte und die Optionen, wie wir in der Übung später sehen werden.
Und so werden Cookies, wenn sie von der Client-Seite gesendet werden, die in dieser
Anforderungsnachricht enthalten sind, auf der Express-Serverseite mit dem Cookie-Parser analysiert.
Die Cookie-Parser-Middleware
, mit der Sie bei der Installation die eingehenden Cookies analysieren können.
Und dann werden diese eingehenden Cookies
als Header in die Anfrage eingefügt und können serverseitig untersucht werden.
Um die Authentizität des Cookies zu schützen,
können die Cookies selbst vom Server signiert werden.
Wenn der Server nun ein Cookie signiert, verwendet der Server einen geheimen Schlüssel
, der nur der Serverseite bekannt ist.
Wenn Sie jetzt etwas über Computersicherheit und Kryptographie und
Verschlüsselung wissen, dann verstehen Sie, was Signieren und geheime Schlüssel und
öffentliche Schlüssel und all diese Dinge bedeuten.
Wenn Sie dies nicht tun, genügt es, zu sagen, dass ein geheimer Schlüssel
eine bestimmte Zeichenfolge ist, die nur der Server kennt und niemand sonst weiß.
Wenn ein Server also ein Cookie verschlüsselt, verwendet er einen geheimen Schlüssel als Signatur und
erstellt, was als Schlüssel-Hash-Nachrichtenauthentifizierungscode bezeichnet wird.
Und schließt dies in diesem Cookie, das vom Server an die Client-Seite gesendet wird.
Dieser HMAC, der auf der Serverseite erstellt wird, kann nur
von diesem bestimmten Server ausgeführt werden, der diesen geheimen Schlüssel kennt.
Jetzt, da der Server eine geschützte Ressource ist, so dass
nur der Server den geheimen Schlüssel kennen und so ist es sehr einfach zu überprüfen,
wenn ein signiertes Cookie von der Client-Seite auf die Serverseite gesendet wird.
Wenn also das signierte Cookie von der Client-Seite auf die Serverseite gesendet wird,
wird das Cookie auf der Clientseite eingerichtet, und
dann werden alle nachfolgenden Anfragen dieses signierte Cookie auf der Clientseite enthalten.
Die Cookie-Parser-Middleware, die wir mit unserem Express-Server eingerichtet haben,
unterstützt nun bereits signierte Cookies.
Nun geben Sie im Cookie-Parser auch den geheimen Schlüssel als
Parameter für den Cookie-Parser an, wenn Sie die Cookie-Parser-Middleware einrichten.
Dabei werden alle Cookies entsprechend signiert und anschließend versendet.
Und wenn das Cookie auf der Serverseite in der eingehenden
Anforderungsnachricht analysiert wird, wird dies in die Anforderungsnachricht als Req.signedCookies eingefügt.
Und dann können Sie ein bestimmtes Feld haben, das Sie in den signierten Cookie einchecken können.
Cookies sind sehr nützlich, um
Ihren Kunden Informationen senden zu können, wodurch Ihr Server den Client erkennt.
Aber natürlich haben Cookies Einschränkungen.
Sie haben eine feste Größe, so dass sie nicht viele Informationen
über den Client codieren können, die ihr Server aus dem Cookie abrufen kann.
Das Cookie wird verwendet, um den Server nur daran zu erinnern
, welcher Client die Anfrage sendet.
Wenn Sie nun einen aufwändigeren Mechanismus haben möchten, um Informationen über
einen Client zu verfolgen, können Sie auf der Serverseite einrichten, was als Sitzungen bezeichnet werden.
Jetzt sind Sitzungen ein generischer Mechanismus, der für alle Server verfügbar ist.
Insbesondere betrachten wir Express selbst und
wie Express die Sitzungsverwaltung auf der Serverseite unterstützt.
Die Funktionsweise besteht darin, dass die Benutzersitzung auf der Serverseite eingerichtet ist.
Diese Sitzung selbst ist also eine Kombination aus einem Cookie und
einer Sitzungs-ID, und die serverseitige Verfolgung von Informationen
, die mit dieser Sitzungs-ID verknüpft sind oder durch diese Sitzungs-ID indiziert werden.
Die Sitzungsinformationen selbst können
beliebig viele Informationen auf der Serverseite verfolgt und von diesem Cookie indiziert werden.
Wenn also ein Client eine Anfrage über den Server sendet, dann
wird aus dem Cookie die Sitzungs-ID abgerufen und die als Index auf die Serverseite verwendet wird.
Wenn Sie beispielsweise eine serverseitige Datenbank verwenden, ist dieser Index der primäre Index in
dieser bestimmten serverseitigen Datenbank, die die Sitzungen verfolgt.
Dadurch können zusätzliche Informationen über diese Sitzung abgerufen und
von Ihrem Server verwendet werden, um Entscheidungen darüber zu treffen, wie
er die eingehende Clientanfrage bedient.
Jetzt werden die Sitzungen standardmäßig im Speicher auf der Server-Site gespeichert.
Nun offensichtlich, was das bedeutet, ist, dass, wenn Ihr Server neu gestartet
wird, Ihr Speicher gelöscht wird und so alle Sitzungsinformationen vollständig verschwunden sind.
Stattdessen werden viele Server auf eine
Form des permanenten Speichers zurückgreifen, in dem die Sitzungsinformationen verfolgt werden.
Der permanente Speicher auf der Serverseite könnte entweder
durch eine Art Dateispeicher erfolgen.
Oder nutzen Sie sogar die Tatsache, dass Sie bereits eine Datenbank auf der Serverseite haben und dann
die Sitzungsinformationen auf der Serverseite speichern.
Zum Beispiel in Ihrer MongoDB selbst.
In der folgenden Übung werden wir uns nun die Verwendung eines Dateispeichers für die
Verfolgung von Sitzungsinformationen auf der Serverseite ansehen.
Ein weiterer Aspekt, auf den Sie achten müssen, ist die Tatsache, dass, wenn
Sie eine verteilte Serverimplementierung haben, bei der
mehrere Server als Server für die Wartung der Anfrage fungieren.
Dann sollte der Verteilerserver in der Lage sein, auf die Sitzungsinformationen zuzugreifen.
Jeder dieser Server sollte auf die Sitzungsinformationen zugreifen können.
Sie benötigen also ein Verteiler-Session-Tool auf der Serverseite,
damit Sie mehrere replizierte Server unterstützen können.
Dies ist besonders nützlich, wenn wir versuchen, die Zuverlässigkeit
des Serverbetriebs zu gewährleisten.
Jetzt wieder, wir werden nicht zu viele Details über die in diesem speziellen
Kurs bekommen, wir werden uns darauf verlassen, im Grunde zu verstehen, wie Express-Sitzungen funktionieren.
Speziell zu Express kommen und
wie die Sitzungsverwaltung in Express unterstützt wird.
Express verwendet die Express-Sitzungs-Middleware, die
die Verwendung von Sitzungen auf einem Express-Server unterstützt.
Jetzt installieren Sie die Express-Sessions Middleware.
Und in der Übung werde ich den FileStore verwenden, um
die Sitzungsinformationen dauerhaft zu speichern.
Und so werden wir auch das Sitzungsdatei-Speicher-Knoten-Modul, das
es uns ermöglicht, die Dateien auf der Serverseite zu verwenden, um die Sitzungsinformationen zu verfolgen.
Wir werden die Details in der folgenden Übung sehen.
Und dann, sobald wir tun, wird Ihre Sitzung selbst mit dem neuen
Express-Server eingerichtet werden, indem Sie die Middleware hier als Sitzung deklarieren, die
einen bestimmten Satz von Optionen als Parameter hier nimmt.
Die Optionen enthalten den Namen für die Sitzung, daher geben wir die Sitzungs-ID für
die jeweilige Sitzung an.
Und dann geben Sie auch das Geheimnis an, einen geheimen Schlüssel, der für die
Kodierung des signierten Cookies verwendet wird, der an die Client-Seite gesendet wird.
Und dann auch zusätzliche Informationen einschließlich SaveUnInitialized, die
ein Flag sein wird, das verwendet wird, und auch ein Resave Flag, das verwendet wird.
Einige der Details dieser Optionen werden in der nächsten Folie betrachtet.
Also alle diese Optionen sind hier angegeben.
Und wenn Sie FileStore als permanenter Speicher für Ihre Sitzungen
sind, dann werden wir das auch in den Sitzungsoptionen dort erklären.
So würden wir eine Sitzung auf der Express-Serverseite
mit der Express-Sitzung Middleware einrichten.
Und die Express-Sitzung Middleware, wenn der Client diese Informationen sendet,
wird dies auf der Serverseite analysiert und
dies führt dazu, dass eine Eigenschaft namens Session dem Anforderungsobjekt hinzugefügt wird.
Auf diese Sitzungsinformationen kann also im
Anforderungsobjekt als req.session zugegriffen werden.
Die req.session wird also zusätzliche Informationen über diese bestimmte Sitzung
für diesen bestimmten Client enthalten.
Sobald diese Sitzung eingehende Anforderung von der Sitzungs-Middleware analysiert wird,
wird die req.session Eigenschaft dem eingehenden
Anforderungsnachrichtungsobjekt hinzugefügt, das Express verwendet.
Also, nachdem die Sitzung geparst wurde, wird die direkte Sitzungseigenschaft verfügbar sein und
wir können das auch untersuchen, um zu überprüfen, welcher Client diese Anfrage gesendet hat.
Wenn sie ihr Sitzungsobjekt auf der Server-Site
einrichten, wie wir gesehen haben, können wir verschiedene Optionen für diese Server-Site einrichten.
Das Cookie, die Optionen aus dem Session-ID-Cookie und der Standardwert für
das Cookie werden wie hier gezeigt, was Pfad ist: '/',
HttpOnly: true, secure: false, maxAge: null.
Dies wird also der Standardwert des Cookies sein, der auf dem Paket gespeichert
und als signiertes Cookie an die Seite des Kunden gesendet wird.
Und dies würde in jeder eingehenden Anfrage vom Standort des Kunden enthalten sein.
Dann ist die genid die Funktion, die die Sitzungs-ID generiert.
Standardmäßig wird die UUID des Servers selbst als allgemeine ID verwendet.
Wenn es wahr ist, erzwingt das Resave Flag dann, dass eine Sitzung wieder
im Speicher gespeichert wird, auch wenn sie nicht von der Anforderung geändert wird.
Manchmal
enthält die eingehende Anforderung möglicherweise eine Notwendigkeit, die Sitzungsinformationen auf der Serverseite zu ändern.
Wenn die Sitzungsinformationen geändert werden, muss sie dauerhaft sein.
Wenn nicht, dann müssen Sie es nicht anhalten.
Wenn Sie jedoch das Flag „Erneut speichern“ auf „true“ setzen, werden
die Sitzungsinformationen auf dem Server nicht von der eingehenden Clientanforderung geändert werden, dennoch erneut gespeichert.
Das nächste Flag, das wir uns angesehen haben, war SaveUninitialized.
Wenn dies der Fall ist, wird eine neu erstellte Sitzung erstellt, ohne dass
Änderungen am Sitzungsspeicher gespeichert werden müssen.
Jetzt werden wir dies standardmäßig auf false setzen, was bedeutet, dass wir nur
die Sitzungen verfolgen, die auf dem Server autorisiert sind.
Nun ist das Geheimnis, wie wir sehen, der geheime Schlüssel, der zum Signieren des Cookies verwendet wird,
und der Speicher selbst gibt die Session-Store-Instanz, die verwendet wird.
Standardmäßig wird der Speicher im Speicher verwendet.
Sie können den Dateispeicher oder den Mongo-Speicher zum
Speichern dieser Sitzungsinformationen angeben usw.
Wenn Sie also diese Informationen für Ihre Express-Sitzungs-Middleware angeben,
wird die Sitzung entsprechend eingerichtet und so auf der Serverseite verfolgt.
Jede Clientanforderung wird dann den Sitzungsinformationen auf der
Serverseite zugeordnet, wenn die Clientanforderung von der Express-Sitzungs-Middleware analysiert wird.
Und die req.session wird dem Anforderungsobjekt hinzugefügt.
Mit diesem Verständnis von Cookies und Express-Sitzungen, lassen Sie uns
auf die Übung gehen, wo wird prüfen, wie wir die Verwendung von Cookies zuerst machen.
Und dann schauen wir uns an, wie wir Express-Express-Sitzungen
innerhalb unserer Express-REST-API-Anwendung nutzen, an der wir bisher gearbeitet haben.
( MUSIK)