Was sind die technischen Vor- und Nachteile von localStorage
, sessionStorage
, Session und cookies
, und wann würde ich eines gegenüber dem anderen verwenden?
Antworten
Zu viele Anzeigen?Dies ist eine äußerst breite Fragestellung, und viele der Vor- und Nachteile werden im Kontext zur Situation stehen.
In allen Fällen sind diese Speichermechanismen spezifisch für einen einzelnen Browser auf einem einzelnen Computer/Gerät. Jede Anforderung, Daten über Sitzungen hinweg zu speichern, muss Ihren Anwendungsserver einbeziehen - höchstwahrscheinlich unter Verwendung einer Datenbank, aber möglicherweise auch XML oder einer Textdatei/CSV-Datei.
localStorage, sessionStorage und Cookies sind alle Client-Speicherlösungen. Sitzungsdaten werden auf dem Server gespeichert, wo sie unter Ihrer direkten Kontrolle bleiben.
localStorage und sessionStorage
localStorage und sessionStorage sind relativ neue APIs (was bedeutet, dass nicht alle veralteten Browser sie unterstützen werden) und sind fast identisch (sowohl in APIs als auch in Funktionen) mit der einzigen Ausnahme der Persistenz. sessionStorage (wie der Name schon sagt) steht nur für die Dauer der Browsersitzung zur Verfügung (und wird gelöscht, wenn das Tab oder Fenster geschlossen wird) - es überlebt jedoch Seitenneuladungen (Quelle DOM Storage guide - Mozilla Developer Network).
Offensichtlich, wenn die gespeicherten Daten permanent verfügbar sein müssen, ist localStorage gegenüber sessionStorage vorzuziehen - obwohl beachtet werden sollte, dass beide vom Benutzer gelöscht werden können, sodass Sie sich nicht darauf verlassen sollten, dass die Daten in beiden Fällen weiterhin vorhanden sind.
localStorage und sessionStorage sind ideal für das Speichern von nicht sensitiven Daten, die innerhalb von Client-Skripten zwischen Seiten benötigt werden (zum Beispiel: Präferenzen, Punktestände in Spielen). Die in localStorage und sessionStorage gespeicherten Daten können leicht vom Client/Browser aus gelesen oder geändert werden, daher sollten sie nicht zur Speicherung sensitiver oder sicherheitsrelevanter Daten in Anwendungen verwendet werden.
Cookies
Dies gilt auch für Cookies, die vom Benutzer problemlos manipuliert werden können, und Daten können auch im Klartext aus ihnen gelesen werden - wenn Sie also sensible Daten speichern möchten, ist die Sitzung wirklich Ihre einzige Option. Wenn Sie kein SSL verwenden, kann auch Cookie-Informationen während der Übertragung abgefangen werden, insbesondere in einem offenen WLAN.
Auf der positiven Seite können Cookies ein gewisses Maß an Schutz vor Sicherheitsrisiken wie Cross-Site Scripting (XSS)/Script-Injektion erhalten, indem ein HTTP only-Flag gesetzt wird, was bedeutet, dass moderne (unterstützende) Browser den Zugriff auf Cookies und Werte von JavaScript verhindern (dies verhindert auch, dass Ihr eigenes, legitimes JavaScript darauf zugreift). Dies ist besonders wichtig bei Authentifizierungscookies, die verwendet werden, um einen Token zu speichern, der Details des angemeldeten Benutzers enthält - wenn Sie eine Kopie dieses Cookies haben, dann werden Sie praktisch als dieser Benutzer betrachtet, und haben denselben Zugriff auf Daten und Funktionen wie der Benutzer.
Da Cookies für Authentifizierungszwecke und zur Speicherung von Benutzerdaten verwendet werden, werden alle für eine Seite gültigen Cookies vom Browser bei jeder Anfrage an dieselbe Domain an den Server gesendet - dies umfasst die ursprüngliche Seitenanfrage, alle nachfolgenden Ajax-Anfragen, alle Bilder, Stylesheets, Skripte und Schriftarten. Aus diesem Grund sollten Cookies nicht zum Speichern großer Informationsmengen verwendet werden. Der Browser kann auch Grenzen für die Größe von Informationen festlegen, die in Cookies gespeichert werden können. Typischerweise werden Cookies zur Speicherung von Identifizierungstoken für Authentifizierung, Sitzungen und Werbeverfolgung verwendet. Die Tokens sind in der Regel keine menschenlesbaren Informationen an sich, sondern verschlüsselte Bezeichner, die mit Ihrer Anwendung oder Datenbank verknüpft sind.
localStorage vs. sessionStorage vs. Cookies
In Bezug auf Funktionen erlauben Cookies, sessionStorage und localStorage nur die Speicherung von Zeichenketten - es ist möglich, primitive Werte implizit beim Setzen zu konvertieren (diese müssen nach dem Lesen zurückkonvertiert werden, um sie als ihren Typ zu verwenden), aber nicht Objekte oder Arrays (es ist möglich, sie zu JSON zu serialisieren, um sie mit den APIs zu speichern). Session-Speicher ermöglicht in der Regel das Speichern aller Primitiven oder Objekte, die von Ihrer Serverseiten-Sprache/Ihrem Framework unterstützt werden.
Client-seitig vs. Server-seitig
Da HTTP ein zustandsloses Protokoll ist, haben Webanwendungen keine Möglichkeit, einen Benutzer aus früheren Besuchen beim erneuten Besuch der Website zu identifizieren - Sitzungsdaten verlassen sich in der Regel auf ein Cookie-Token, um den Benutzer bei wiederholten Besuchen zu identifizieren (obwohl selten auch URL-Parameter für denselben Zweck verwendet werden können). Die Daten haben in der Regel eine gleitende Ablaufzeit (die bei jedem Besuch des Benutzers erneuert wird), und je nach Ihrem Server/Ihrem Framework werden die Daten entweder im Prozess gespeichert (d.h. die Daten gehen verloren, wenn der Webserver abstürzt oder neu gestartet wird) oder extern in einem Zustandsserver oder einer Datenbank. Dies ist auch notwendig bei Verwendung eines Webfarms (mehr als ein Server für eine bestimmte Website).
Da Sitzungsdaten vollständig von Ihrer Anwendung (serverseitig) gesteuert werden, ist dies der beste Ort für alles Sensible oder Sicherheitsrelevantes.
Der offensichtliche Nachteil von serverseitigen Daten ist die Skalierbarkeit - Serverressourcen werden für jeden Benutzer für die Dauer der Sitzung benötigt, und alle Daten, die clientseitig benötigt werden, müssen mit jeder Anfrage gesendet werden. Da der Server nicht weiß, ob ein Benutzer zu einer anderen Seite navigiert oder seinen Browser schließt, müssen die Sitzungsdaten nach einer bestimmten Zeit ablaufen, um zu verhindern, dass alle Serverressourcen von verlassenen Sitzungen belegt werden. Bei Verwendung von Sitzungsdaten sollten Sie sich daher der Möglichkeit bewusst sein, dass Daten abgelaufen und verloren gegangen sind, insbesondere auf Seiten mit langen Formularen. Sie gehen auch verloren, wenn der Benutzer seine Cookies löscht oder den Browser/das Gerät wechselt.
Einige Web-Frameworks/Entwickler verwenden versteckte HTML-Eingaben, um Daten von einer Formularseite auf eine andere zu übertragen, um das Ablaufen der Sitzung zu vermeiden.
localStorage, sessionStorage und Cookies unterliegen alle "same-origin" Regeln, was bedeutet, dass Browser den Zugriff auf die Daten auf die Domain begrenzen sollten, die die Informationen ursprünglich gesetzt hat.
Weitere Informationen zu Client-Speichertechnologien finden Sie unter Dive Into Html 5.
-
Pros:
- Web-Speicher kann vereinfacht als eine Verbesserung von Cookies angesehen werden, da es eine wesentlich größere Speicherkapazität bietet. Wenn wir uns den Mozilla-Quellcode ansehen, sehen wir, dass 5120KB (5MB, was 2,5 Millionen Zeichen entspricht, in Chrome) die Standard-Speichergröße für eine gesamte Domäne ist. Dadurch haben Sie deutlich mehr Platz zum Arbeiten als bei einem typischen 4KB-Cookie.
- Die Daten werden nicht für jede HTTP-Anfrage (HTML, Bilder, JavaScript, CSS usw.) an den Server zurückgesendet, was den Datenverkehr zwischen Client und Server reduziert.
- Die in localStorage gespeicherten Daten bleiben bestehen, bis sie explizit gelöscht werden. Gemachte Änderungen werden gespeichert und sind für alle aktuellen und zukünftigen Besuche auf der Website verfügbar.
Nachteile:
- Es funktioniert nach dem Same-Origin-Policy. Daher sind die gespeicherten Daten nur auf dem gleichen Ursprung verfügbar.
-
Pros:
- Verglichen mit anderen gibt es meines Wissens nichts.
Nachteile:
- Die 4K-Grenze bezieht sich auf den gesamten Cookie, einschließlich Name, Wert, Ablaufdatum usw. Um die meisten Browser zu unterstützen, sollte der Name unter 4000 Bytes und die Gesamtgröße des Cookies unter 4093 Bytes bleiben.
- Die Daten werden für jede HTTP-Anfrage (HTML, Bilder, JavaScript, CSS usw.) an den Server zurückgesendet, was den Datenverkehr zwischen Client und Server erhöht.
Typischerweise sind folgende Werte zulässig:
- 300 Cookies insgesamt
- 4096 Bytes pro Cookie
- 20 Cookies pro Domain
- 81920 Bytes pro Domain (Angenommen 20 Cookies maximaler Größe 4096 = 81920 Bytes.)
-
Pros:
- Es ist ähnlich wie
localStorage
. - Die Daten sind nicht persistent, d.h. die Daten sind nur pro Fenster (oder Tab in Browsern wie Chrome und Firefox) verfügbar. Die Daten sind nur während der Seitensitzung verfügbar. Gemachte Änderungen werden gespeichert und sind für die aktuelle Seite sowie für zukünftige Besuche auf der gleichen Registerkarte/dem gleichen Fenster verfügbar. Sobald die Registerkarte/das Fenster geschlossen wird, werden die Daten gelöscht.
Nachteile:
- Die Daten sind nur im Fenster/Tab verfügbar, in dem sie festgelegt wurden.
- Wie bei
localStorage
funktioniert es nach der Same-Origin-Policy. Daher sind die gespeicherten Daten nur auf dem gleichen Ursprung verfügbar.
- Es ist ähnlich wie
Checkout across-tabs - wie man die einfache Kommunikation zwischen Browser-Tabs unterschiedlicher Herkunft erleichtert.
OK, LocalStorage wie es genannt wird, ist der lokale Speicher für Ihren Browser, er kann bis zu 10MB speichern, SessionStorage tut dasselbe, aber wie der Name schon sagt, basiert es auf Sitzungen und wird nach dem Schließen Ihres Browsers gelöscht, kann auch weniger als LocalStorage speichern, z.B. bis zu 5MB, aber Cookies sind sehr kleine Daten, die im Browser gespeichert werden, die bis zu 4KB speichern können und sowohl über Server als auch über Browser darauf zugegriffen werden können...
Ich habe auch das untenstehende Bild erstellt, um die Unterschiede auf einen Blick zu zeigen:
Dies sind Eigenschaften des 'window'-Objekts in JavaScript, genau wie 'document' eine Eigenschaft des window-Objekts ist, das DOM-Objekte enthält.
Die Session Storage-Eigenschaft verwaltet einen separaten Speicherbereich für jede gegebene Ursprung, der für die Dauer der Seitensitzung verfügbar ist, d. h. solange der Browser geöffnet ist, einschließlich Seitenaktualisierungen und Wiederherstellungen.
Local Storage tut dasselbe, bleibt aber auch bestehen, wenn der Browser geschlossen und wieder geöffnet wird.
Sie können gespeicherte Daten wie folgt festlegen und abrufen:
sessionStorage.setItem('Schlüssel', 'Wert');
var data = sessionStorage.getItem('Schlüssel');
Gleiches gilt für localStorage.
- See previous answers
- Weitere Antworten anzeigen