Ursprungstest für HTTP-Header-Unterstützung in Storage Access

Natalia Markoborodova
Natalia Markoborodova
X GitHub

In Chrome 130 wird ein Ursprungstest für das Hinzufügen von HTTP-Headern zur Storage Access API (SAA) gestartet: Storage Access Headers. Die neuen Anfrageheader Sec-Fetch-Storage-Access und Antwortheader Activate-Storage-Access sollen Ressourcen ohne iFrame unterstützen und die Leistung und Nutzerfreundlichkeit von Websites verbessern, die auf eingebetteten Inhalten wie Social-Media-Widgets, Kalendern und interaktiven Tools basieren.

JavaScript-Ablauf (und seine Einschränkungen)

Bisher war für SAA bei jedem Neuladen ein JavaScript-API-Aufruf an document.requestStorageAccess() erforderlich, auch wenn der Nutzer die Berechtigung bereits erteilt hatte. Diese Methode ist zwar effektiv, hat aber auch Einschränkungen:

  • Mehrere Netzwerk-Roundtrips:Bevor die eingebetteten Inhalte vollständig funktionierten, waren oft mehrere Netzwerkanfragen und Seitenneuladungen erforderlich.
  • iFrame-Abhängigkeit:Für die JavaScript-Ausführung war die Verwendung von iFrames oder untergeordneten Ressourcen in iFrames erforderlich, was die Flexibilität für Entwickler einschränkte.

Ein Kalender-Widget von calendar.example, das nur mit JavaScript auf website.example eingebettet wird, sieht beispielsweise so aus:

  1. Platzhalter laden:website.example fordert das Widget an. Da das auf website.example eingebettete calendar.example-Widget keinen Zugriff auf seine nicht partitionierten Cookies hat, wird stattdessen ein Platzhalter-Widget gerendert.
  2. Berechtigung anfordern:Der Platzhalter wird geladen und ruft dann document.requestStorageAccess() auf, um die Berechtigung storage-access anzufordern.
  3. Der Nutzer entscheidet, ob er die Berechtigung erteilt.
  4. Widget neu laden:Das Widget wird aktualisiert, diesmal mit Cookie-Zugriff, und lädt schließlich die personalisierten Inhalte.
  5. Jedes Mal, wenn der Nutzer eine Website mit dem calendar.example-Widget besucht, sieht der Ablauf genau wie in den Schritten 1, 2 und 4 aus. Die einzige Vereinfachung besteht darin, dass der Nutzer den Zugriff nicht noch einmal gewähren muss.

Dieser Ablauf ist ineffizient: Wenn der Nutzer bereits die Speicherberechtigung erteilt hat, sind das anfängliche Laden des iFrames, der document.requestStorageAccess()-Aufruf und das anschließende Neuladen unnötig und führen zu Latenz.

Der neue Ablauf mit HTTP-Headern

Die neuen Storage Access Headers ermöglichen ein effizienteres Laden eingebetteter Inhalte, einschließlich Nicht-iFrame-Ressourcen.

Mit Storage Access Headers ruft der Browser automatisch Ressourcen mit dem festgelegten Anfrageheader Sec-Fetch-Storage-Access: inactive ab, wenn der Nutzer die Berechtigung bereits erteilt hat. Entwickler müssen nichts weiter tun, um den Anfrageheader festzulegen. Der Server kann mit dem Header Activate-Storage-Access: retry; allowed-origin="<origin>" antworten. Der Browser wiederholt die Anfrage dann mit den erforderlichen Anmeldedaten.

Anfrage-Header

Sec-Fetch-Storage-Access: <access-status>

Wenn ein Nutzer eine Seite besucht, auf der websiteübergreifende Inhalte eingebettet sind, fügt der Browser automatisch den Sec-Fetch-Storage-Access-Header in websiteübergreifende Anfragen ein, für die möglicherweise Anmeldedaten (z. B. Cookies) erforderlich sind. Dieser Header gibt den Berechtigungsstatus für den Cookie-Zugriff des eingebetteten Elements an. So interpretieren Sie die Werte:

  • none: Das eingebettete Element hat nicht die Berechtigung storage-access und kann daher nicht auf nicht partitionierte Cookies zugreifen.
  • inactive: Das Einbettungselement hat die Berechtigung storage-access, hat sich aber nicht für die Verwendung entschieden. Das eingebettete Element hat keinen Zugriff auf nicht partitionierte Cookies.
  • active: Das eingebettete Element hat uneingeschränkten Cookie-Zugriff. Dieser Wert wird in alle ursprungsübergreifenden Anfragen aufgenommen, die Zugriff auf nicht partitionierte Cookies haben.

Antwortheader

Activate-Storage-Access: <retry-or-reload>

