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

Dies ist eine äußerst weit gefasste Frage, und viele der Vor- und Nachteile werden kontextabhängig sein.

In allen Fällen sind diese Speichermechanismen für einen einzelnen Browser auf einem einzelnen Computer / Gerät spezifisch. Jede Anforderung, Daten kontinuierlich über Sitzungen hinweg zu speichern, muss Ihre Anwendungsserverseite einbeziehen - höchstwahrscheinlich unter Verwendung einer Datenbank, möglicherweise jedoch XML oder einer Text- / CSV-Datei.

localStorage, sessionStorage und Cookies sind Client-Speicherlösungen. Sitzungsdaten werden auf dem Server gespeichert, auf dem sie direkt von Ihnen gesteuert werden.

localStorage und sessionStorage

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

Wenn die von Ihnen gespeicherten Daten fortlaufend verfügbar sein müssen, ist localStorage eindeutig sessionStorage vorzuziehen. Beachten Sie jedoch, dass beide 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 zum Speichern nicht sensibler Daten, die in Client-Skripten zwischen Seiten benötigt werden (z. B. Einstellungen, Ergebnisse in Spielen). Die in localStorage und sessionStorage gespeicherten Daten können problemlos über den Client / Browser gelesen oder geändert werden. Sie sollten daher nicht für die Speicherung vertraulicher oder sicherheitsrelevanter Daten in Anwendungen verwendet werden.

Kekse

Dies gilt auch für Cookies. Diese können vom Benutzer trivial manipuliert werden, und Daten können auch im Klartext daraus 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) / Script Injection bieten können, indem ein Nur-HTTP-Flag gesetzt wird. Dies bedeutet, dass moderne (unterstützende) Browser den Zugriff auf die Cookies und Werte von JavaScript verhindern ( Dies verhindert auch, dass Ihr eigenes, legitimes JavaScript auf sie zugreift. Dies ist besonders wichtig bei Authentifizierungs-Cookies, mit denen ein Token gespeichert wird, das Details des angemeldeten Benutzers enthält. Wenn Sie eine Kopie dieses Cookies haben, werden Sie in jeder Hinsicht zu diesem Benutzer, soweit es die Webanwendung betrifft betroffen sind und den gleichen Zugriff auf Daten und Funktionen haben, über die der Benutzer verfügt.

Da Cookies zu Authentifizierungszwecken und zur Beständigkeit von Benutzerdaten verwendet werden, werden alle für eine Seite gültigen Cookies für jede Seite vom Browser an den Server gesendet Anforderung an dieselbe Domain Dazu gehören die ursprüngliche Seitenanforderung, alle nachfolgenden Ajax-Anforderungen, 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 einschränken, die in Cookies gespeichert werden können. In der Regel werden Cookies verwendet, um identifizierende Token für die Authentifizierung, Sitzung und Werbeverfolgung zu speichern. Bei den Token handelt es sich in der Regel nicht um an sich lesbare Informationen, sondern um verschlüsselte Kennungen, die mit Ihrer Anwendung oder Datenbank verknüpft sind.

localStorage vs. sessionStorage vs. Cookies

In Bezug auf Funktionen können Sie mit Cookies, sessionStorage und localStorage nur Zeichenfolgen speichern. Beim Festlegen können implizite Grundwerte 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 mithilfe von JSON zu serialisieren, um sie mithilfe der APIs zu speichern.) Im Sitzungsspeicher können Sie im Allgemeinen alle Grundelemente oder Objekte speichern, die von Ihrer serverseitigen Sprache / Ihrem Framework unterstützt werden.

Client-Seite vs. Server-Seite

Da HTTP ein zustandsloses Protokoll ist - Webanwendungen haben keine Möglichkeit, einen Benutzer aus früheren Besuchen bei der Rückkehr zur Website zu identifizieren -, basieren Sitzungsdaten normalerweise auf einem Cookie-Token, um den Benutzer für wiederholte Besuche zu identifizieren (obwohl selten URL-Parameter verwendet werden können der gleiche Zweck). Daten haben normalerweise eine verschiebbare Ablaufzeit (wird bei jedem Besuch des Benutzers erneuert). Abhängig von Ihrem Server / Framework werden die Daten entweder in Bearbeitung gespeichert (dh Daten gehen verloren, wenn der Webserver abstürzt oder neu gestartet wird) oder extern in ein Statusserver oder eine Datenbank. Dies ist auch erforderlich, wenn Sie eine Webfarm verwenden (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 sensible oder sichere 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 clientseitig 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 seinen Browser schließt, müssen die Sitzungsdaten nach einer bestimmten Zeit ablaufen, um zu vermeiden, dass alle Serverressourcen von abgebrochenen Sitzungen belegt 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 Browser / Geräte wechselt.

Einige Web-Frameworks / Entwickler verwenden versteckte HTML-Eingaben, um Daten von einer Seite eines Formulars auf eine andere zu speichern und so das Ablaufen der Sitzung zu vermeiden.

localStorage, sessionStorage und Cookies unterliegen den Regeln "gleichen Ursprungs". Dies bedeutet, dass Browser den Zugriff auf die Daten mit Ausnahme der Domäne, mit der die Informationen beginnen, verhindern sollten.

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

1. Lokaler Speicher

   Vorteile :

   1. 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 , was 2,5 Millionen Zeichen in Chrome entspricht) die Standardspeichergröße für eine gesamte Domain ist. Dies gibt Ihnen erheblich mehr Platz zum Arbeiten als mit 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 bestehen, bis sie explizit gelöscht werden. Die vorgenommenen Änderungen werden gespeichert und stehen für alle aktuellen und zukünftigen Besuche auf der Website zur Verfügung.

   Nachteile :

   1. Es funktioniert mit Richtlinien gleichen Ursprungs . Die gespeicherten Daten sind also nur am selben Ursprung verfügbar.

