Storage Access API

Konzepte und Nutzung

Browser implementieren mehrere Funktionen und Richtlinien fr den Speicherzugriff, die den Zugriff auf Drittanbieter-Cookies und unpartitionierte Zustnde einschrnken. Diese reichen von der Bereitstellung eines einzigartigen Cookie-Speicherplatzes fr jede eingebettete Ressource unter jedem obersten Ursprung (partitionierte Cookies) bis hin zum vollstndigen Blockieren des Cookie-Zugriffs, wenn Ressourcen in einem Drittanbieter-Kontext geladen werden.

Die Semantik der Funktionen und Richtlinien zur Blockierung von Drittanbieter-Cookies und unpartitionierten Zustnden unterscheiden sich von Browser zu Browser, aber die Kernfunktionalitt ist hnlich. Standorteigene Ressourcen, die in einem Drittanbieter-Kontext eingebettet sind, erhalten keinen Zugriff auf denselben Zustand, auf den sie zugreifen knnten, wenn sie in einem Erstanbieter-Kontext geladen werden. Dies erfolgt in guter Absicht Browserhersteller mchten Schritte unternehmen, um die Privatsphre und Sicherheit ihrer Benutzer besser zu schtzen. Beispiele beinhalten, dass weniger Tracking-Aktivitten zwischen verschiedenen Websites mglich sind und weniger Angriffsflchen fr Exploits wie Cross-Site Request Forgery (CSRF) bestehen.

Es gibt jedoch legitime Verwendungszwecke fr eingebettete standortbergreifende Inhalte, die auf Drittanbieter-Cookies und unpartitionierte Zustnde zugreifen, und die oben genannten Funktionen und Richtlinien sind bekannt dafr, dies zu stren. Nehmen wir an, Sie haben eine Reihe verschiedener Websites, die Zugang zu unterschiedlichen Produkten bieten heads-example.com, shoulders-example.com, knees-example.com und toes-example.com.

Alternativ knnten Sie Ihre Inhalte oder Dienste in verschiedene Lnderdomains fr Lokalisierungszwecke trennen example.com, example.ua, example.br usw. oder in einer anderen Weise.

Sie knnten begleitende Utility-Websites haben, die in alle anderen Websites eingebettete Komponenten bereitstellen, um beispielsweise SSO (sso-example.com) oder allgemeine Personalisierungsdienste (services-example.com) bereitzustellen. Diese Utility-Websites mchten ihren Zustand ber Cookies mit den Websites teilen, in die sie eingebettet sind. Sie knnen keine Erstanbieter-Cookies teilen, da sie sich auf unterschiedlichen Domains befinden, und Drittanbieter-Cookies werden in Browsern, die diese blockieren, nicht mehr funktionieren.

In solchen Situationen ermutigen Website-Betreiber die Benutzer oft, ihre Website als Ausnahme hinzuzufgen oder die Richtlinien zur Blockierung von Drittanbieter-Cookies vollstndig zu deaktivieren. Benutzer, die weiterhin mit ihren Inhalten interagieren mchten, mssen ihre Blockierungspolitik erheblich fr Ressourcen lockern, die von allen eingebetteten Ursprngen geladen werden, und mglicherweise ber alle Websites hinweg.

Die Speicherzugriffs-API soll dieses Problem lsen; eingebettete standortbergreifende Inhalte knnen uneingeschrnkten Zugriff auf Drittanbieter-Cookies und unpartitionierte Zustnde auf einer Frame-zu-Frame-Basis ber die Methode Document.requestStorageAccess() anfordern. Sie kann auch berprfen, ob sie bereits Zugriff hat, ber die Methode Document.hasStorageAccess().

Unpartitionierte versus partitionierte Cookies

Die Speicherzugriffs-API wird nur bentigt, um den Zugriff auf unpartitionierte Drittanbieter-Cookies bereitzustellen! Unpartitionierte Cookies sind solche, bei denen alle auf derselben Website gesetzten Cookies im selben Cookie-Jar gespeichert werden die traditionelle Art und Weise seit den frhen Zeiten des Webs. Da die Gefahr besteht, dass Daten, die fr eine Website gedacht sind, anderen Websites zugnglich gemacht werden, blockieren Browser hufig das Senden unpartitionierter Drittanbieter-Cookies in Anfragen und lassen den Zugriff darauf in eingebetteten Kontexten nicht zu.

