SELF-Treffen in Mannheim 2025

SELFHTML wird 30 Jahre alt!
Die Mitgliederversammlung findet am 24.05.2025 um 10:00 statt. Alle Mitglieder und Interessierte sind herzlich eingeladen.
Davor und danach gibt es Gelegenheiten zum gemütlichen Beisammensein. → Veranstaltungs-Ankündigung.

Web Storage

Aus SELFHTML-Wiki
(Weitergeleitet von Benutzer:Rolf b/WebStorage)
Wechseln zu: Navigation, Suche

Die Web Storage API ist ein Teil der HTML Spezifikation und ermöglicht es, im Browser Daten so zu speichern, dass sie auch nach dem Verlassen einer Seite noch zur Verfügung stehen. Man unterscheidet zwischen Local Storage, der auch nach dem Schließen des Browsers erhalten bleibt, und Session Storage, der nach dem Schließen eines Tabs gelöscht wird.[1]

Beide Speicherorte sind in über Eigenschaften des window-Objekts erreichbar, die in allen aktuellen Browsern verfügbar sind und sogar schon im Internet Explorer bekannt waren:

window.localStorage
liefert das Storage-Objekt des Local Storage
window.sessionStorage
liefert das Storage-Objekt des Session Storage

Beide Speicherorte sind nur auf dem window-Objekt (bzw. im globalen Scope eines Browser-Dokuments) zu finden, in Workern dagegen nicht.

Im Zusammenhang mit Web Storage findet man auch das Storage API. Dieses beschäftigt sich mit dem Speichermanagement, das den zuvor genannten Speichermöglichkeiten zu Grunde liegt, und ist ziemlich abstrakt. Wir werden es in diesem Artikel nur insoweit streifen, wie es zum Verständnis von Web Storage erforderlich ist.

In der Storage Spezifikation finden sich Quota (Größenbeschränkungen) für local und session storage von jeweils 5 MeBiByte (5 × 220 Bytes). Wenn Sie diese Quota überschreiten, wird der Browser eine DOMException auslösen.

Beachte: Wenn etwa eine Permission Policy gesetzt wird, die nicht allow="storage-access" führt, dann wird der Browser den Zugriff auf localStorage mit einem Fehler quittieren.[2]

Das Storage Objekt

Der Local Storage und der Session Storage werden durch ein Storage-Objekt realisiert. Der Browser stellt für jeden Origin ein Local Storage Objekt bereit, und für jeden Browser-Tab, in dem eine Seite dieses Origins geöffnet wird, ein Session Storage Objekt. Diese beiden Objekte sind unabhängig voneinander.

Pro Origin bedeutet, dass sich alle HTML Dokumente, bei denen die URL-Anteile Schema, Hostname und Port übereinstimmen, einen Local Storage teilen. Wenn Sie auf einem geöffneten Browser-Tab zwischen mehreren Seiten wechseln, bei denen der Origin übereinstimmt, ist auch der Session Storage der gleiche. Wenn Sie eine Seite des gleichen Origin in einem anderen Tab öffnen, erhalten Sie einen anderen Session Storage. Wenn Sie den Tab schließen, wird der Session Storage gelöscht.

Sie können Storage-Objekte dazu benutzen, Daten in Form von Schlüssel-Wert (key-value) Paaren abzulegen. Sowohl Schlüssel als auch Wert müssen eine Zeichenkette sein. Das Storage-Objekt bietet dazu folgende Methoden an. Ausführlichere Informationen und einfache Beispiele finden Sie im zugehörigen Referenzartikel zum Storage-Objekt.

getItem(key)
Wert zum Schlüssel lesen.
setItem(key, value)
Wert unter dem angegebenen Schlüssel speichern
length
Diese Eigenschaft liefert die Anzahl der im Storage abgelegten Schlüssel
key(n)
Gibt den Namen des n-ten Schlüssels zurück, unter dem Daten abgelegt sind
removeItem(key)
Entfernt den Eintrag zum übergebenen Schlüssel
clear()
Löscht alle Einträge

Wenn Sie mit setItem einen Wert speichern, finden Sie den verwendeten Key danach auch als Eigenschaft des Storage-Objekts vor. In der HTML Spezifikation ist auch vorgesehen, dass der Aufruf von storage.setItem(key, value) gleichbedeutend sein soll mit storage[key] = value. Dieses „Feature“ ist aber eine ziemlich schlechte Idee. Stellen Sie sich vor, Sie möchten einen Wert unter dem Schlüssel "length" oder "clear" speichern. Wenn Sie das mit storage['clear'] = 'Hallo selfhtml' tun, dann haben Sie die vom Storage-Prototypen bereitgestellte clear-Methode verdeckt. Mit storage.setItem('clear', 'Hallo') passiert Ihnen das nicht.