Der Activate-Storage-Access-Header weist den Browser an, die Anfrage entweder mit Cookies noch einmal zu versuchen oder die Ressource direkt mit aktivierter SAA zu laden. Der Header kann die folgenden Werte haben:

  • load: weist den Browser an, dem Einbettungsprogramm Zugriff auf nicht partitionierte Cookies für die angeforderte Ressource zu gewähren.
  • retry: Der Server antwortet, dass der Browser die Berechtigung für den Speicherzugriff aktivieren und die Anfrage dann noch einmal versuchen soll.
Activate-Storage-Access: retry; allowed-origin="https://site.example"
Activate-Storage-Access: retry; allowed-origin=*
Activate-Storage-Access: load

Unterstützung für Ressourcen ohne iFrame

Durch die Aktualisierung der Storage Access Headers wird SAA für Inhalte aktiviert, die nicht in iFrames eingebettet sind, z. B. Bilder, die auf einer anderen Domain gehostet werden. Bisher war es nicht möglich, solche Ressourcen mit Anmeldedaten in Browsern zu laden, wenn keine Drittanbieter-Cookies verfügbar sind. Ihr embedding-site.example kann beispielsweise ein Bild anfordern:

   <img src="https://server.example/image"/>

Der Server kann je nach Verfügbarkeit eines Cookies mit Inhalten oder einem Fehler antworten:

app.get('/image', (req, res) => {
  const headers = req.headers;
  const cookieHeader = headers.cookie;
  // Check if the embed has the necessary cookie access
  if (!cookieHeader || !cookieHeader.includes('foo')) {
  // If the cookie is not present, check if the browser supports Storage Access headers
    if (
      'sec-fetch-storage-access' in headers &&
      headers['sec-fetch-storage-access'] == 'inactive'
    ) {
    // If the browser supports Storage Access API, retry the request with storage access enabled
      res.setHeader('Activate-Storage-Access', 'retry; allowed-origin="https://embedding-site.example"');
    }
    res.status(401).send('No cookie!');
   } else {
    // If the cookie is available, check if the user is authorized to access the image
    if (!check_authorization(cookieHeader)) {
      return res.status(401).send('Unauthorized!');
    }
    // If the user is authorized, respond with the image file
    res.sendFile("path/to/image.jpeg");
  }
});

Wenn das Cookie nicht verfügbar ist, prüft der Server den Wert des Anfrageheaders Sec-Fetch-Storage-Access. Wenn dieser Wert auf inactive gesetzt ist, antwortet der Server mit dem Header Activate-Storage-Access: retry, der angibt, dass die Anfrage mit Speicherzugriff wiederholt werden sollte. Wenn kein Cookie vorhanden ist und der Sec-Fetch-Storage-Access-Header nicht den Wert „inactive“ hat, wird das Bild nicht geladen.

HTTP-Header-Ablauf

Mithilfe von HTTP-Headern kann der Browser erkennen, wann der Nutzer dem Widget bereits die Berechtigung für den Speicherzugriff erteilt hat. Bei nachfolgenden Besuchen wird der iFrame mit Zugriff auf nicht partitionierte Cookies geladen.

