Webdatenspeicherung: Cookie, UserData, SessionStorage, WebSqlDatabase

Plätzchen

Dies ist eine Standardmethode zum Speichern des Status des Client-Browsers. Cookies können kurz nach der Erstellung des Browsers erschienen sein. Warum brauchen wir Cookies? Da das HTTP-Protokoll keinen Status hat, wird ein Flag/Speicher benötigt, um den aktuellen Status des Client-Browsers aufzuzeichnen und sicherzustellen, dass der aktuelle Status des Client-Browsers bekannt ist, wenn der Client-Browser und der Server kommunizieren. Ein Cookie ist ein Container, der diesen Status aufzeichnet. Bei jeder Anforderung wird das Cookie an den Server zurückgeschickt, sodass der Server den aktuellen Status des Browsers kennt. Da das Cookie an den Server zurückgeschickt wird, darf der Inhalt des Cookies nicht zu groß sein und darf höchstens 4 KB nicht überschreiten. Die Einführung der 4-KB-Begrenzung finden Sie unter http://ec.europa.eu/ipg/standards/cookies/index_en.htm.
Eine der Passagen lautet:

Ein Browser muss insgesamt nur bis zu 300 Cookies speichern und nur die letzten 20 von jeder Domäne verwalten. Die maximale Größe eines Cookies beträgt 4 KB Speicherplatz.

In manchen Szenarien kann es jedoch erforderlich sein, mehr als 4 KB oder mehr Daten zu speichern. Diese Daten müssen jedoch nicht bei jeder Anforderung an den Server zurückgeschickt werden. Solange sie im Browser des Kunden gespeichert und von Javascript problemlos gelesen und geschrieben werden können, ist alles in Ordnung. Diese Anforderung ist in den Anwendungsszenarien mittlerer und großer RIAs besonders dringend. Einige Daten werden im Browser des Kunden abgelegt, um Bandbreite zu sparen und die Browsing-Geschwindigkeit zu erhöhen. Der HTML5-Standard bietet bereits Lösungen, um diesem Bedarf gerecht zu werden: sessionStorage, webSqlDatabase und Microsoft IE verfügt über eine userData-Lösung.

Benutzerdaten
Microsofts Einführung in USERDATA: http://msdn2.microsoft.com/en-us/library/ms531424(VS.85).aspx
Eine der Passagen lautet:

Sicherheitswarnung: Aus Sicherheitsgründen ist ein UserData-Speicher nur im selben Verzeichnis und mit demselben Protokoll verfügbar, das zum Speichern des Speichers verwendet wird.
Sicherheitswarnung: Die falsche Verwendung dieses Verhaltens kann die Sicherheit Ihrer Anwendung gefährden. Daten in einem UserData-Speicher sind nicht verschlüsselt und daher nicht sicher. Jede Anwendung, die Zugriff auf das Laufwerk hat, auf dem UserData gespeichert ist, hat Zugriff auf die Daten. Daher wird empfohlen, vertrauliche Daten wie Kreditkartennummern nicht dauerhaft zu speichern. Weitere Informationen finden Sie unter Sicherheitsüberlegungen: DHTML und Standardverhalten.
…
Das userData-Verhalten speichert Daten über Sitzungen hinweg und verwendet dabei einen UserData-Speicher für jedes Objekt. Der UserData-Speicher wird mithilfe der Methoden save und load im Cache gespeichert. Sobald der UserData-Speicher gespeichert wurde, kann er neu geladen werden, selbst wenn Microsoft Internet Explorer geschlossen und erneut geöffnet wurde.
Das Festlegen der Verhaltensklasse „userData“ für das HTML-, Head-, Title- oder Style-Objekt verursacht einen Fehler, wenn die Methode „Speichern“ oder „Laden“ aufgerufen wird.

Auf Benutzerdaten kann im selben Verzeichnis und mit demselben Protokoll zugegriffen werden, und sie können für längere Zeit auf dem Client-Rechner gespeichert werden. Auch der maximale Speicherplatz wurde deutlich vergrößert. UserData muss an ein Dom-Element gebunden werden. In der Methode userData gibt es eine Methode removeAttribute. Nach dem Testen des Codes stellte ich fest, dass die Methode removeAttribute nicht sehr nützlich zu sein scheint. Um ein userData-Attribut vollständig zu löschen, muss eine Methode wie Cookie Expiration verwendet werden.
Unter http://www.itwen.com/04web/11skill/skill20060918/60588.html wird eingeführt, dass Benutzerdaten im Verzeichnis X:\Dokumente und Einstellungen\aktueller Benutzer\UserData\ gespeichert werden. MS macht in der UserData-Dokumentation keine konkreten Angaben.