Empfehlung: Verwenden Sie immer die Zugriffsmethoden, um Storage-Elemente zu lesen, zu schreiben oder zu löschen, um nicht mit geerbten Namen von Eigenschaften oder Methoden kollidieren zu können.
Beachten Sie: Wenn Sie als Schlüssel oder Wert etwas angeben, das kein String ist, konvertiert das API diesen Wert in einen String. Dazu verwendet es die toString()-Methode, die jedes JavaScript-Objekt besitzt. Aus einem Array entsteht so eine kommaseparierte Liste, aus einem Objekt einfach nur "[object Object]". Verwenden Sie JSON.stringify(), um Arrays oder Objekte in einen JSON-String zu konvertieren, den Sie nachher mit JSON.parse() wieder in ein Array oder Objekt umwandeln können.

Speicherüberlastung

Man spricht von Speicherüberlastung (storage pressure), wenn die Gesamtmenge aller Local Storage Daten, die sich im Browser ansammeln, die vom Browserhersteller vorgesehene Höchstmenge überschreitet. Beispielsweise könnte ein Browserhersteller festlegen, dass sein Browser keine Benutzerdaten mehr speichern soll, wenn die Festplattte, auf der sie liegen, zu mehr als 90% gefüllt ist.

Um die Speicherüberlastung zu beheben, kann der Browser den Local Storage von einigen Origins verwerfen. Die HTML Spezifikation besagt, dass er das so tun soll, dass der Einfluss auf den Benutzer möglichst gering ist - konkret bedeutet das, dass der Local Storage der am längsten nicht mehr besuchten Origins verworfen wird.

Ein solches Verwerfen kann unangenehme Folgen haben. Deshalb kann eine Webseite vom Browser verlagen, die lokalen Daten ihres Origins bei Speicherüberlastung nicht zu entfernen. Dazu dient die Methode persist, die von dem StorageManager Objekt bereitgestellt wird, das Sie über window.navigator.storage erhalten.

Hinweis:
Die Spezifikation erwähnt nicht, wie man den Persistenzmodus wieder löscht. Überlegen Sie gut, ob die lokal gespeicherten Daten Ihrer Seite tatsächlich auch bei Speicherüberlastung erhalten bleiben müssen.

Datensicherheit

Wenn Sie personenbezogene Daten speichern, müssen Sie die Benutzer immer darüber informieren, was Sie speichern und warum Sie es tun. Sie müssen dem Benutzer die Möglichkeit geben, die Speicherung abzulehnen, und es muss auch die Möglichkeit geben, diese Daten zu löschen, wenn der Benutzer es fordert.

Ohne Einwilligung speichern dürfen Sie Daten, die nicht personenbezogen sind, oder ohne die Sie die vom Benutzer gewünschte Leistung nicht erbringen können. Soweit solche Daten personenbezogen sind, müssen Sie darüber aber informieren und müssen dem Benutzer die Möglichkeit geben, auf die Datenspeicherung und damit auf die Dienstleistung zu verzichten. Eine Speicherungserlaubnis ohne Rückfrage gibt es auch beim sogenannten „legitimen Interesse“ des Dienstanbieters - einen Begriff, den wir hier im Wiki nicht detailliert auslegen können.

Wenn Sie personenbezogene Daten, beispielsweise mit PHP, auf Ihrem Server speichern, hat das den Vorteil, dass Sie diese Daten auch verarbeiten können, ohne dass der Benutzer online ist. Und sie stehen dem Benutzer von überall zur Verfügung. Für Kundendaten und den Warenkorb eines Webshops ist das kaum vermeidbar. Es bedeutet aber auch, dass Sie zügig aktiv werden müssen, wenn Sie eine Löschforderung bekommen. Für eine serverseitige Speicherung benötigen Sie auch eine Benutzerverwaltung mit sicherem Login, und natürlich eine DSGVO-konforme Arbeitsweise.

Web Storage hat hier den Vorteil, dass die Daten auf dem Computer des Nutzers bleiben und er die Kontrolle über seine Daten behält. Aber sie können eben auch nur auf genau dem Computer verarbeitet werden, wo sie gespeichert sind, bzw. Ihre Website muss die Daten, wenn sie am Server benötigt werden, dorthin übertragen. Hinzu kommt, dass die im Browser gespeicherten Daten bei Speicherüberlastung gelöscht werden können, dass sie beim Inkognito-Browsen gar nicht gespeichert werden und dass ein unbedarfter Anwender möglicherweise "Cookies und sonstige Website-Daten" löscht und damit alles weg ist.