Dies steht im Gegensatz zu partitionierten Cookies, bei denen eingebetteten Ressourcen unter jeder obersten Website ein einzigartiger Cookie-Speicherplatz zugewiesen wird, der von denen anderer Websites isoliert ist. Da es kein Datenschutzrisiko gibt, da es nicht mglich ist, Benutzer ber Sites mithilfe partitionierter Cookies zu verfolgen, senden Browser partitionierte Cookies in Anfragen und stellen sie eingebetteten Ressourcen zur Verfgung. Beachten Sie jedoch, dass, da die Cookies nicht zwischen Websites geteilt werden, sie auch nicht automatisch synchronisiert werden. Browser haben verschiedene Mechanismen zur Partitionierung des Zugriffs auf Drittanbieter-Cookies, beispielsweise Firefox Total Cookie Protection und Cookies Having Independent Partitioned State (CHIPS).

Wenn wir im Kontext der Speicherzugriffs-API ber Drittanbieter-Cookies sprechen, meinen wir implizit unpartitionierte Drittanbieter-Cookies.

Funktionsweise

Drittanbieter-Inhalte, die in einem <iframe> eingebettet sind und auf Cookies oder andere unpartitionierte Zustnde zugreifen mssen, knnen mithilfe der Speicherzugriffs-API wie folgt Zugriff anfordern:

1. Document.hasStorageAccess() kann aufgerufen werden, um zu berprfen, ob der eingebettete Inhalt bereits Zugriff auf unpartitionierte Cookies hat.

2. Falls nicht, kann Document.requestStorageAccess() mit transient activation aufgerufen werden, um die Erlaubnis storage-access anzufordern.

   Abhngig vom Browser wird der Benutzer auf leicht unterschiedliche Weise gefragt, ob er der anfordernden Einbettung die Erlaubnis erteilen mchte.

   • Safari zeigt Eingabeaufforderungen fr alle eingebetteten Inhalte an, die zuvor keinen Speicherzugriff erhalten haben.
   • Firefox fordert Benutzer nur auf, nachdem ein Ursprung auf mehr als einer Schwellenanzahl von Websites um Speicherzugriff gebeten hat.
   • Chrome zeigt Eingabeaufforderungen fr alle eingebetteten Inhalte an, die zuvor keinen Speicherzugriff erhalten haben. Es wird jedoch den Zugriff automatisch gewhren und die Eingabeaufforderungen berspringen, wenn der eingebettete Inhalt und die einbettende Website Teil desselben related website set sind.

3. Die Genehmigung wird basierend auf der Erfllung aller Sicherheitsanforderungen erteilt oder verweigert siehe Sicherheitsberlegungen fr allgemeine Anforderungen und Browser-spezifische Variationen fr einige browserspezifische Sicherheitsanforderungen. Die Promise-basierte Natur von requestStorageAccess() ermglicht Ihnen das Ausfhren von Code, um Erfolgs- und Fehlerszenarien zu verarbeiten.

   Sobald die Genehmigung gewhrt ist, wird ein Erlaubnisschlssel mit der Struktur <top-level site, embedded site> im Browser gespeichert. Wenn die einbettende Website beispielsweise embedder.com ist und die Einbettung locator.example.com, wrde der Schlssel <embedder.com, example.com> sein.

   Das bedeutet, dass die Erlaubnis fr den Zugriff auf unpartitionierte Cookies fr jede Seite auf der Website example.com oder einer ihrer Subdomains, die in jede Seite auf der embedder.com-Website eingebettet ist, gewhrt wurde. Beispielsweise knnen docs.example.com, profile.example.com jetzt requestStorageAccess() aufrufen und das Versprechen wrde automatisch erfllt werden.

   Hinweis: ltere Spezifikationsversionen verwendeten die spezifischere Erlaubnisschlsselstruktur <top-level site, embedded origin>, was bedeutete, dass samesite-Cross-Origin-Einbettungen nicht mit dem Erlaubnisschlssel bereinstimmten und den gesamten Prozess separat durchlaufen mussten.

