it-swarm.com.de

Was ist der Unterschied zwischen localStorage, sessionStorage, session und cookies?

Was sind die technischen Vor- und Nachteile von localStorage, sessionStorage, session und cookies und wann würde ich eines übereinander verwenden?

472
Pank

Dies ist eine äußerst weit gefasste Frage, und viele Vor- und Nachteile hängen von der jeweiligen Situation ab.

In allen Fällen sind diese Speichermechanismen spezifisch für einen einzelnen Browser auf einem einzelnen Computer/Gerät. Wenn Sie Daten über mehrere Sitzungen hinweg kontinuierlich speichern möchten, muss dies auf der Seite Ihres Anwendungsservers erfolgen - höchstwahrscheinlich unter Verwendung einer Datenbank, möglicherweise jedoch von XML oder einer Text-/CSV-Datei.

localStorage, sessionStorage und Cookies sind Client-Speicherlösungen. Sitzungsdaten werden auf dem Server gespeichert, auf den Sie direkten Zugriff haben.

localStorage und sessionStorage

localStorage und sessionStorage sind relativ neue APIs (dh nicht alle älteren Browser unterstützen sie) und sind nahezu identisch (sowohl in APIs als auch in Funktionen), mit Ausnahme der Persistenz. sessionStorage ist (wie der Name schon sagt) nur für die Dauer der Browsersitzung verfügbar (und wird gelöscht, wenn die Registerkarte oder das Fenster geschlossen wird). Es übersteht jedoch das Neuladen von Seiten (source DOM-Speicherhandbuch - Mozilla Developer) Netzwerk ).

Wenn die von Ihnen gespeicherten Daten dauerhaft verfügbar sein müssen, ist localStorage dem sessionStorage vorzuziehen. Sie sollten jedoch beachten, dass beide Daten vom Benutzer gelöscht werden können, sodass Sie sich in beiden Fällen nicht auf das Fortbestehen von Daten verlassen sollten.

localStorage und sessionStorage eignen sich perfekt, um nicht vertrauliche Daten, die in Clientskripten benötigt werden, zwischen Seiten zu speichern (z. B. Einstellungen, Ergebnisse in Spielen). Die in localStorage und sessionStorage gespeicherten Daten können problemlos vom Client/Browser aus gelesen oder geändert werden. Daher sollten Sie sich nicht auf die Speicherung vertraulicher oder sicherheitsrelevanter Daten in Anwendungen verlassen.

Kekse

Dies gilt auch für Cookies. Diese können vom Benutzer geringfügig manipuliert werden, und Daten können auch im Klartext gelesen werden. Wenn Sie also vertrauliche Daten speichern möchten, ist die Sitzung wirklich Ihre einzige Option. Wenn Sie kein SSL verwenden, können Cookie-Informationen auch während der Übertragung abgefangen werden, insbesondere über ein offenes WLAN.

Positiv zu vermerken ist, dass Cookies einen gewissen Schutz vor Sicherheitsrisiken wie Cross-Site Scripting (XSS)/Skriptinjektion haben können, indem ein Nur-HTTP-Flag gesetzt wird. Dies 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 Authentifizierungs-Cookies, die zum Speichern eines Tokens verwendet werden, der Details des angemeldeten Benutzers enthält. Wenn Sie eine Kopie dieses Cookies haben, werden Sie in jeder Hinsicht Dieser Benutzer hat in Bezug auf die Webanwendung 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 an den Server gesendet, um jede Anfrage an dieselbe Domain - dies beinhaltet 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 die Größe der Informationen begrenzen, die in Cookies gespeichert werden können. In der Regel werden Cookies zum Speichern von Identifikationstoken für Authentifizierungs-, Sitzungs- und Werbeverfolgung verwendet. Die Token sind in der Regel keine für den Menschen lesbaren Informationen an sich, sondern verschlüsselte Kennungen, die mit Ihrer Anwendung oder Datenbank verknüpft sind.

localStorage vs. sessionStorage vs. Cookies

