En-tête Activate-Storage-Access

Syntaxe

Activate-Storage-Access: retry; allowed-origin="https://toto.tata"
Activate-Storage-Access: retry; allowed-origin=*
Activate-Storage-Access: load

Directives

retry

Le serveur utilise ce jeton pour indiquer qu'il a besoin de ses cookies tiers afin de répondre correctement à cette requête.

Le serveur doit vérifier la présence de Sec-Fetch-Storage-Access: inactive dans la requête avant de répondre avec ce jeton pour vérifier que l'autorisation a déjà été accordée (mais est inactive). Le paramètre allowed-origin doit être défini pour autoriser l'origine spécifique (définir * pour autoriser n'importe quelle origine).

Le navigateur doit répondre en activant une autorisation d'accès au stockage déjà accordée, et en réessayant la requête avec les cookies non partitionnés inclus.

load

Le serveur utilise ce jeton pour indiquer qu'il envoie au navigateur un document HTML qui doit activer une autorisation storage-access préexistante — afin d'accéder aux cookies non partitionnés pendant le chargement.

Le serveur doit vérifier la présence de Sec-Fetch-Storage-Access: inactive ou Sec-Fetch-Storage-Access: active dans la requête avant de répondre avec load pour confirmer que l'autorisation a déjà été accordée.

Le navigateur doit répondre en chargeant la ressource et en lui accordant l'accès à ses cookies non partitionnés.

Description

L'API d'accès au stockage fournit un mécanisme JavaScript permettant à une ressource intégrée de demander l'autorisation storage-access. Ceci permet d'envoyer des cookies tiers dans les requêtes, ce qui est sinon bloqué par défaut dans la plupart des navigateurs. La ressource doit d'abord être demandée sans cookies, de sorte que le serveur retourne une version non authentifiée de la ressource qui n'a pas accès à ses propres cookies. Après le chargement, cette ressource peut appeler Document.requestStorageAccess() avec une activation transitoire pour demander l'autorisation d'accès au stockage. Si l'utilisateur·ice accorde l'autorisation, celle-ci est stockée par le navigateur dans une clé associée à l'intégrateur et au site intégré. Le navigateur doit alors recharger la ressource, qu'il peut maintenant demander avec les cookies, car il dispose de l'état d'autorisation active pour le contexte courant.

L'autorisation est accordée pour un couple intégrateur/site intégré particulier, mais n'est activée que pour un contexte particulier, tel qu'un <iframe> ou un onglet du navigateur. Cela signifie que si vous chargez la même page dans un nouvel onglet ou <iframe>, l'état d'autorisation de ce contexte est accordé mais inactive ; il ne devient active que lorsque l'autorisation est activée. Le flux normal d'accès au stockage consiste à demander à nouveau la ressource sans cookies, à appeler Document.requestStorageAccess() pour activer l'autorisation existante, puis à recharger la ressource avec les cookies.

La ressource doit être chargée au moins une fois pour que l'autorisation d'accès au stockage soit accordée. Cependant, une fois accordée, un serveur peut utiliser Activate-Storage-Access pour activer l'autorisation pour d'autres origines et contextes.

Le fonctionnement est le suivant :

1. Le navigateur ajoute Sec-Fetch-Storage-Access: inactive aux requêtes lorsque le contexte dispose de l'autorisation mais qu'elle n'est pas active (ainsi que l'en-tête Origin indiquant la source de la requête).
2. Si le serveur reçoit Sec-Fetch-Storage-Access: inactive, il peut répondre avec Activate-Storage-Access: retry; allowed-origin="<request_origin>" pour demander au navigateur d'activer l'autorisation pour le contexte et de réessayer la requête.
3. Si le navigateur reçoit la demande de réessai, il active l'autorisation et envoie à nouveau la requête, cette fois avec Sec-Fetch-Storage-Access: active et en incluant les cookies.
4. Si le serveur voit une requête avec Sec-Fetch-Storage-Access: active et des cookies, il répond avec la version authentifiée de la ressource. Une fois chargée par le navigateur, cette ressource a accès à ses cookies comme s'il s'agissait d'une ressource de premier niveau.

Les réponses doivent également inclure l'en-tête Vary avec Sec-Fetch-Storage-Access.

Exemples

Ces exemples montrent des requêtes avec Sec-Fetch-Storage-Access pour des contextes ayant différents états d'autorisation d'accès au stockage, et les réponses correspondantes avec Activate-Storage-Access. Ils utilisent l'exemple d'un site, https://monsite.exemple, qui inclut un <iframe> intégrant une page de profil utilisateur, embedded.com/user/profile.

Activation d'une autorisation par le serveur

