Ich habe einen Session-Store-Treiber für ArangoDB für ConnectJS geschrieben. Es funktioniert, obwohl immer noch sehr viel in Alpha, aber ich habe ein paar Fragen.
Erste Sitzungen, die ein Attribut "false" haben, bleiben nur für die Dauer des Benutzeragenten bestehen. Ich habe bemerkt, dass session.destroy () nicht aufgerufen wird, wenn das Browserfenster geschlossen wird. Dies führt zu einer "verlassenen" Sitzung im Laden. Wie kann ich diese effektiv beseitigen? Gibt es eine Möglichkeit, verlassene Sitzungen nach einem Zeitplan zu suchen und zu zerstören?
Zweitens habe ich die Mindestanforderungen für meinen Sitzungsladen wie auf dieser Seite beschrieben implementiert: Ссылка (in der Nähe) nach unten)
Das wäre erhalten, setzen und zerstören. Die anderen beiden empfohlenen Methoden sind Länge und Klarheit. Was genau sollten diese Methoden tun? Ich nehme an, Länge gibt die Länge der Zeit zurück, die eine Sitzung aktiv war. Wie ist "klar" anders als zerstören? Danke!
Wenn Sie nicht ein Ereignis auf dem Client eingerichtet haben, um den Server zu benachrichtigen, dass das Fenster geschlossen wird, kann der Server nicht wissen, dass die Sitzung nicht mehr verwendet wird.
Sie möchten über Sitzungen als zwei Teile geistig denken. Ein Teil ist das Token (das Cookie), das zwischen dem Knoten und dem Browser übergeben wird. Die zweite ist die tatsächliche Persistenz von Sitzungen in einem Geschäft (entweder der grundlegende MemoryStore oder Redis oder Ihr neuer Sitzungsspeicher für eine andere Datenbank). Der gesamte Verbindungssitzungs-Code tut dies mit jeder Anfrage zusammen.
Beachten Sie, dass Node die Sitzungsdaten nur dann im Speicher hat, wenn Sie den MemoryStore verwenden, während Ihre Anfrage darauf ausgeführt wird. (Nun, es wäre für eine Weile im Speicher, würde aber nicht referenziert und der Speicherbereinigung unterliegen). Wenn Sie über verschiedene Einsatzszenarien nachdenken, ist dies sinnvoll.
Der Job des serverseitigen Ablaufs von Sitzungen fällt somit in den Store selbst. Einer der Gründe, warum Redis dafür großartig ist, ist, dass es automatisch ablaufende Dinge verwaltet, die Sie sehen können connect-redis tut in seiner Set-Operation :
Sie können sehen, dass TTL durch 1000 geteilt wird, da es für seinen Ablauf Sekunden statt Millis verwendet. Der beliebtesten MongoDB Session Store verwendet die TTL-Funktion von MongoDB auf die gleiche Weise.
Es war also ein langer Weg, zu sagen, dass Sie sich entweder auf Ihre DB-Engine verlassen werden, um den Ablauf der Sitzungen auf der Serverseite automatisch bereitzustellen, oder Sie müssen die Ablaufzeit selbst implementieren. Sie könnten einen Prozess außerhalb Ihrer Knoten-App (möglicherweise ein anderer Knotenprozess) ausführen, der dies tut, oder Ihre Store-Implementierung könnte eine SetInterval-Task installieren, um sie regelmäßig zu überprüfen und zu bereinigen. Ein MySQL-basierter Session-Store zum Beispiel tut genau das.
Was machen length und clear im zweiten Teil Ihrer Frage? Der Kommentator ist der Ansicht, dass RedisStore diese nicht implementiert und sie können wahrscheinlich sicher ignoriert werden, aber Sie können ihre Implementierungen in der MemoryStore-Quellcode . Nicht zu aufregend.
clear leert alle Sitzungen und den Rückruf, wenn ein Rückruf bereitgestellt wird:
length ruft einfach mit der Anzahl der Sitzungen im Geschäft zurück:
Ich hoffe, das war hilfreich.