Warum erinnerst du dich an mich Token?

Question

Während der Implementierung der "Remember Me" -Funktion für eine Website komplizieren wir die Dinge und haben einen Token namens Remember Me Token, abgesehen von einem Sitzungs -Token.

Denken Sie nach meinem Verständnis daran, dass Token verwendet werden kann, um sich anzumelden und ein neues Sitzungs -Token zu erstellen, während das Sitzungs -Token nur einige Minuten dauert oder bis zum Schließen des Browsers der Benutzer. Warum können wir die Ablaufdauer des Sitzungs -Tokens nicht auf die gewünschte Zeit erhöhen, bis der Benutzer angemeldet wird?

Ich muss eine solche Funktionalität in einer Flexbasis implementieren, die über Tomcat ausgeführt wird, und ich frage mich, ob ich mich an mich erinnere, um mich zu erinnern

Ist es auch möglich, diese Funktionalität in Tomcat aus dem Box zu bringen?

Answer 1

1) Sitzungen enthalten normalerweise eine ganze Reihe anderer Daten als den Anmeldenamen des Benutzers. Wenn Sie also das Ablaufdatum auf ein paar Wochen oder Monate festlegen, wie ein Token, würden Sie wahrscheinlich aufgrund von Tausenden oder Millionen von Schwergewichts -Sitzungsobjekten auf Leistungsprobleme auf dem Server stoßen.

2) Denken Sie daran, dass Token clientseitig und nicht serverseitig sind. Dies stellt alle Speicheranforderungen für den Browser des Benutzers ein, was eine bessere Lösung für einfache Daten wie Anmeldeamen ist. Wenn Sie sich auf die Sitzungs-ID angewiesen hätten, die mit In-Memory-Objekten auf dem Server verknüpft sind, würden Sie jedes Mal, wenn Sie Ihren Server oder den Serverprozess neu starten (um beispielsweise eine aktualisierte Anwendung bereitzustellen), alle diese Sitzungsobjekte verloren gehen.

Answer 2

Weil per Definition eine Sitzung endet, sobald der Benutzer seinen Browser schließt. So läuft der Sitzungs -Cookie aus, sobald der Browser geschlossen ist.

Da der Zweck der Funktionalität von Erinnerungs-ME darin besteht, den Benutzer über Sitzungen hinweg angemeldet zu halten, müssen die im Remember-Me-Cookie gespeicherten Informationen über Browser-Neustarts hinweg bestehen bleiben.

Um diese Funktionalität "aus der Box" herauszuholen, sehen Sie sich ein Framework an. wie Frühlingssicherheit.

Answer 3

Denken Sie an-Me-Kekse normalerweise den Benutzernamen und eine Art Token auf. Beide werden verwendet, um den Benutzer zu authentifizieren. Sich ansehen Verbesserte anhaltende Login -Cookie Best Practice Das beschreibt den Prozess ziemlich gut.

Das Sitzungs -Cookie wird verwendet, um eine Sitzungs -ID auf dem Client zu speichern, mit der der Server eine Sitzung erkennen kann, die die Sitzungsdaten laden, die der Sitzung zugeordnet sind.

Denken Sie also daran, dass Sie Kekse haben, eine längere Lebensdauer (normalerweise Tage oder Wochen) als Sitzungskekse. Sitzungskekse verfallen normalerweise nach wenigen Minuten oder wenn der Browser geschlossen ist.

Aus meinem Kopf gibt es einige Gründe, warum zwei verschiedene Kekse verwendet werden:

• Wenn nur der persistente Remin-Me-Cookie verwendet würde, müsste der Server den Benutzer mit jeder Anfrage authentifizieren. Wenn ein zusätzlicher Sitzungs -Cookie verwendet wird, muss der Server dies nicht tun, solange die Sitzung gültig ist. Natürlich könnte die Sitzungs-ID im Remin-Me-Cookie gespeichert werden, aber was ist der Sinn, das zu tun?
• Aus Sicht der Kodierung ist es besser, den bestehenden Sitzungsmechanismus wiederzuverwenden. Warum das Rad neu erfinden, anstatt nur eine Funktion (Authentifizierung über Remin-Me Cookie) hinzuzufügen, die leicht aktiviert/deaktiviert werden kann?

Answer 4

Die Leute haben richtig gesagt, dass die Sitzung eine Reihe von Objekten mit schwerem Gewicht enthält. Wenn Sie mit genügend Benutzern in Ihrem System versuchen, sie alle in der begrenzten Menge an Speicher zu halten, die der Server hat, werden Sie schließlich den Server ab Abstürzen, wenn dieser Speicher -Maximal ausgeht.