Sitzungsspeicher
HTML5-Standardeinführung in sessionStorage: http://www.whatwg.org/specs/web-apps/current-work/
Die Einführung von sessionStorage:

Diese Spezifikation führt zwei verwandte Mechanismen ein, ähnlich den HTTP-Sitzungscookies [RFC2965], um strukturierte Daten auf der Clientseite zu speichern.
Die erste ist für Szenarien vorgesehen, in denen der Benutzer eine einzelne Transaktion durchführt, aber mehrere Transaktionen gleichzeitig in verschiedenen Fenstern ausführen könnte.
Cookies sind in diesem Fall nicht wirklich hilfreich. Ein Benutzer könnte beispielsweise über dieselbe Website in zwei verschiedenen Fenstern Flugtickets kaufen. Wenn die Website Cookies verwendet, um zu verfolgen, welches Ticket der Benutzer kauft, würde das aktuell gekaufte Ticket, während der Benutzer in beiden Fenstern von Seite zu Seite klickt, von einem Fenster in das andere „durchsickern“, was möglicherweise dazu führen könnte, dass der Benutzer zwei Tickets für denselben Flug kauft, ohne es wirklich zu bemerken.
Um dieses Problem zu lösen, führt diese Spezifikation das DOM-Attribut sessionStorage ein. Sites können Daten zum Sitzungsspeicher hinzufügen und diese sind für jede Seite von diesem Ursprung aus zugänglich, die in diesem Fenster geöffnet wird.

Html5 sessionStorage-Demo: http://html5demos.com/storage
Nachfolgend sehen Sie den Testcode für IE FF-kompatible Benutzerdaten gemäß http://www.blogjava.net/emu/archive/2006/10/04/73385.html:

Der SetInsurance-Link führt JavaScript aus, um Daten mithilfe von userData im IE und sessionStore im FF zu schreiben. Unter IE ist die Situation folgende: Der geschriebene Wert geht beim Schließen des IE oder beim Neustarten des Computers nicht verloren. Die Situation unter FF ist sehr interessant: Auf den auf dieser Seite geschriebenen Wert kann auf dieser Seite und auf anderen von dieser Seite geöffneten Seiten zugegriffen werden. Aber auch wenn diese Seite geöffnet ist, kann nicht auf den gespeicherten Wert zugegriffen werden, wenn Sie die Adresse in die Navigationsleiste eingeben und diese Seite öffnen. Auf die auf dieser Seite gespeicherten Werte kann auf der übergeordneten Seite (der Seite, die diese Seite geöffnet hat) nicht zugegriffen werden. Ich habe mir den HTML5-Standard noch einmal angesehen. Der vollständige Name von sessionStorage lautet: Clientseitige Sitzung und dauerhafte Speicherung von Name/Wert-Paaren, was wahrscheinlich bedeutet, dass der im Client gespeicherte Inhalt sitzungsbezogen ist und die gespeicherten Werte von der Sitzung verwaltet werden. Sobald die Sitzung unterbrochen oder verloren geht, verschwinden die gespeicherten Werte. Wenn für die Seite keine Sitzung besteht (übergeordnete Seite, die über die Adressleiste geöffnete Seite), kann der Wert daher nicht abgerufen werden. Wenn FF heruntergefahren oder die Maschine neu gestartet wird, wird der Wert zwangsläufig nicht abgerufen.

webSqlDatenbank
webSqlDatabase ist eine sehr coole Sache im HTML5-Standard. Sie können SQL-Abfragen in Javascript schreiben und die Datenbank befindet sich im Browser, was vorher fast undenkbar war. Aber heute unterstützen Safari, Chrome und Opera es alle. Hier sind zwei Demoseiten für webSqlDatabase: http://html5demos.com/database http://html5demos.com/database-rollback
Einführungsseite des W3C für WEBSQLDATABASE: http://dev.w3.org/html5/webdatabase/
Eine kurze Erklärung im Wiki: http://en.wikipedia.org/wiki/Web_SQL_Database

Vom W3C: „...eine API zum Speichern von Daten in Datenbanken, die mit einer SQL-Variante abgefragt werden können“
Web SQL Database wird von Google Chrome[1], Opera und Safari unterstützt, wird aber nicht von Mozilla(Firefox)[2] implementiert, das stattdessen den Zugriff über die Indexed Database API vorsieht.

Ich weiß nicht, wie gut die SQLDB von HTML 5 von Browsern unterstützt wird, aber sessionStorage scheint die Anforderungen grundsätzlich erfüllen zu können.