Mit Storage Access-Headern wird bei nachfolgenden Seitenbesuchen der folgende Ablauf ausgelöst:

  1. Der Nutzer besucht website.example, in die calendar.example wieder eingebettet ist. Bei diesem Abruf ist noch kein Zugriff auf das Cookie möglich. Der Nutzer hat jedoch zuvor die Berechtigung storage-access erteilt und der Abruf enthält einen Sec-Fetch-Storage-Access: inactive-Header, der angibt, dass der Zugriff auf nicht partitionierte Cookies verfügbar, aber nicht in Verwendung ist.
  2. Der calendar.example-Server antwortet mit einem Activate-Storage-Access: retry; allowed-origin="<origin>"-Header (in diesem Fall wäre <origin> https://website.example), um anzugeben, dass für das Abrufen der Ressource die Verwendung nicht partitionierter Cookies mit der Berechtigung „Speicherzugriff“ erforderlich ist.
  3. Der Browser wiederholt die Anfrage und fügt diesmal nicht partitionierte Cookies ein (wodurch die Berechtigung storage-access für diesen Abruf aktiviert wird).
  4. Der calendar.example-Server antwortet mit dem personalisierten iFrame-Inhalt. Die Antwort enthält einen Activate-Storage-Access: load-Header, der angibt, dass der Browser die Inhalte mit der aktivierten Berechtigung storage-access laden soll. Das bedeutet, dass die Inhalte mit nicht partitioniertem Cookie-Zugriff geladen werden, als ob document.requestStorageAccess() aufgerufen worden wäre.
  5. Der User-Agent lädt den iFrame-Inhalt mit nicht partitioniertem Cookie-Zugriff mithilfe der Berechtigung „storage-access“. Danach kann das Widget wie erwartet funktionieren.
Ein Flussdiagramm, das den Ablauf des Storage Access Headers veranschaulicht.
Flussdiagramm für den Header für den Speicherzugriff.

Lösung aktualisieren

Mit der Funktion „Storage Access Headers“ kann es in zwei Fällen erforderlich sein, Ihren Code zu aktualisieren:

  1. Sie verwenden SAA und möchten die Leistung mit Header-Logik verbessern.
  2. Sie haben eine Validierung oder Logik, die davon abhängt, ob der Origin-Header in der Anfrage auf Ihrem Server enthalten ist.

Logik für SAA-Header implementieren

Wenn Sie Storage Access Headers in Ihrer Lösung verwenden möchten, müssen Sie Ihre Lösung aktualisieren. Angenommen, Sie sind der Inhaber von calendar.example. Damit website.example ein personalisiertes calendar.example-Widget laden kann, muss der Widget-Code Speicherzugriff haben.

Clientseitig

Für die Funktion „Storage Access Headers“ ist für die vorhandenen Lösungen kein Code-Update auf der Clientseite erforderlich. Weitere Informationen zur Implementierung von SAA

Serverseitig

Auf der Serverseite können Sie die neuen Header verwenden:

app.get('/cookie-access-endpoint', (req, res) => {
  const storageAccessHeader = req.headers['sec-fetch-storage-access'];

  if (storageAccessHeader === 'inactive') {
    // User needs to grant permission, trigger a prompt
    if (!validate_origin(req.headers.origin)) {
      res.status(401).send(`${req.headers.origin} is not allowed to send` +
          ' credentialed requests to this server.');
      return;
    }
    res.set('Activate-Storage-Access', `retry; allowed-origin="${req.headers.origin}"`);
    res.status(401).send('This resource requires storage access. Please grant permission.');
  } else if (storageAccessHeader === 'active') {
    // User has granted permission, proceed with access
    res.set('Activate-Storage-Access', 'load');
    // Include the actual iframe content here
    res.send('This is the content that requires cookie access.');
  } else {
    // Handle other cases (e.g., 'Sec-Fetch-Storage-Access': 'none')
  }
});

Demo ansehen

Origin-Header-Logik aktualisieren

Mit Storage Access Headers sendet Chrome den Origin-Header in mehr Anfragen als zuvor. Dies kann sich auf Ihre serverseitige Logik auswirken, wenn sie darauf basiert, dass der Origin-Header nur für bestimmte Arten von Anfragen (z. B. für CORS-Anfragen) vorhanden ist.

Um potenzielle Probleme zu vermeiden, müssen Sie Ihren serverseitigen Code überprüfen:

  • Prüfen Sie, ob es Validierungen oder Logik gibt, die vom Vorhandensein des Origin-Headers abhängen.
  • Aktualisieren Sie Ihren Code, damit der Origin-Header in mehr Fällen vorhanden ist.

Hauptvorteile

Storage Access Headers sind eine empfohlene, leistungsfähigere Methode zur Verwendung der SAA. Insgesamt bringt diese Änderung mehrere Verbesserungen mit sich:

  • Unterstützung von Einbettungen ohne iFrame:Ermöglicht SAA für eine größere Auswahl an Ressourcen.
  • Geringere Netzwerknutzung:Weniger Anfragen und kleinere Nutzlasten.
  • Geringere CPU-Auslastung:Weniger JavaScript-Verarbeitung.
  • Verbesserte Nutzerfreundlichkeit:Störende Zwischenladezeiten werden vermieden.

Am Ursprungstest teilnehmen

Mit Ursprungstests können Sie neue Funktionen ausprobieren und Feedback zu ihrer Benutzerfreundlichkeit, Praktikabilität und Effektivität geben. Weitere Informationen finden Sie unter Erste Schritte mit Origin Trials.

Sie können die Funktion „Storage Access Headers“ testen, indem Sie sich ab Chrome 130 für die Ursprungstests registrieren. So nehmen Sie am Ursprungstest teil:

  1. Rufen Sie die Registrierungsseite für den Storage Access Headers-Testlauf auf.
  2. Folgen Sie der Anleitung zur Teilnahme am Origin-Test.

Lokal testen

Sie können die Funktion „Storage Access Headers“ lokal testen, um sicherzustellen, dass Ihre Website für diese Änderung bereit ist.

So konfigurieren Sie Ihre Chrome-Instanz:

  1. Aktivieren Sie das Chrome-Flag auf chrome://flags/#storage-access-headers.
  2. Starten Sie Chrome neu, damit die Änderungen wirksam werden.

Feedback geben

Wenn Sie Feedback haben oder Probleme auftreten, können Sie ein Problem melden. Weitere Informationen zu den Storage Access Headers finden Sie in der GitHub-Erklärung.