In Bezug auf Funktionen können Sie in Cookies, sessionStorage und localStorage nur Zeichenfolgen speichern. Bei der Einstellung können primitive Werte implizit konvertiert werden (diese müssen zurückkonvertiert werden, um sie nach dem Lesen als Typ zu verwenden), nicht jedoch Objekte oder Arrays (Es ist möglich, sie mit JSON zu serialisieren, um sie mithilfe der APIs zu speichern.) Mit dem Sitzungsspeicher können Sie im Allgemeinen alle Grundelemente oder Objekte speichern, die von Ihrer serverseitigen Sprache/Ihrem serverseitigen Framework unterstützt werden.

Client-Seite vs. Server-Seite

Da HTTP ein zustandsloses Protokoll ist, können Webanwendungen einen Benutzer bei der Rückkehr auf die Website nicht anhand früherer Besuche identifizieren. Die Sitzungsdaten basieren normalerweise auf einem Cookie-Token, mit dem der Benutzer für wiederholte Besuche identifiziert wird (obwohl selten URL-Parameter verwendet werden können) den gleichen Zweck). Daten haben in der Regel eine gleitende Ablaufzeit (wird bei jedem Besuch des Benutzers erneuert) und werden je nach Server/Framework entweder während des Vorgangs gespeichert (dh Daten gehen verloren, wenn der Webserver abstürzt oder neu gestartet wird) oder extern in ein Zustandsserver oder eine Datenbank. Dies ist auch erforderlich, wenn eine Webfarm verwendet wird (mehr als ein Server für eine bestimmte Website).

Da die Sitzungsdaten vollständig von Ihrer Anwendung (Serverseite) gesteuert werden, ist dies der beste Ort für alle sensiblen oder sicheren Objekte.

Der offensichtliche Nachteil von serverseitigen Daten ist die Skalierbarkeit: Für die Dauer der Sitzung sind für jeden Benutzer Serverressourcen erforderlich, und alle auf der Clientseite benötigten Daten müssen bei jeder Anforderung gesendet werden. Da der Server nicht wissen kann, ob ein Benutzer zu einer anderen Site navigiert oder ihren Browser schließt, müssen die Sitzungsdaten nach einer bestimmten Zeit verfallen, damit nicht alle Serverressourcen von abgebrochenen Sitzungen beansprucht werden. Wenn Sie Sitzungsdaten verwenden, sollten Sie sich daher der Möglichkeit bewusst sein, dass Daten abgelaufen sind und verloren gegangen sind, insbesondere auf Seiten mit langen Formularen. Es geht auch verloren, wenn der Benutzer seine Cookies löscht oder den Browser/das Gerät wechselt.

Einige Webframeworks/-entwickler verwenden versteckte HTML-Eingaben, um Daten von einer Seite eines Formulars zur nächsten zu speichern und das Ablaufen der Sitzung zu vermeiden.

localStorage, sessionStorage und Cookies unterliegen denselben Ursprungsregeln. Dies bedeutet, dass Browser den Zugriff auf die Daten mit Ausnahme der Domäne verhindern sollten, in der die Informationen festgelegt sind, mit denen sie beginnen.

Weitere Informationen zu Client-Speichertechnologien finden Sie unter Dive Into Html 5 .