Prüfen des Inhalts von Storage-Objekten

Sie können die Storage-Objekte der dargestellten Seite in den Entwicklungswerkzeugen Ihres Browsers anschauen.

Chrome
Auf dem Tab Anwendung (oder Applikation) finden Sie links die Rubriken Lokaler Speicher und Sitzungsspeicher.
Firefox
Auf dem Tab Web-Speicher finden Sie links die Rubriken Local Storage und Session Storage,

enthalten ein Tab "Anwendung" (Chrome) oder "Web-Speicher" (Firefox)

In diesen Rubriken finden Sie die Origins, die im aktuellen Dokument verwendet werden. Das kann mehr als einer sein, wenn ein iframe verwendet wird, in dem ein Dokument aus einem anderen Origin angezeigt wird. Klicken Sie in der gewünschten Rubrik den Origin an, dessen Daten Sie sehen wollen, und Sie erhalten eine Auflistung aller dort gespeicherten Schlüssel-Wert Paare.

Sollte einer der Einträge ein im JSON-Format gespeichertes Objekt beinhalten, zeigt Ihnen Firefox den Eintrag rechts neben der Liste als Objekt an. Bei Chrome finden Sie diese Anzeige unter der Liste.

In dieser Auflistung können Sie Einträge löschen, Schlüsselnamen oder Werte verändern und auch neue Einträge anlegen. Zum Anlegen müssen Sie in Chrome unter den vorhandenen Einträgen die rechte Maustaste drücken, bei Firefox auf einem der vorhandenen Einträge oder alternativ das + Icon rechts oben.


Alternativen

Cookies

Auch Cookies werden dauerhaft im Browser gespeichert. Sie unterscheiden sich von den Storage-Objekten, Caches und IndexedDB in den folgenden Punkten:

  • Cookies dienen vor allem dazu, vom Server vorgegebene Werte zu speichern
  • Cookies haben nicht wirklich ein API, sie werden mit Hilfe von speziellen Zeichenketten über die cookie-Eigenschaft des Document-Objekts verwaltet
  • Die Sichtbarkeit von Cookies kann auf einen bestimmten Ressourcenpfad einer Domain begrenzt werden. Die Storage-Objekte sind immer für die ganze Domain sichtbar
  • Ein Cookie hat eine vorgegebene Lebensdauer
  • Je nach Browser-Einstellung und Response-Headern einer Seite können Ressourcen, die von Drittanbietern hinzugeladen werden, Cookies dieser Drittanbieter übertragen
  • Cookies werden bei Server-Requests mit zum Server übertragen und könnn vom Server verändert werden. Größere Datenmengen in Cookies führen zu einer deutlichen Erhöhung des übertragenen Datenvolumens und bremsen damit eine Webseite aus
Beachten Sie: Datensparsamkeit und Datensicherheit
Sowohl Cookies wie auch andere dauerhafte Datenspeicher dürfen nur verwendet werden, wenn entweder ein berechtigtes Interesse an der Speicherung begründet werden kann, oder der Webseitenbesucher sein Einverständnis zur Speicherung gibt. Man spricht hier zwar regelmäßig von der Cookie-Richtlinie, die EU Datenschutzgrundverordnung gilt aber weltweit und für jegliche personenbezogene Daten, egal ob sie im Browser oder auf einem Server gespeichert werden.

Cache Storage und IndexedDB

Es gibt noch zwei weitere Techniken, um Daten im Browser abzulegen. Diese sind auch in Workern verfügbar und haben jeweils eine eigene Spezifikation und eine eigene Programmierschnittstelle.

  • Das CacheStorage Objekt, das Teil des ServiceWorker API ist und über die caches-Eigenschaft des globalen Objekts erreicht werden kann. Der CachedStorage ist zum Zwischenspeichern von Ressourcen gedacht, die von einem Server geladen wurden, und eignet sich nicht als eigenständiger Datenspeicher.
  • Das IndexedDB API, das über die indexedDB Eigenschaft des globalen Objekts verfügbar ist. Es wurde für das clientseitige Speichern und Verarbeiten größerer Datenmengen entwickelt und bietet allen Komfort einer Datenbank.

Siehe auch

  • DOM-Manipulation
    • ToDo-Liste
      • WebStorage
  • Zahlenspiele
    • Zufallsgenerator
    • Zahlen-Raten
    • Mathe-Quiz mit Web Storage
  • Dark Mode

    Lass' die Nutzer entscheiden:

    Vorschau-01-groß.png

Weblinks

  1. MDN: Using the Web Storage API
  2. SELF-Forum: WebStorage kann blockiert sein 10.02.2025 von Ryuno-Ki