4. Die Erlaubnis muss explizit fr jeden Kontext aktiviert werden.

   Wenn eine Einbettung die Erlaubnis erhlt, wird diese Erlaubnis auch fr den aktuellen Kontext aktiviert. Andere Kontexte, wie neue Browser-Tabs oder Inhalte in anderen <iframe>-Elementen auf der Seite, haben standardmig keinen Zugriff auf Drittanbieter-Cookies. Das bedeutet, selbst wenn die Erlaubnis erteilt wurde, muss die Seite laden und requestStorageAccess() aufrufen, um die Erlaubnis zu aktivieren. Wenn die Erlaubnis bereits erteilt wurde, erfordert ein Aufruf von requestStorageAccess() keine vorbergehende Aktivierung und das Versprechen wird automatisch erfllt werden.

   Die einzige Ausnahme von dem Verhalten "standardmig blockiert" ist, wenn eine Einbettung eine navigation von gleicher Herkunft durchfhrt, um sich nach Erhalt der Erlaubnis oder Aktivierung einer Erlaubnis neu zu laden. In solchen Fllen wird der Speicherzugriff aus der vorherigen Navigation bernommen. Dies ermglicht der eingebetteten Ressource, sich selbst neu zu laden und Zugriff auf ihre Cookies zu erhalten.

   Hinweis: In lteren Spezifikationsversionen war der Zugriff pro Seite (Safari ist der einzige Browser, der dieses Modell noch verwendet). Wenn eine Einbettung ber requestStorageAccess() Zugriff auf Drittanbieter-Cookies erhielt, erhielten alle anderen samesite-Einbettungen automatisch Zugriff. Dies war aus Sicherheitsgrnden kein wnschenswertes Verhalten. Wenn shop.example.com beispielsweise locator.users.com einbettete, um Benutzern zu ermglichen, ihre Standortinformationen whrend des Einkaufs zu verwenden und locator.users.com requestStorageAccess() aufrief, konnte shop.example.com und jede andere von ihm eingebettete Seite auf seine Cookies zugreifen und auch auf Cookies von private.users.com, die nicht fr Einbettungen gedacht sind. Lesen Sie mehr ber die Beweggrnde hinter dieser nderung.

5. Nachdem eine Einbettung die Berechtigung zum Speicherzugriff aktiviert hat, sollte sie sich selbst neu laden. Der Browser wird die Ressource mit einbezogenen Drittanbieter-Cookies erneut anfordern und sie beim Laden der eingebetteten Ressource zur Verfgung stellen. Die richtlinienbezogenen Anfragen der Einbettung folgen der Samesite-Politik, daher werden Drittanbieter-Cookies nur mit Anfragen an die genaue Herkunft der eingebetteten Ressource gesendet. Andere Ursprnge innerhalb derselben Website, die auf Drittanbieter-Cookies zugreifen mchten, mssen die Speicherzugriffs-Berechtigung separat aktivieren.

Speicherzugriffs-Header

Die API erfordert, dass eine Ressource requestStorageAccess() fr jeden neuen Kontext aufruft, um sich fr die Aktivierung der bereits gewhrten Speicherzugriffsberechtigung anzumelden. Dies bedeutet im Gegenzug, dass die eingebettete Ressource zuerst ohne Cookies angefordert und geladen werden muss, damit sie die Methode aufrufen kann.

Die Speicherzugriffs-Header ermglichen einen Workflow, bei dem der Server die Aktivierung der Berechtigung fr den Kontext anfordern kann und damit das unntige zustzliche Laden der eingebetteten Ressource vermieden wird, wenn die Erlaubnis bereits erteilt wurde. Die Ressource muss jedoch noch geladen werden, um die Erlaubnis beim ersten Mal anzufordern.

Es gibt zwei Header:

