Cette page a été traduite par l'API Cloud Translation.

Test de l'origine pour la prise en charge des en-têtes HTTP dans l'accès au stockage

Natalia Markoborodova

Chrome lance une phase d'évaluation pour l'ajout d'en-têtes HTTP à l'API Storage Access (SAA) dans la version 130: En-têtes d'accès au stockage. Le nouvel en-tête de requête Sec-Fetch-Storage-Access et l'en-tête de réponse Activate-Storage-Access visent à prendre en charge les ressources autres que les iFrames, et à améliorer les performances et l'expérience utilisateur des sites Web qui s'appuient sur du contenu intégré, comme les widgets de réseaux sociaux, les calendriers et les outils interactifs.

Flux JavaScript (et ses limites)

Auparavant, SAA exigeait un appel d'API JavaScript vers document.requestStorageAccess() à chaque rechargement, même si l'utilisateur avait déjà accordé l'autorisation. Bien qu'efficace, cette méthode présente des limites:

Plusieurs allers-retours sur le réseau:le processus nécessitait souvent plusieurs requêtes réseau et actualisations de pages avant que le contenu intégré ne puisse fonctionner entièrement.
Dépendance iFrame:l'exécution JavaScript exigeait l'utilisation d'iFrames ou de sous-ressources dans les iFrames, ce qui limite la flexibilité pour les développeurs.

Par exemple, un widget d'agenda calendar.example intégré à website.example à l'aide de JavaScript se présente comme suit :

Charger un espace réservé : website.example demande le widget. Comme le widget calendar.example intégré à website.example n'a pas accès à ses cookies non partitionnés, un widget d'espace réservé s'affiche à la place.
Demander l'autorisation:l'espace réservé se charge, puis appelle document.requestStorageAccess() pour demander l'autorisation storage-access.
L'utilisateur choisit d'accorder l'autorisation.
Actualisez le widget : le widget s'actualise, cette fois avec un accès aux cookies, et charge finalement le contenu personnalisé.
Chaque fois que l'utilisateur accède à un site qui intègre à nouveau le widget calendar.example, le parcours est exactement le même que dans les étapes 1, 2 et 4. La seule simplification est que l'utilisateur n'a pas besoin de réaccorder l'accès.

Ce flux est inefficace : si l'utilisateur a déjà accordé l'autorisation de stockage, le chargement initial de l'iframe, l'appel document.requestStorageAccess() et le rechargement ultérieur deviennent inutiles et créent une latence.

Nouveau flux avec des en-têtes HTTP

Les nouveaux en-têtes d'accès à l'espace de stockage permettent un chargement plus efficace du contenu intégré, y compris des ressources hors iFrame.

Avec les en-têtes d'accès au stockage, le navigateur extrait automatiquement les ressources dont l'en-tête de requête Sec-Fetch-Storage-Access: inactive est défini, si l'utilisateur a déjà accordé l'autorisation. Aucune action de la part du développeur n'est requise pour définir l'en-tête de la requête. Le serveur peut répondre avec l'en-tête Activate-Storage-Access: retry; allowed-origin=<origin>, et le navigateur relance la requête avec les identifiants nécessaires.

En-tête de requête

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

Lorsqu'un utilisateur visite une page qui intègre du contenu intersites, le navigateur inclut automatiquement l'en-tête Sec-Fetch-Storage-Access dans les requêtes intersites pouvant nécessiter des identifiants (comme des cookies). Cet en-tête indique l'état de l'autorisation d'accès aux cookies de l'intégration. Voici comment interpréter ses valeurs :

none : l'intégration ne dispose pas de l'autorisation storage-access et n'a donc pas accès aux cookies non partitionnés.
inactive : l'intégration dispose de l'autorisation storage-access, mais n'a pas activé son utilisation. L'intégration n'a pas d'accès aux cookies non partitionné.
active : l'intégration dispose d'un accès aux cookies non partitionné. Cette valeur sera incluse dans toutes les requêtes inter-origines ayant accès aux cookies non partitionnés.

En-têtes de réponse

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

L'en-tête Activate-Storage-Access indique au navigateur de réessayer la requête avec des cookies ou de charger la ressource directement avec SAA activé. L'en-tête peut avoir les valeurs suivantes:

load: indique au navigateur d'accorder à l'intégrateur l'accès aux cookies non partitionnés pour la ressource demandée.
retry : le serveur répond que le navigateur doit activer l'autorisation d'accès au stockage, puis réessayer la requête.

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

Prise en charge des ressources autres que les iFrames

La mise à jour des en-têtes Storage Access permet d'utiliser SAA pour les contenus intégrés autres que les iframe, comme les images hébergées sur un autre domaine. Auparavant, aucune API de plate-forme Web n'autorisait le chargement de ces ressources avec des identifiants dans les navigateurs si les cookies tiers ne sont pas disponibles. Par exemple, votre embedding-site.example peut demander une image :

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

Le serveur peut répondre avec du contenu ou une erreur, selon qu'un cookie est disponible :

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");
  }
});

Si le cookie n'est pas disponible, le serveur vérifie la valeur de l'en-tête de requête Sec-Fetch-Storage-Access. Si cette valeur est définie sur inactive, le serveur répond avec l'en-tête Activate-Storage-Access: retry, indiquant que la requête doit être relancée avec l'accès à l'espace de stockage. S'il n'y a pas de cookie et que la valeur de l'en-tête Sec-Fetch-Storage-Access est inactive, l'image ne se charge pas.