2. Kekse

   Vorteile:

   1. Im Vergleich zu anderen gibt es nichts AFAIK.

   Nachteile:

   1. Das 4K-Limit 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 des Cookies unter 4093 Byte halten.

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

      In der Regel sind folgende 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, dh Daten sind nur pro Fenster (oder Tab in Browsern wie Chrome und Firefox) verfügbar. Daten sind nur während der Seitensitzung verfügbar. Die vorgenommenen Änderungen werden gespeichert und sind für die aktuelle Seite sowie für zukünftige Besuche der Site im selben Fenster verfügbar. Sobald das Fenster geschlossen ist, wird der Speicher gelöscht.

   Nachteile:

   1. Die Daten sind nur in dem Fenster / der Registerkarte verfügbar, in dem sie festgelegt wurden.
   2. Wie localStoragefunktioniert es auf same-origin policy . Die gespeicherten Daten sind also nur am selben Ursprung verfügbar.

Checkout über Registerkarten hinweg - So vereinfachen Sie die Kommunikation zwischen originalen Browser-Registerkarten.

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 5 MB , aber Cookies sind sehr kleine Daten, die in Ihrem Browser gespeichert werden. Sie können bis zu 4 KB speichern und können sowohl über den Server als auch über den Browser aufgerufen werden.

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

Dies sind Eigenschaften des 'Fenster'-Objekts in JavaScript, genau wie das Dokument eine Eigenschaft des Fensterobjekts ist, das DOM-Objekte enthält.

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

Der lokale Speicher macht dasselbe, bleibt jedoch auch dann bestehen, wenn der Browser geschlossen und erneut geöffnet wird.

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

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

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

Ähnliches gilt für localStorage.

Lokaler Speicher: Die Benutzerinformationsdaten 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

Sitzungsspeicher: Entspricht dem lokalen Speicherdatum, löscht jedoch alle Fenster, wenn Browserfenster von einem Webbenutzer geschlossen werden.

In Session Storage können bis zu 5 MB Daten gespeichert werden

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

Session : 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.

Die Web Storage API bietet Mechanismen, mit denen Browser Schlüssel / Wert-Paare viel intuitiver speichern können als mit Cookies. Die Web Storage API erweitert das WindowObjekt um zwei neue Eigenschaften - Window.sessionStorageund 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 sessionStorageund localStoragefür jeden Ursprung (Domäne) wird 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 Werte sind immer Zeichenfolgen . So speichern Sie einen beliebigen Typconvert it to Stringund speichern ihn dann. Es wird immer empfohlen,Storage interfaceMethodenzu 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 zwei Mechanismen innerhalb von Web Storage sind wie folgt:

• sessionStorage verwaltet für jeden Ursprung einen separaten Speicherbereich. Richtlinie für denselben ^Ursprung , die für die Dauer der Seitensitzung verfügbar ist (solange der Browser geöffnet ist, einschließlich Neuladen und Wiederherstellen von Seiten).
• localStorage macht dasselbe, bleibt aber auch dann bestehen, wenn der Browser geschlossen und erneut geöffnet wird.

Speicher «Der lokale Speicher schreibt die Daten auf die Festplatte, während der Sitzungsspeicher die Daten nur in den Speicher schreibt. Alle in den Sitzungsspeicher geschriebenen Daten 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   |
+----------------+--------+---------+-----------+--------+

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

• QuotaExceededError : Wenn die Speicherbeschränkungen für diese Funktion überschritten werdenwindow.sessionStorage.setItem(key, value);, wird eine DOMException-Ausnahme "QuotaExceededError" ausgelöst, wenn der neue Wert nicht festgelegt werden konnte. (Die Einstellung kann fehlschlagen, wenn der Benutzer beispielsweise den Speicher für die Site deaktiviert hat oder wenn das Kontingent überschritten wurde.)

  DOMException. QUOTA_EXCEEDED_ERR ist 22 , Beispiel Geige .