• Der Browser fgt der Anfrage den Sec-Fetch-Storage-Access-Header hinzu, um den Speicherzugriffsstatus des aktuellen Abrufkontexts anzuzeigen, z. B. ob die Erlaubnis aktiviert, erteilt oder nicht erteilt wurde.
• Abhngig vom Speicherzugriffsstatus der Anfrage kann der Server mit einem Activate-Storage-Access-Header antworten, um zu verlangen, dass der Browser die Erlaubnis fr den Kontext aktiviert und die Anfrage mit Cookies erneut versucht (wobei vermieden wird, die Ressource laden zu mssen, um requestStorageAccess() aufzurufen, um dasselbe Ziel zu erreichen), oder die Erlaubnis aktiviert und die zurckgegebene Ressource ldt.

Die Speicherzugriffs-Header knnen auch verwendet werden, um die Erlaubnis fr passive Ressourcen wie Bilder zu aktivieren, sofern der Kontext bereits eine Erlaubnis hat. Dies knnte zum Beispiel verwendet werden, um verschiedene Bilder fr verschiedene Benutzer, Zielgruppen oder Orte zu servieren.

Die Workflows werden im Abschnitt Speicherzugriffs-Header-Sequenzen gezeigt.

Anforderungs-/Antwortfluss

JavaScript-Sequenzen

Betrachten wir das Beispiel einer in einem <iframe> geladenen Bibliothek, die ber mehrere Seiten hinweg geteilt werden muss und auf Anmeldedaten setzt, die in unpartitionierten Cookies gespeichert sind.

Betrachten wir zuerst den Fall, in dem keine Erlaubnis erteilt wurde:

1. Der Browser fordert die Ressource an, ohne Drittanbieter-Cookies einzuschlieen.

2. Der Server antwortet mit einer "Rckfall"-Version von Inhalten, die nicht auf Anmeldedaten setzt und die beim Laden keinen Zugriff auf ihre Cookies hat.

   • Sobald die Ressource geladen ist, ruft sie requestStorageAccess() mit transienter Aktivierung auf, um die Erlaubnis storage-access anzufordern und zu aktivieren.
   • Wenn die Erlaubnis erteilt wird, ldt die Ressource sich selbst neu.

3. Der Browser fordert die Ressource erneut an, diesmal unter Einbeziehung von Drittanbieter-Cookies.

4. Die Antwort des Servers enthlt eine "anmeldedatenbasierte" Version der Ressource.

Der Browser ldt die Ressource, die Zugriff auf ihre eigenen Cookies hat, weil sie eine aktivierte storage-access-Erlaubnis hat.

[Speicher-API-Workflow - ohne Speicherzugriffs-Berechtigung]

Nun betrachten wir den Fall, in dem die Erlaubnis erteilt, aber nicht aktiviert wurde. Dies wrde passieren, wenn Sie dieselbe URL in einem neuen Browser-Tab ffnen oder versuchen, dieselbe Ressource von einer anderen Seite auf derselben Website einzubetten.

Der Workflow ist fast genau derselbe, da die Ressource trotzdem zuerst ohne Cookies geladen werden muss und anschlieend requestStorageAccess() aufrufen muss, um die Erlaubnis fr den Kontext zu aktivieren. In diesem Fall bentigt sie jedoch keine vorbergehende Aktivierung und kann beim Laden ausgefhrt werden.

[Speicher-API-Workflow - Speicherzugriffs-Berechtigung aktivieren]

Speicherzugriffs-Header-Sequenzen

Die Speicherzugriffs-Header ermglichen einen verbesserten Workflow, der es dem Server erlaubt, den Browser aufzufordern, eine bereits erteilte Erlaubnis zur Aktivierung zu nutzen und die Anforderung mit einbezogenen Cookies erneut zu versuchen. Dies vermeidet das Erfordernis, die Ressource zu laden, um requestStorageAccess() aufzurufen, wenn der Benutzer die Erlaubnis bereits erteilt hat.