655
pwdst
  1. LocalStorage

    Vorteile :

    1. Der Webspeicher kann vereinfacht als Verbesserung von Cookies angesehen werden und bietet eine viel größere Speicherkapazität. Wenn Sie sich den Mozilla-Quellcode ansehen, sehen Sie, dass 5120 KB ( 5 MB sind, was 2,5 Millionen entspricht Zeichen in Chrome) ist die Standardspeichergröße für eine gesamte Domain. Dadurch haben Sie erheblich mehr Platz zum Arbeiten als bei einem typischen 4-KB-Cookie.
    2. Die Daten werden nicht bei jeder HTTP-Anforderung (HTML, Bilder, JavaScript, CSS usw.) an den Server zurückgesendet, wodurch der Datenverkehr zwischen Client und Server verringert wird.
    3. Die in localStorage gespeicherten Daten bleiben so lange erhalten, bis sie explizit gelöscht werden. Die vorgenommenen Änderungen werden gespeichert und stehen für alle aktuellen und zukünftigen Besuche der Website zur Verfügung.

    Nachteile :

    1. Es funktioniert mit Same-Origin-Richtlinie . Die gespeicherten Daten sind also nur in demselben Ursprung verfügbar.
  2. Cookies

    Vorteile:

    1. Im Vergleich zu anderen gibt es nichts AFAIK.

    Nachteile:

    1. Die Beschränkung auf 4 KB gilt für das gesamte Cookie, einschließlich Name, Wert, Ablaufdatum usw. Um die meisten Browser zu unterstützen, sollten Sie den Namen unter 4000 Byte und die Gesamtgröße der Cookies unter 4093 Byte halten.
    2. Die Daten werden bei jeder HTTP-Anforderung (HTML, Bilder, JavaScript, CSS usw.) an den Server zurückgesendet, wodurch der Datenverkehr zwischen Client und Server erhöht wird.

      In der Regel ist Folgendes zulässig:

      • Insgesamt 300 Cookies
      • 4096 Bytes pro Cookie
      • 20 Cookies pro Domain
      • 81920 Bytes pro Domain (Bei 20 Cookies mit einer maximalen Größe von 4096 = 81920 Bytes.)
  3. sessionStorage

    Vorteile:

    1. Es ist ähnlich wie localStorage.
    2. Die Daten sind nicht persistent, d. H., Daten sind nur pro Fenster (oder Tabulator in Browsern wie Chrome und Firefox) verfügbar. Daten sind nur während der Seitensitzung verfügbar. Die vorgenommenen Änderungen werden gespeichert und stehen für die aktuelle Seite sowie für zukünftige Besuche der Site im selben Fenster zur Verfügung. Sobald das Fenster geschlossen ist, wird der Speicher gelöscht.

    Nachteile:

    1. Die Daten sind nur in dem Fenster/Reiter verfügbar, in dem sie eingestellt wurden.
    2. Wie localStorage funktioniert es mit Same-Origin-Richtlinie . Die gespeicherten Daten sind also nur in demselben Ursprung verfügbar.

Checkout tabellenübergreifend - wie Sie die Kommunikation zwischen den Registerkarten des Cross-Origin-Browsers vereinfachen können.

56
softvar

OK, LocalStorage , wie es als lokaler Speicher für Ihre Browser bezeichnet wird, kann bis zu 10 MB , speichern ) SessionStorage macht dasselbe, aber wie der Name schon sagt, ist es sitzungsbasiert und wird nach dem Schließen Ihres Browsers gelöscht. Es kann auch weniger als LocalStorage speichern, wie bis zu 5MB , aber Cookies sind sehr kleine Daten, die in Ihrem Browser gespeichert werden. Sie können bis zu 4 KB speichern und über den Server oder abgerufen werden Browser sowohl ...

Ich habe auch das Bild unten erstellt, um die Unterschiede auf einen Blick zu zeigen:

LocalStorage, SessionStorage and Cookies

37
Alireza

Dies sind Eigenschaften von 'window'-Objekten in JavaScript, genau wie document eine Eigenschaft von window-Objekten ist, die DOM-Objekte enthält.

Die Eigenschaft "Sitzungsspeicher" verwaltet für jeden Origin einen separaten Speicherbereich, der für die Dauer der Seitensitzung verfügbar ist, d. H. Solange der Browser geöffnet ist, einschließlich des erneuten Ladens und Wiederherstellens von Seiten.

Local Storage macht dasselbe, bleibt jedoch auch dann bestehen, wenn der Browser geschlossen und erneut geöffnet wird.

Sie können gespeicherte Daten wie folgt einstellen und abrufen:

sessionStorage.setItem('key', 'value');

var data = sessionStorage.getItem('key');

Ähnliches gilt für localStorage.

23
Prashant_M

Lokaler Speicher: Die Benutzerdaten werden ohne Ablaufdatum gespeichert. Diese Daten werden nicht gelöscht, wenn der Benutzer die Browserfenster schließt. Sie sind für Tag, Woche, Monat und Jahr verfügbar.