Ich habe einmal an einem Projekt gearbeitet, bei dem ein Produktionscode -Update ein Speicherleck hatte. Es war ein J2EE -Projekt (ja J2EE nicht Java EE). Als sich ein Benutzer angemeldet hat, um seine Rechnung in dieser Telefongesellschaft zu überprüfen, wurde die Benutzersitzung nicht ordnungsgemäß aus dem Speicher veröffentlicht (ich kann mich nicht an die Ursache erinnern, aber das war definitiv das Problem). Dieser Fehler ahmt nach, was Sie absichtlich tun.

Der Server stürzte immer wieder ab. Also legen wir einen Profiler darauf. Wir würden beobachten, wie der Speicher verwendet wird, bis der Tag nach dem Sturz des App -Servers nachging und Shorty nachgieb. Wir haben den Speicher hinzugefügt und die VM -Speichereinstellung erhöht. Ich sagte ihnen, es sei ein Speicherleck, aber weil ich kein 200,00 Dollar pro Stunde lang war, wollten die Leute es nicht glauben, weil die Leute, die dort waren, immer noch glaubten, dass der Müllsammler alle mächtig war, anstatt nur sehr gut zu sein.

Zwei Tage später (es wirkte sich auf das System "Sehen Sie sich Ihre Rechnung anzeigen", nicht das Hauptgeschäftssystem, dh es hatte nicht die gleiche Workload- oder Speicheranforderungen, obwohl es auf den Servern viel Hardwarespeicher hatte), sie stellten ein paar ein paar Anforderungen an Berater von 200,00 USD pro Stunde, die ihnen nach einem Tag mitgeteilt wurden, dass die App das oben genannte Speicherleck hatte. Es war fixiert und alles war gut ... abzüglich der Beratergebühren.

Auf jeden Fall ist hier die Ausnahme davon: Wenn Sie keine Benutzersitzungen beenden, wenn sich Benutzer anmelden oder ihren Browser schließen (Sitzungszeit), führen Sie ein echtes Risiko ein, Ihren Speicher zu maximieren und Ihre Server zu stürzen. Insbesondere wenn Ihre Website oder App eine erhebliche Anzahl von Benutzern hat. Wie von anderen erwähnt, sind leichte Token/Cookies am besten.

Answer 5

Der Grund dafür, warum wir ein anderes Cookie als das SessionID -Cookie verwenden sollten, um sich an den Benutzer zu erinnern, ist nicht, dass Sitzungen schnell ablaufen oder auf dem Server Leistungsprobleme konfrontiert werden.

Jetty (und wahrscheinlich viele andere Servlet -Container) verfügt über eine Funktion, die die automatische Räumung von Leerlaufsitzungen von Speicher zu Festplatte oder Datenbank ermöglicht, die IMHO alle oben genannten Begründungen in Bezug auf Leistungsprobleme ausschließen, die mit dem Speichern von Schwergewichtssitzungen im Speicher geliefert werden.

Der Grund, warum ein anderer Cookie verwendet wird, ist, dass Remember-Me darin besteht, sich an den Benutzer zu erinnern, auch nachdem die Sitzung abgelaufen ist. Wenn die Sitzung des Benutzers abgelaufen ist, wird der andere Cookie verwendet, um den Benutzer zu authentifizieren, ohne dass er ein Kennwort eingeben muss, was die Phishing -Angriffe offensichtlich weniger wahrscheinlich macht. Obwohl es auch Nachteile gibt, wenn beispielsweise jemand Zugriff auf Ihren Laptop erhält und Ihre Authentifizierungs -Token stiehlt, könnte Sie in der Lage sein, Sie auszugeben, es sei denn, der Server wendet noch mehr Sicherheitsmaßnahmen an, um das Token nur an Ihren Kunden und den Standort zu binden.

Kurz gesagt, Remember-Me ist ein Authentifizierungsmechanismus und kein Ersatz für Sitzungs Cookies.

Ich glaube, es ist in Ordnung, langfristige Ablaufdaten für Sitzungen zu haben, solange sie aus dem Gedächtnis gespeichert sind. Und sobald sie ablaufen, fragen Sie einfach nach Passwort. Viele Websites bieten diese Funktion als "Erinnere dich für 30 Tage", was nur mit einem langfristigen Sessionid -Cookie erreicht wird, sonst nichts.