Der Sec-Fetch-Storage-Access-Header wird zu Anforderungen hinzugefgt, um den Speicherzugriffsstatus des aktuellen Abrufkontexts anzugeben, etwa ob die Erlaubnis aktiviert, erteilt oder nicht erteilt wurde. Abhngig vom Speicherzugriffsstatus der Anforderung kann der Server mit einem Activate-Storage-Access-Header antworten, um den Browser aufzufordern, die Erlaubnis fr den Kontext zu aktivieren und die Anforderung mit Cookies erneut zu versuchen.

Schauen wir uns zunchst den Fall an, in dem versucht wird, eine eingebettete Ressource fr einen neuen Kontext zu laden, der bereits eine erteilte Erlaubnis hat:

1. Der Browser sendet eine Anfrage mit Sec-Fetch-Storage-Access: inactive, um anzuzeigen, dass die Erlaubnis erteilt, aber fr den Kontext inaktiv ist.
   • Die Anforderung wird auch den Origin-Header enthalten, um dem Server zu helfen, zu entscheiden, ob er die Berechtigung aktivieren mchte.
2. Der Server kann dann mit Activate-Storage-Access: retry antworten, um anzuzeigen, dass der Browser die Erlaubnis aktivieren und die Anfrage mit Cookies erneut versuchen soll.
   • Die Antwort sollte auch den Vary: Sec-Fetch-Storage-Access-Header enthalten, da sie vom Wert Sec-Fetch-Storage-Access abhngt.
   • Beachten Sie, dass die Antwort keinen Inhalt enthlt.
3. Wenn der Browser die Anfrage erneut versucht, fgt er Sec-Fetch-Storage-Access: active neben den Cookies hinzu.
4. Der Server antwortet dann mit Activate-Storage-Access: load, was dem Browser mitteilt, die neue Version der Bibliothek mit Zugriff auf die Drittanbieter-Cookies zu laden.

[Speicherzugriffs-Header-Workflow - Speicherzugriffs-Berechtigung aktivieren und erneut versuchen]

Der letzte Zustand, der zu bercksichtigen ist, ist das Laden einer eingebetteten Ressource, fr die die Erlaubnis nicht erteilt wurde:

1. Der Browser sendet eine Anfrage mit Sec-Fetch-Storage-Access: none, um anzuzeigen, dass die Erlaubnis nicht erteilt wurde.

2. Der Server antwortet dann mit der Ressource, die beim Laden die Erlaubnis fr sicheren Zugriff mit vorbergehender Aktivierung anfordert. Der Activate-Storage-Access-Header ist nicht in der Antwort enthalten, aber der Server sollte Vary: Sec-Fetch-Storage-Access hinzufgen.

   Nachdem der Benutzer die Erlaubnis erteilt (und dadurch aktiviert) hat, ldt die Einbettung sich selbst neu.

3. Der Browser fgt der Anfrage Sec-Fetch-Storage-Access: active hinzu, um anzuzeigen, dass der Kontext eine aktivierte storage-access-Erlaubnis hat, und schliet die Drittanbieter-Cookies ein.

4. Der Server antwortet mit Activate-Storage-Access: load, was dem Browser mitteilt, die neue Version der Bibliothek mit Zugriff auf die Drittanbieter-Cookies zu laden.

[Speicherzugriffs-Header-Workflow - ohne Speicherzugriffs-Berechtigung]

Sicherheitsberlegungen

Verschiedene Sicherheitsmanahmen knnten dazu fhren, dass ein Aufruf von Document.requestStorageAccess() fehlschlgt. berprfen Sie die nachstehende Liste, wenn Sie Probleme haben, eine Anfrage zum Laufen zu bringen:

1. Der Erlaubnisantrag muss mit einem Nutzerzustimmungs(transient activation) wie einem Tipp oder Klick verbunden sein. Dies verhindert, dass eingebettete Inhalte auf der Seite den Browser oder Benutzer mit bermigen Zugriffsanforderungen berfluten. Beachten Sie, dass dies nicht erforderlich ist, wenn:

   • Die Erlaubnis zur Nutzung der API bereits fr einen anderen Kontext mit demselben <top-level site, embedded site>-Schlssel erteilt wurde.
   • Der Anrufer ein oberstes Dokument oder eine gleichartige Seite des obersten Dokuments ist. In solchen Fllen muss requestStorageAccess() wahrscheinlich berhaupt nicht aufgerufen werden.