Flux d'en-tête HTTP

Grâce aux en-têtes HTTP, le navigateur peut reconnaître lorsque l'utilisateur a déjà accordé l'autorisation d'accéder à l'espace de stockage au widget, et charger l'iFrame avec l'accès aux cookies non partitionnés lors des visites suivantes.

Avec les en-têtes d'accès au stockage, les visites suivantes des pages déclencheront le flux suivant:

L'utilisateur accède à nouveau à website.example, qui contient l'calendar.example intégrée. Comme précédemment, cette exploration n'a pas encore accès au cookie. Toutefois, l'utilisateur a déjà accordé l'autorisation storage-access, et la récupération inclut un en-tête Sec-Fetch-Storage-Access: inactive pour indiquer que l'accès aux cookies non partitionnés est disponible, mais pas utilisé.
Le serveur calendar.example répond avec un en-tête Activate-Storage-Access: retry; allowed-origin=<origin> (dans ce cas, <origin> serait https://website.example) pour indiquer que l'extraction de ressources nécessite l'utilisation de cookies non partitionnés avec l'autorisation d'accès au stockage.
Le navigateur retente la requête, cette fois en incluant les cookies non partitionnés (activation de l'autorisation storage-access pour cette extraction).
Le serveur calendar.example répond avec le contenu de l'iframe personnalisé. La réponse inclut un en-tête Activate-Storage-Access: load pour indiquer que le navigateur doit charger le contenu avec l'autorisation storage-access activée (en d'autres termes, charger avec un accès aux cookies non partitionné, comme si document.requestStorageAccess() avait été appelé).
L'user-agent charge le contenu de l'iFrame avec un accès aux cookies non partitionnés à l'aide de l'autorisation d'accès au stockage. Une fois cette étape effectuée, le widget peut fonctionner comme prévu.

Organigramme illustrant le flux de l'en-tête d'accès au stockage — Schéma du flux de l'en-tête d'accès au stockage

Mettre à jour votre solution

Avec la fonctionnalité d'en-têtes d'accès au stockage, vous pouvez mettre à jour votre code dans deux cas:

Vous utilisez la stratégie d'enchères au second affichage et souhaitez améliorer vos performances avec la logique d'en-tête.
Vous disposez d'une validation ou d'une logique qui dépend de l'inclusion de l'en-tête Origin dans la requête sur votre serveur.

Implémenter la logique d'en-têtes SAA

Pour utiliser les en-têtes d'accès au stockage dans votre solution, vous devez la mettre à jour. Supposons que vous soyez le propriétaire de calendar.example. Pour que website.example puisse charger un widget calendar.example personnalisé, le code du widget doit disposer d'un accès au stockage.

Côté client

La fonctionnalité d'en-têtes d'accès au stockage ne nécessite aucune mise à jour du code côté client pour les solutions existantes. Consultez la documentation pour découvrir comment implémenter SAA.

Côté serveur

Côté serveur, vous pouvez utiliser les nouveaux en-têtes:

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')
  }
});

Regardez la démonstration pour voir comment cette solution fonctionne en pratique.

Modifier la logique de l'en-tête d'origine

Avec les en-têtes d'accès au stockage, Chrome envoie l'en-tête Origin dans davantage de requêtes qu'auparavant. Cela peut affecter votre logique côté serveur si elle repose sur le fait que l'en-tête "Origin" n'est présent que pour des types de requêtes spécifiques (comme ceux définis par CORS).

Pour éviter tout problème potentiel, vous devez examiner votre code côté serveur :

Recherchez une validation ou une logique qui dépend de la présence de l'en-tête Origin.
Mettez à jour votre code pour gérer la présence de l'en-tête Origin dans un plus grand nombre de cas.

Principaux avantages

Les en-têtes d'accès au stockage sont une méthode recommandée et plus performante d'utiliser la SAA. Globalement, ce changement apporte plusieurs améliorations :

Compatibilité avec les éléments intégrés non iFrame:permet d'activer la fonctionnalité SAA pour un plus grand nombre de ressources.
Utilisation réduite du réseau : moins de requêtes et charges utiles plus petites.
Utilisation réduite du processeur:moins de traitement JavaScript.
Expérience utilisateur améliorée:élimine les chargements intermédiaires perturbateurs.

Participer à l'essai de l'origine

Les phases d'évaluation vous permettent de tester de nouvelles fonctionnalités et de donner votre avis sur leur facilité d'utilisation, leur utilité et leur efficacité. Pour en savoir plus, consultez Premiers pas avec les tests d'origine.

Vous pouvez essayer la fonctionnalité d'en-têtes d'accès au stockage en vous inscrivant aux phases d'évaluation à partir de Chrome 130. Pour participer à la phase d'évaluation de Topics :

Accédez à la page d'inscription à la phase d'évaluation des en-têtes d'accès au stockage.
Suivez les instructions pour participer au test de l'origine.

Tester en local

Vous pouvez tester la fonctionnalité des en-têtes d'accès au stockage localement pour vous assurer que votre site Web est prêt pour ce changement.

Pour configurer votre instance Chrome, procédez comme suit:

Activez l'indicateur Chrome sur chrome://flags/#storage-access-headers.
Redémarrez Chrome pour que les modifications prennent effet.

Interagir et partager des commentaires

Si vous avez des commentaires ou rencontrez des problèmes, vous pouvez signaler un problème. Vous pouvez également en savoir plus sur les en-têtes d'accès au stockage dans la explication sur GitHub.