Im lokalen Speicher können 5-10 MB Offline-Daten gespeichert werden.

//Set the value in a local storage object
localStorage.setItem('name', myName);

//Get the value from storage object
localStorage.getItem('name');

//Delete the value from local storage object
localStorage.removeItem(name);//Delete specifice obeject from local storege
localStorage.clear();//Delete all from local storege

Sitzungsspeicherung: Dies entspricht dem lokalen Speicherdatum, mit der Ausnahme, dass alle Fenster gelöscht werden, wenn Browserfenster von einem Webbenutzer geschlossen werden.

Im Sitzungsspeicher können bis zu 5 MB Daten gespeichert werden

//set the value to a object in session storege
sessionStorage.myNameInSession = "Krishna";

Sitzung: Eine Sitzung ist eine globale Variable, die auf dem Server gespeichert ist. Jeder Sitzung wird eine eindeutige ID zugewiesen, mit der gespeicherte Werte abgerufen werden.

Cookies: Cookies sind Daten, die in kleinen Textdateien als Name-Wert-Paare auf Ihrem Computer gespeichert werden. Sobald ein Cookie gesetzt wurde, geben alle folgenden Seitenanforderungen den Namen und den Wert des Cookies zurück.

2
Srikrushna

Die Web-Speicher-API bietet Mechanismen, mit denen Browser Schlüssel/Wert-Paare sicherer speichern können als mit Cookies. Die Web Storage API erweitert das Objekt Window um zwei neue Eigenschaften - _Window.sessionStorage_ und _Window.localStorage_. - Wenn Sie eine dieser Optionen aufrufen, wird eine Instanz des Speicherobjekts erstellt, über die Datenelemente festgelegt, abgerufen und entfernt werden können. Für sessionStorage und localStorage wird für jeden Ursprung (Domäne) ein anderes Speicherobjekt verwendet.

Speicherobjekte sind einfache Schlüsselwertspeicher , ähnlich wie Objekte , bleiben jedoch beim Laden von Seiten erhalten.

_localStorage.colorSetting = '#a4509b';
localStorage['colorSetting'] = '#a4509b';
localStorage.setItem('colorSetting', '#a4509b');
_

Die Schlüssel und die Werte sind immer Zeichenfolgen . Zum Speichern eines beliebigen Typs convert it to String und dann speichern. Es wird immer empfohlen, Storage interface zu verwenden.

_var testObject = { 'one': 1, 'two': 2, 'three': 3 };
// Put the object into storage
localStorage.setItem('testObject', JSON.stringify(testObject));
// Retrieve the object from storage
var retrievedObject = localStorage.getItem('testObject');
console.log('Converting String to Object: ', JSON.parse(retrievedObject));
_

Die beiden Mechanismen in Web Storage lauten wie folgt:

  • sessionStorage verwaltet einen separaten Speicherbereich für jeden angegebenen OriginSame-Origin-Richtlinie Dies ist für die Dauer der Seitensitzung verfügbar (solange der Browser geöffnet ist, einschließlich des erneuten Ladens und Wiederherstellens von Seiten).
  • localStorage macht dasselbe, bleibt aber bestehen, auch wenn der Browser geschlossen und wieder geöffnet wird.

Speicher " Lokaler Speicher schreibt die Daten auf die Festplatte, während der Sitzungsspeicher nur die Daten in den Speicher schreibt. Alle Daten, die in den Sitzungsspeicher geschrieben werden, werden beim Beenden Ihrer App gelöscht.

Der maximal verfügbare Speicher ist je nach Browser unterschiedlich , aber die meisten Browser haben mindestens das von w3c empfohlene maximale Speicherlimit von 5 MB implementiert.

_+----------------+--------+---------+-----------+--------+
|                | Chrome | Firefox | Safari    |  IE    |
+----------------+--------+---------+-----------+--------+
| LocalStorage   | 10MB   | 10MB    | 5MB       | 10MB   |
+----------------+--------+---------+-----------+--------+
| SessionStorage | 10MB   | 10MB    | Unlimited | 10MB   |
+----------------+--------+---------+-----------+--------+
_