2. Das Dokument und das oberste Dokument drfen keinen null-Ursprung haben.

3. Ursprnge, die nie als Erstanbieter in Interaktion getreten sind, haben keine Vorstellung von Erstanbieter-Speicherplatz. Aus Sicht des Benutzers haben sie nur eine Drittanbieterbeziehung zu diesem Ursprung. Zugriffsanforderungen werden automatisch abgelehnt, wenn der Browser erkennt, dass der Benutzer in letzter Zeit nicht mit dem eingebetteten Inhalt in einem Erstanbieter-Kontext interagiert hat (in Firefox bedeutet "in letzter Zeit" innerhalb von 30 Tagen).

4. Das Fenster des Dokuments muss ein sicherer Kontext sein.

5. Sandboxed <iframe>s knnen aus Sicherheitsgrnden standardmig keinen Speicherzugriff erhalten. Die API stellt den allow-storage-access-by-user-activation Sandbox-Token zur Verfgung, um dies zu behandeln. Das <iframe> muss dies enthalten, um Speicherzugriffsanforderungen zu aktivieren, zusammen mit allow-scripts und allow-same-origin, um es zu erlauben, ein Skript auszufhren, um die API aufzurufen und sie in einem Ursprung auszufhren, der Cookies/Zustand haben kann:

   html

   <iframe
     sandbox="allow-storage-access-by-user-activation
                   allow-scripts
                   allow-same-origin">
     
   </iframe>
   

6. Die Nutzung dieser Funktion kann durch eine storage-access Permissions Policy, die auf Ihrem Server gesetzt ist, blockiert werden.

Browser-spezifische Varianten

Obwohl die API-Oberflche dieselbe ist, sollten Websites, die die Speicherzugriffs-API verwenden, Unterschiede im Ausma und Umfang des Zugriffs auf Drittanbieter-Cookies erwarten, den sie in verschiedenen Browsern erhalten, aufgrund ihrer unterschiedlichen Speicherzugriffsrichtlinien.

Chrome

• Cookies mssen explizit SameSite=None gesetzt haben, da der Standardwert fr Chrome SameSite=Lax ist (SameSite=None ist der Standard in Firefox und Safari).
• Cookies mssen das Attribut Secure gesetzt haben.
• Die Berechtigungsfreigaben fr den Speicherzugriff laufen nach 30 Tagen Browsernutzung aus, wenn keine Nutzerinteraktion stattgefunden hat. Die Interaktion mit dem eingebetteten Inhalt verlngert dieses Limit um weitere 30 Tage. Dies geschieht nicht, wenn Document.requestStorageAccessFor() aufgerufen wird, da der Benutzer bereits auf der Seite ist.

Firefox

• Wenn der eingebettete Ursprung tracker.example bereits Drittanbieter-Cookie-Zugriff auf den obersten Ursprung foo.example erhalten hat und der Benutzer eine Seite von foo.example besucht, die eine Seite von tracker.example erneut einbettet, wird der eingebettete Ursprung sofort Drittanbieter-Cookie-Zugriff beim Laden haben, sofern das innerhalb von 30 Tagen geschieht.
• Die Zugriffsberechtigungen laufen nach 30 Kalendertagen aus.

Die Dokumentation zu Firefox' neuer Speicherzugriffsrichtlinie fr das Blockieren von Tracking-Cookies enthlt eine detaillierte Beschreibung des Berechtigungsumfangs.

Safari

• Die Speicherzugriffsberechtigungen laufen nach 30 Tagen Browserverwendung aus, wenn keine Nutzerinteraktion stattgefunden hat. Ein erfolgreicher Einsatz der Speicherzugriffs-API setzt diesen Zhler zurck.
• Nachdem eine Einbettung die Speicherzugriffs-Berechtigung aktiviert hat und ihr Inhalt erneut angefordert wurde, werden Drittanbieter-Cookies mit Anfragen an die Website der eingebetteten Ressource gesendet, anstelle des Ursprungs. Safari verwendet immer noch ein lteres Design, das nicht der Ursprungsstrategie folgt.