Cet exemple suppose que l'utilisateur·ice a déjà accordé l'autorisation pour le contexte, mais qu'elle n'a pas encore été activée. (Avec l'API, on active l'autorisation en rechargeant la ressource afin qu'elle puisse appeler Document.requestStorageAccess().)

La requête concerne un <iframe> inter-sites avec le mode d'identifiants "include". Le navigateur a ajouté Sec-Fetch-Storage-Access: inactive à la requête, car l'autorisation secure-access a été accordée mais pas activée. Il n'a pas ajouté de cookies car ils sont bloqués par défaut. L'en-tête Origin est également défini car le serveur doit connaître la source de la requête.

GET /user/profile HTTP/1.1
Host: embedded.com
Origin: https://monsite.exemple
Sec-Fetch-Dest: iframe
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: navigate
Sec-Fetch-Storage-Access: inactive
Credentials-Mode: include

Le serveur répond avec Activate-Storage-Access: retry; allowed-origin="https://monsite.exemple", indiquant que le navigateur doit activer l'autorisation accordée et réessayer la requête avec les cookies. Le serveur inclut l'en-tête Vary, car la réponse peut varier selon Sec-Fetch-Storage-Access.

HTTP/1.1 401 Unauthorized
Content-Type: text/html
Vary: Sec-Fetch-Storage-Access
Activate-Storage-Access: retry; allowed-origin="https://monsite.exemple"

Le navigateur active l'autorisation et effectue une nouvelle requête. Vous pouvez voir ci-dessous qu'il positionne Sec-Fetch-Storage-Access: active et inclut cette fois les cookies tiers.

GET /user/profile HTTP/1.1
Host: embedded.com
Origin: https://monsite.exemple
Sec-Fetch-Dest: iframe
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: navigate
Sec-Fetch-Storage-Access: active
Credentials-Mode: include
Cookie: sessionid=abc123

Le serveur répond alors avec la ressource authentifiée qui inclut Activate-Storage-Access: load. La ressource est chargée et a accès à ses cookies comme s'il s'agissait d'une inclusion de premier niveau.

HTTP/1.1 200 OK
Content-Type: text/html
Activate-Storage-Access: load
Vary: Sec-Fetch-Storage-Access

<html>
  ...
</html>

Autorisation secure-access initialement non accordée

Cet exemple suppose qu'il s'agit de la première fois que l'utilisateur·ice visite une page qui intègre un contenu de embedded.com, donc l'autorisation d'accès au stockage n'a pas été accordée.

Les en-têtes ne peuvent activer une autorisation que pour un contexte qui a déjà été accordé — ils ne peuvent pas être utilisés pour accorder l'autorisation d'accès au stockage à l'origine. La page intégrée doit donc être chargée sans cookies puis appeler Document.requestStorageAccess() avec une activation transitoire pour demander l'autorisation d'accès au stockage. C'est le même flux que si les en-têtes n'étaient pas présents.

La requête est la même que dans l'exemple précédent, sauf que le navigateur a ajouté Sec-Fetch-Storage-Access: none, car l'autorisation secure-access n'a pas été accordée. Là encore, les cookies ne sont pas ajoutés car ils sont bloqués par défaut.

GET /user/profile HTTP/1.1
Host: embedded.com
Origin: https://monsite.exemple
Sec-Fetch-Dest: iframe
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: navigate
Sec-Fetch-Storage-Access: none
Credentials-Mode: include

Le serveur retourne une version non authentifiée de la ressource. Celle-ci inclut l'en-tête Vary, car la réponse peut varier selon Sec-Fetch-Storage-Access. Notez qu'elle n'inclut pas Activate-Storage-Access car le serveur ne peut pas activer une autorisation si aucune n'a été accordée.

HTTP/1.1 200 OK
Content-Type: text/html
Vary: Sec-Fetch-Storage-Access

<html>
  ...
</html>

La page intégrée appelle alors Document.requestStorageAccess() avec une activation transitoire pour demander l'autorisation d'accès au stockage. Si l'autorisation d'accès au stockage est accordée pour la page intégrée, elle est également activée.

Elle se recharge alors, ce qui donne la requête suivante. Cette fois, le navigateur ajoute Sec-Fetch-Storage-Access: active et inclut les cookies tiers, reflétant l'état d'autorisation du contenu intégré.

GET /user/profile HTTP/1.1
Host: embedded.com
Origin: https://monsite.exemple
Sec-Fetch-Dest: iframe
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: navigate
Sec-Fetch-Storage-Access: active
Credentials-Mode: include
Cookie: sessionid=abc123

Le serveur répond avec la version authentifiée de la ressource, qui peut être différente de la première version chargée, et ajoute l'en-tête Activate-Storage-Access: load. Le navigateur charge la page, qui a désormais accès à ses propres informations de cookie.

HTTP/1.1 200 OK
Content-Type: text/html
Vary: Sec-Fetch-Storage-Access
Activate-Storage-Access: load

<html>
  ...
</html>

Spécifications

Compatibilité des navigateurs

Voir aussi

• L'en-tête HTTP Sec-Fetch-Storage-Access
• En-têtes d'accès au stockage dans l'API Storage Access
• Séquences d'en-têtes d'accès au stockage dans l'API Storage Access