Fangen Sie immer die LocalStorage-Sicherheit ab, und das Kontingent hat die Fehler überschritten

StorageEvent ​​"Das Speicherereignis wird für das Window-Objekt eines Dokuments ausgelöst, wenn sich ein Speicherbereich ändert. Wenn ein Benutzeragent eine Speicherbenachrichtigung für ein Dokument senden soll, muss der Benutzeragent eine Task in die Warteschlange stellen, um mit StorageEvent ein Ereignis mit dem Namen storage auf dem Window-Objekt des Dokumentobjekts auszulösen.

Hinweis: Ein Beispiel aus der Praxis finden Sie unter Web Storage Democheck out the source code

Hören Sie sich das Speicherereignis auf dom/Window an, um Änderungen im Speicher zu erfassen. Geige .


Cookies (Web-Cookie, Browser-Cookie) Cookies sind Daten, die in kleinen Textdateien als Name-Wert-Paare auf Ihrem Computer gespeichert werden Computer.

JavaScript-Zugriff über Document.cookie

Neue Cookies können auch über JavaScript mit der Eigenschaft Document.cookie erstellt werden. Wenn das HttpOnly-Flag nicht gesetzt ist, kann auch über JavaScript auf vorhandene Cookies zugegriffen werden.

_document.cookie = "yummy_cookie=choco"; 
document.cookie = "tasty_cookie=strawberry"; 
console.log(document.cookie); 
// logs "yummy_cookie=choco; tasty_cookie=strawberry"
_

Sichere und nur HTTP-Cookies HTTP-Statusverwaltungsmechanismus

Cookies werden häufig in Webanwendungen verwendet, um einen Benutzer und seine authentifizierte Sitzung zu identifizieren

Beim Empfang einer HTTP-Anfrage kann ein Server einen Set-Cookie Header mit der Antwort senden. Das Cookie wird normalerweise vom Browser gespeichert. Anschließend wird das Cookie mit Anfragen an denselben Server in einem Cookie-HTTP-Header gesendet.

_Set-Cookie: <cookie-name>=<cookie-value> 
Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>
_

Sitzungscookies werden entfernt, wenn der Client heruntergefahren wird. Sie geben weder die Expires- noch die Max-Age-Richtlinie an.

_Set-Cookie: sessionid=38afes7a8; HttpOnly; Path=/
_

Permanente Cookies verfallen zu einem bestimmten Datum (Expires) oder nach einer bestimmten Zeitspanne (Max-Age).

_Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
_

Der HTTP-Anforderungsheader für Cookies enthält gespeicherte HTTP-Cookies, die zuvor vom Server mit dem Set-Cookie-Header gesendet wurden. Über die Eigenschaft Document.cookie, die API XMLHttpRequest und die API Request können Cookies nur über HTTP nicht über JavaScript aufgerufen werden, um Angriffe auf Cross-Site-Scripting (XSS) abzuschwächen.

Cookies werden hauptsächlich für drei Zwecke verwendet:

  • Sitzungsverwaltung "Logins, Einkaufswagen, Spielergebnisse oder alles, woran sich der Server erinnern sollte
  • Personalisierung "Benutzereinstellungen, Themen und andere Einstellungen
  • Tracking (Aufzeichnung und Analyse des Nutzerverhaltens) "Cookies sind mit einer Domain verbunden. Wenn diese Domain mit der Domain der Seite übereinstimmt, auf der Sie sich befinden, handelt es sich bei den Cookies um ein Erstanbieter-Cookie. Wenn sich die Domain unterscheidet, handelt es sich um ein Cookie eines Drittanbieters. Während Erstanbieter-Cookies nur an den Server gesendet werden, der sie einstellt, kann eine Webseite Bilder oder andere Komponenten enthalten, die auf Servern in anderen Domänen gespeichert sind (z. B. Werbebanner). Cookies, die über diese Komponenten von Drittanbietern gesendet werden, werden als Drittanbieter-Cookies bezeichnet und hauptsächlich für Werbung und Tracking im Internet verwendet.