Beispiele

• Siehe Verwendung der Speicherzugriffs-API fr einen Implementierungsleitfaden mit Codebeispielen.

API-Methoden

Document.hasStorageAccess()

Gibt ein Promise zurck, das sich mit einem booleschen Wert auflst, der angibt, ob das Dokument Zugriff auf Drittanbieter-Cookies hat.

Document.hasUnpartitionedCookieAccess()

Neuer Name fr Document.hasStorageAccess().

Document.requestStorageAccess()

Ermglicht es Inhalten, die in einem Drittanbieter-Kontext geladen werden (z. B. in einem <iframe> eingebettet), Zugriff auf Drittanbieter-Cookies und unpartitionierte Zustnde anzufordern; gibt ein Promise zurck, das erfllt wird, wenn der Zugriff gewhrt wurde, und abgelehnt wird, wenn der Zugriff verweigert wurde.

Document.requestStorageAccessFor()

Eine nicht standardisierte veraltete Erweiterung der Speicherzugriffs-API, die es obersten Websites ermglicht, Drittanbieter-Cookie-Zugriff im Namen eingebetteter Inhalte zu beantragen, die von einer anderen Website im selben related website set stammen. Gibt ein Promise zurck, das erfllt wird, wenn der Zugriff gewhrt wurde, und abgelehnt wird, wenn der Zugriff verweigert wurde.

Ergnzungen fr andere APIs

Permissions.query(), der "storage-access"-Feature-Name

In untersttzenden Browsern kann dies abfragen, ob der Zugriff auf Drittanbieter-Cookies im Allgemeinen gewhrt wurde, das heit zu einem anderen samesite-Einbettung. Wenn ja, knnen Sie requestStorageAccess() ohne Benutzerinteraktion aufrufen und das Versprechen wird automatisch erfllt.

Permissions.query(), der "top-level-storage-access"-Feature-Name

Ein separater Feature-Name, der verwendet wird, um abzufragen, ob die Erlaubnis zum Zugriff auf Drittanbieter-Cookies bereits ber requestStorageAccessFor() gewhrt wurde. Wenn ja, bentigen Sie requestStorageAccessFor() nicht erneut aufzurufen.

Ergnzungen zu HTTP

Erlaubnisrichtlinie

Permissions-Policy: storage-access

Die storage-access-Richtlinienrichtlinie steuert, ob ein in einem Drittanbieter-Kontext geladenes Dokument (z. B. eingebettet in einem <iframe>) die Speicherzugriffs-API verwenden darf, um Zugriff auf unpartitionierte Cookies anzufordern.

Speicherzugriffs-Header

Sec-Fetch-Storage-Access

Gibt den "Speicherzugriffsstatus" fr den aktuellen Anforderungskontext an, der einer von none, inactive oder active sein wird.

Activate-Storage-Access

Wird als Antwort auf Sec-Fetch-Storage-Access verwendet, um anzuzeigen, dass der Browser eine vorhandene Berechtigung fr sicheren Zugriff aktivieren und die Anfrage mit Cookies wiederholen kann oder eine Ressource mit Cookie-Zugriff laden kann, wenn er bereits eine aktivierte Erlaubnis hat.

Spezifikationen

Spezifikation
The Storage Access API
Extending Storage Access API (SAA) to non-cookie storage

Browser-Kompatibilitt

api.Document.hasStorageAccess

api.Document.hasUnpartitionedCookieAccess

api.Document.requestStorageAccess

api.Document.requestStorageAccessFor

api.Permissions.permission_storage-access

http.headers.Activate-Storage-Access

http.headers.Sec-Fetch-Storage-Access

Siehe auch

• Verwendung der Speicherzugriffs-API
• Einfhrung in die Speicherzugriffs-API (WebKit-Blog)