• Sicherheitsfehler :Uncaught SecurityError: Access to 'localStorage' is denied for this document.

  CHROME:-Privacy and security « Content settings « Cookies « Block third-party cookies.

StorageEvent «Das Speicherereignis wird für das Fensterobjekt eines Dokuments ausgelöst, wenn sich ein Speicherbereich ändert. Wenn ein Benutzeragent eine Speicherbenachrichtigung für ein Dokument senden soll, muss der Benutzeragent eine Aufgabe in die Warteschlange stellen, um mithilfe von StorageEvent ein Ereignis mit dem Namen storage im Fensterobjekt des Dokumentobjekts auszulösen.

Hinweis: Ein Beispiel aus der Praxis finden Sie unter Web Storage-Demo . ^{Überprüfen Sie den Quellcode}

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

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

JavaScript-Zugriff mit Document.cookie

Neue Cookies können auch über JavaScript mithilfe der Document.cookie-Eigenschaft 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"

Secure und HttpOnly Cookies ^{HTTP State Management Mechanism}

In Webanwendungen werden häufig Cookies 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, und dann wird das Cookie mit Anforderungen 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-Direktive an.

Set-Cookie: sessionid=38afes7a8; HttpOnly; Path=/

Permanente Cookies verfallen zu einem bestimmten Datum (läuft ab) oder nach einer bestimmten Zeitspanne (maximales Alter).

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

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

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

• Sitzungsverwaltung «Anmeldungen, Einkaufswagen, Spielergebnisse oder alles andere, woran sich der Server erinnern sollte
• Personalisierung «Benutzereinstellungen, Themen und andere Einstellungen
• Tracking (Aufzeichnen und Analysieren des Benutzerverhaltens) «Cookies ist eine Domain zugeordnet. Wenn diese Domain mit der Domain der Seite identisch ist, auf der Sie sich befinden, handelt es sich bei den Cookies um Erstanbieter-Cookies. Wenn die Domain anders ist, handelt es sich um ein Cookie eines Drittanbieters. Während Cookies von Erstanbietern nur an den Server gesendet werden, der sie setzt, 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 Cookies von Drittanbietern bezeichnet und hauptsächlich für Werbung und Nachverfolgung im Internet verwendet.

Cookies wurden erfunden, um das Problem zu lösen, "wie man sich Informationen über den Benutzer merkt":

• 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 Anfrage Cookies hinzugefügt, die zur Seite gehören. Auf diese Weise erhält der Server die erforderlichen Daten, um sich Informationen über Benutzer zu "merken".

GitHubGist Beispiel

Zusammenfassend:

• localStorage bleibt über verschiedene Registerkarten oder Fenster hinweg bestehen, und selbst wenn wir den Browser schließen, entsprechend der Domänensicherheitsrichtlinie und den Benutzeroptionen für das Kontingentlimit.
• Das sessionStorage-Objekt bleibt nicht bestehen, 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.
• Mit Web Storage (Sitzung, lokal) können wir eine große Anzahl von Schlüssel / Wert-Paaren und viel Text speichern, was per Cookie 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 die von Google verwendeten Arten von Cookies .
• Bei jeder Anfrage werden Cookies gesendet, damit die Leistung beeinträchtigt werden kann (insbesondere bei mobilen Datenverbindungen). Moderne APIs für den Client-Speicher sind die Web-Speicher-API (localStorage und sessionStorage) und IndexedDB.

LocalStorage :

• 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 typischer 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 bestehen, bis sie explizit gelöscht werden. Die vorgenommenen Änderungen werden gespeichert und stehen für alle aktuellen und zukünftigen Besuche auf der Website zur Verfügung.

• Es funktioniert mit Richtlinien gleichen Ursprungs. Die gespeicherten Daten sind also nur am selben Ursprung verfügbar.

Kekse:

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

• Das 4K-Limit 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 des Cookies unter 4093 Byte halten.

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

sessionStorage:

• Es ähnelt localStorage.

• Änderungen sind nur pro Fenster (oder Registerkarte in Browsern wie Chrome und Firefox) verfügbar. Die vorgenommenen Änderungen werden gespeichert und sind für die aktuelle Seite sowie für zukünftige Besuche der Site im selben Fenster verfügbar. Sobald das Fenster geschlossen ist, wird der Speicher gelöscht. Die Daten sind nur innerhalb des Fensters / der Registerkarte verfügbar, in dem sie festgelegt wurden.

• Die Daten sind nicht persistent, dh sie gehen verloren, sobald das Fenster / die Registerkarte geschlossen wird. Wie localStorage funktioniert es mit Richtlinien gleichen Ursprungs. Die gespeicherten Daten sind also nur am selben Ursprung verfügbar.

Hier ist eine kurze Überprüfung und mit einem einfachen und schnellen Verständnis

von Lehrer Beau Carnes vom Freecodecamp