Cookies wurden erfunden, um das Problem zu lösen, "wie Informationen über den Benutzer gespeichert werden":

  • Wenn ein Benutzer eine Webseite besucht, kann sein Name in einem Cookie gespeichert werden.
  • Wenn der Benutzer das nächste Mal die Seite besucht, werden der Anforderung Cookies hinzugefügt, die zur Seite gehören. Auf diese Weise erhält der Server die erforderlichen Daten, um Informationen über Benutzer zu speichern.

GitHubGist Beispiel


Als Zusammenfassung

  • localStorage bleibt über verschiedene Registerkarten oder Fenster hinweg bestehen, und selbst wenn wir den Browser schließen, werden die Sicherheitsrichtlinien für die Domäne und die Benutzeroptionen für das Kontingentlimit entsprechend angepasst.
  • das sessionStorage-Objekt bleibt nicht erhalten, wenn wir die Registerkarte schließen (Browserkontext der obersten Ebene), da es nicht vorhanden ist, wenn wir über eine andere Registerkarte oder ein anderes Fenster surfen.
  • Durch die Speicherung im Web (Sitzung, lokal) können wir eine große Menge von Schlüssel/Wert-Paaren und viel Text speichern, was mit Cookies nicht möglich ist.
  • Cookies, die für sensible Aktionen verwendet werden, sollten nur eine kurze Lebensdauer haben.
  • Cookies, die hauptsächlich für Werbung und Tracking im Internet verwendet werden. Siehe zum Beispiel Arten von Cookies, die von Google verwendet werden .
  • Cookies werden bei jeder Anfrage gesendet, um die Leistung zu beeinträchtigen (insbesondere bei mobilen Datenverbindungen). Moderne APIs für den Client-Speicher sind die Web-Speicher-API (localStorage und sessionStorage) und IndexedDB.
2
Yash

LocalStorage:

  • Der Webspeicher kann vereinfacht als Verbesserung von Cookies angesehen werden und bietet eine viel größere Speicherkapazität. Die verfügbare Größe beträgt 5 MB, was erheblich mehr Platz zum Arbeiten bietet als ein typisches 4-KB-Cookie.

  • Die Daten werden nicht bei jeder HTTP-Anforderung (HTML, Bilder, JavaScript, CSS usw.) an den Server zurückgesendet, wodurch der Datenverkehr zwischen Client und Server verringert wird.

  • Die in localStorage gespeicherten Daten bleiben so lange erhalten, bis sie explizit gelöscht werden. Die vorgenommenen Änderungen werden gespeichert und stehen für alle aktuellen und zukünftigen Besuche der Website zur Verfügung.

  • Es funktioniert mit derselben Origin-Richtlinie. Die gespeicherten Daten sind also nur in demselben Ursprung verfügbar.

Cookies:

  • Wir können die Ablaufzeit für jedes Cookie festlegen

  • Die Beschränkung auf 4 KB gilt für das gesamte Cookie, einschließlich Name, Wert, Ablaufdatum usw. Um die meisten Browser zu unterstützen, sollten Sie den Namen unter 4000 Byte und die Gesamtgröße der Cookies unter 4093 Byte halten.

  • Die Daten werden bei jeder HTTP-Anforderung (HTML, Bilder, JavaScript, CSS usw.) an den Server zurückgesendet, wodurch der Datenverkehr zwischen Client und Server erhöht wird.

sessionStorage:

  • Es ähnelt localStorage.
  • Änderungen sind nur in Fenstern (oder Registerkarten in Browsern wie Chrome und Firefox) verfügbar. Die vorgenommenen Änderungen werden gespeichert und stehen für die aktuelle Seite sowie für zukünftige Besuche der Site im selben Fenster zur Verfügung. Sobald das Fenster geschlossen ist, wird der Speicher gelöscht. Die Daten sind nur in dem Fenster/Register verfügbar, in dem sie eingestellt wurden.

  • Die Daten sind nicht persistent, d. H. Sie gehen verloren, sobald das Fenster/die Registerkarte geschlossen wird. Wie localStorage funktioniert es mit derselben Origin-Richtlinie. Die gespeicherten Daten sind also nur in demselben Ursprung verfügbar.

0
Developer