Detaillierte Erläuterung der Verwendung der Client-Sitzung in Node.js programming_node.js

Statische Websites sind leicht skalierbar. Sie speichern einfach alles zwischen und müssen nicht darüber nachdenken, zustandsbehaftete Inhalte von verschiedenen Servern für den Benutzer zu kombinieren.

Leider nutzen die meisten Webanwendungen zustandsbehaftete Inhalte, um ein personalisiertes Erlebnis zu bieten. Wenn sich Ihre Anwendung anmelden kann, muss sie sich die Sitzung des Benutzers merken. Die klassische Verarbeitungsmethode besteht darin, dass der Client ein Cookie mit einer zufälligen, eindeutigen Sitzungskennung setzt und die identifizierten Sitzungsdaten auf dem Server gespeichert werden.

Zustandsbehaftete Dienste erweitern

Wenn Sie Ihren Service erweitern, haben Sie auf jeden Fall drei Möglichkeiten:

1. Sitzungsdaten zwischen verschiedenen Servern synchronisieren
2. Verschiedene Server stellen eine Verbindung zu einem einzigen Punktzentrum her (Sitzung erhalten)
3. Stellen Sie sicher, dass Benutzer auf denselben Server zugreifen

Aber sie haben alle Mängel:

• Das Synchronisieren von Daten erhöht den Leistungsaufwand
• Ein einziges Punktzentrum verringert die Skalierbarkeit des Systems
• Was tun, wenn der Server, den der Benutzer zuletzt besucht hat, gewartet werden muss

Wenn Sie es jedoch aus einem anderen Blickwinkel betrachten, finden Sie eine vierte Option: Sitzungsdaten auf dem Client speichern

Kundensitzung

Das Speichern der Sitzung auf dem Client hat einige Vorteile:

• Egal welcher Server, die Sitzungsdaten sind gültig
• Keine Notwendigkeit, den Serverstatus aufrechtzuerhalten
• Keine Serversynchronisierung erforderlich
• Fügen Sie nach Belieben einen neuen Server hinzu

Bei der clientseitigen Sitzung gibt es jedoch ein ernstes Problem: Sie können nicht garantieren, dass Benutzer die Sitzungsdaten nicht manipulieren.

Sie speichern beispielsweise die ID des Benutzers in einem Cookie. Es kann von Benutzern leicht geändert werden, um Zugriff auf die Konten anderer Personen zu erhalten.

Dies scheint die Möglichkeit einer clientseitigen Sitzung auszuschließen, aber es gibt eine Möglichkeit, dieses Problem sauber zu lösen: Verschlüsseln und verpacken Sie die Sitzungsdaten (die weiterhin im Cookie gespeichert sind). Auf diese Weise müssen Sie sich keine Sorgen machen, dass der Benutzer die Sitzungsdaten ändert. Der Server überprüft die Daten.

In der praktischen Anwendung wird im Cookie ein verschlüsselter Serverschlüssel gespeichert. Erst nach der Überprüfung des Serverschlüssels ist er berechtigt, Sitzungsdaten zu lesen und zu ändern. Dies ist die Client-Sitzung.

Knoten-Client-Sitzung

Node.JS verfügt über eine Bibliothek, die eine clientseitige Sitzung implementieren kann: node-client-session. Sie kann die integrierte Sitzungs- und CookieParser-Middleware von Connect (ein Node-Middleware-Framework) ersetzen.

Verwendung in Express-Framework-Anwendungen:

const clientSessions = require("client-sessions"); 

app.use(clientSessions({ secret: '0GBlJZ9EKBt2Zbi2flRPvztczCewBxXK' // 设置一个随机长字符串! })

Fügen Sie dann Eigenschaften zum req.session-Objekt hinzu:

app.get('/login', function (req, res){ req.session.username = 'JohnDoe'; });

Attribute lesen:

app.get('/', function (req, res){ res.send('Welcome ' + req.session.username); });

Verwenden Sie die Reset-Methode, um die Sitzung zu beenden:

app.get('/logout', function (req, res) { req.session.reset(); });

Persona-Sitzung sofort abmelden

(Hinweis: Persona ist ein von Mozzilla eingeführtes Online-Identitätssystem)

Im Gegensatz zur serverseitigen Sitzung besteht das Problem bei der clientseitigen Sitzung darin, dass der Server die Sitzung nicht löschen kann.

In der serverseitigen Architektur können Sie Sitzungsdaten löschen. Die durch ein Client-Cookie identifizierte Sitzung ist möglicherweise nicht vorhanden. In der clientseitigen Architektur befinden sich die Sitzungsdaten jedoch nicht auf der Serverseite und es gibt keine Garantie dafür, dass die Sitzungsdaten auf jedem Client gelöscht werden. Mit anderen Worten: Wir können den Client-Status (angemeldet) und den Server-Status (abgemeldet) des Benutzers nicht synchronisieren.

Um diesen Mangel zu beheben, wird der Client-Sitzung eine Ablaufzeit hinzugefügt. Überprüfen Sie die Ablaufzeit, bevor Sie die Sitzungsdaten erweitern (verschlüsselt und verpackt). Wenn es abläuft, verwerfen Sie die Sitzungsdaten und ändern Sie den Benutzerstatus (z. B. Abmelden).

Der Ablaufmechanismus funktioniert in vielen Anwendungen gut (insbesondere bei kurzen Ablaufzeitanforderungen). Wenn der Benutzer beispielsweise in Persona feststellt, dass das Passwort bedroht oder beschädigt wurde, müssen wir eine Methode bereitstellen, mit der sich der Benutzer sofort von den Sitzungsdaten abmelden kann.

Das bedeutet, dass ein paar Statusinformationen im Service-Backend verbleiben. Die Art und Weise, wie wir mit der sofortigen Abmeldung umgehen, besteht darin, ein Token in die Benutzerdatentabelle und die Sitzungsdaten einzufügen.

Bei jedem Aufruf der API wird das Token in den Sitzungsdaten mit dem Token in der Datenbank verglichen. Wenn nicht, geben Sie eine Fehlermeldung zurück und verlassen Sie den Benutzer.

Dadurch werden redundante Datenbankoperationen zur Abfrage des Tokens hinzugefügt. Glücklicherweise erfordern die meisten API-Aufrufe das Lesen der Benutzerdatentabelle. Bringen Sie also einfach das Token mit.