Chrome lance une phase d'évaluation de l'origine pour ajouter des en-têtes HTTP à l'API Storage Access (SAA) dans la version 130 : En-têtes Storage Access. Les nouveaux en-têtes de requête Sec-Fetch-Storage-Access et de réponse Activate-Storage-Access visent à prendre en charge les ressources non-iframe 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 nécessitait un appel d'API JavaScript à 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 :
- Allers-retours réseau multiples : le processus impliquait souvent plusieurs requêtes réseau et rechargements de page avant que le contenu intégré puisse fonctionner pleinement.
- Dépendance iFrame : l'exécution JavaScript imposait l'utilisation d'iFrames ou de sous-ressources dans les iFrames, ce qui limitait la flexibilité des développeurs.
Par exemple, un widget d'agenda de calendar.example intégré à website.example à l'aide de JavaScript uniquement se présentera comme suit :
- Charger un espace réservé :
website.exampledemande le widget. Comme le widgetcalendar.exampleintégré àwebsite.examplen'a pas accès à ses cookies non partitionnés, un widget d'espace réservé est affiché à la place. - Demander l'autorisation : l'espace réservé se charge, puis appelle
document.requestStorageAccess()pour demander l'autorisationstorage-access. - L'utilisateur choisit d'accorder l'autorisation.
- Actualisez le widget : le widget s'actualise, cette fois avec l'accès aux cookies, et charge enfin le contenu personnalisé.
- Chaque fois que l'utilisateur consulte à nouveau un site intégrant le widget
calendar.example, le parcours est exactement le même que celui décrit dans les étapes 1, 2 et 4. La seule simplification est que l'utilisateur n'a pas besoin d'accorder à nouveau 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 en-têtes HTTP
Les nouveaux en-têtes d'accès au stockage permettent de charger plus efficacement le contenu intégré, y compris les ressources non-iframe.
Avec les en-têtes Storage Access, le navigateur récupère automatiquement les ressources avec l'en-tête de requête Sec-Fetch-Storage-Access: inactive défini si l'utilisateur a déjà accordé l'autorisation. Aucune action n'est requise de la part du développeur pour définir l'en-tête de requête. Le serveur peut répondre avec l'en-tête Activate-Storage-Access: retry; allowed-origin="<origin>", et le navigateur relancera la requête avec les identifiants nécessaires.
En-tête de requête
Sec-Fetch-Storage-Access: <access-status>
Lorsqu'un utilisateur accède à une page qui intègre du contenu multisite, le navigateur inclut automatiquement l'en-tête Sec-Fetch-Storage-Access dans les requêtes multisites qui peuvent nécessiter des identifiants (comme des cookies). Cet en-tête indique l'état des autorisations d'accès aux cookies de l'intégration. Voici comment interpréter ses valeurs :
none: l'intégration ne dispose pas de l'autorisationstorage-accesset n'a donc pas accès aux cookies non partitionnés.inactive: l'intégration dispose de l'autorisationstorage-access, mais n'a pas choisi de l'utiliser. L'intégration n'a pas accès aux cookies non partitionnés.active: l'intégration a accès aux cookies non partitionnés. Cette valeur sera incluse dans toutes les requêtes cross-origin 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 l'API Storage Access activée. 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 d'envoyer 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 non-iframe
La mise à jour des en-têtes d'accès au stockage permet d'utiliser l'API Storage Access pour les contenus intégrés non-iframe, comme les images hébergées sur un autre domaine. Auparavant, aucune API de plate-forme Web ne permettait de charger de telles ressources avec des identifiants dans les navigateurs si les cookies tiers n'étaient 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 ou non :
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 un accès au stockage. Si aucun cookie n'est présent et que l'en-tête Sec-Fetch-Storage-Access n'a pas la valeur "inactive", l'image ne se chargera pas.
Flux d'en-tête HTTP
Grâce aux en-têtes HTTP, le navigateur peut reconnaître quand l'utilisateur a déjà accordé l'autorisation d'accès au stockage au widget et charger l'iFrame avec accès aux cookies non partitionnés lors des visites ultérieures.
Avec les en-têtes Storage Access, les visites de pages suivantes déclenchent le flux suivant :
- L'utilisateur consulte à nouveau la page
website.examplequi contient lecalendar.exampleintégré. Comme auparavant, cette récupération n'a pas encore accès au cookie. Toutefois, l'utilisateur a déjà accordé l'autorisationstorage-access, et la récupération inclut un en-têteSec-Fetch-Storage-Access: inactivepour indiquer que l'accès aux cookies non partitionnés est disponible, mais pas utilisé. - Le serveur
calendar.examplerépond avec un en-têteActivate-Storage-Access: retry; allowed-origin="<origin>"(dans ce cas,<origin>seraithttps://website.example) pour indiquer que la récupération de la ressource nécessite l'utilisation de cookies non partitionnés avec l'autorisation d'accès au stockage. - Le navigateur relance la requête, cette fois en incluant les cookies non partitionnés (en activant l'autorisation
storage-accesspour cette récupération). - Le serveur
calendar.examplerépond avec le contenu personnalisé de l'iFrame. La réponse inclut un en-têteActivate-Storage-Access: loadpour indiquer que le navigateur doit charger le contenu avec l'autorisationstorage-accessactivée (en d'autres termes, charger avec un accès aux cookies non partitionné, comme sidocument.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 storage-access. Une fois cette étape effectuée, le widget peut fonctionner comme prévu.
Mettre à jour votre solution
Avec la fonctionnalité d'en-têtes d'accès au stockage, vous devrez peut-être mettre à jour votre code dans deux cas :
- Vous utilisez des RSCA et vous souhaitez améliorer vos performances grâce à la logique d'en-tête.
- Vous disposez d'une validation ou d'une logique qui dépend de la présence ou non de l'en-tête
Origindans la requête sur votre serveur.
Implémenter la logique des 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 avoir 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')
}
});
Consultez la démonstration pour voir comment cette solution fonctionne en pratique.
Mettre à jour la logique de votre en-tête "Origin"
Avec les en-têtes Storage Access, Chrome envoie l'en-tête Origin dans plus de requêtes qu'auparavant. Cela peut affecter votre logique côté serveur si elle repose sur la présence de l'en-tête "Origin" uniquement pour certains types de requêtes (comme celles définies par CORS).
Pour éviter tout problème potentiel, vous devez examiner votre code côté serveur :
- Recherchez toute validation ou 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
Origindans davantage de cas.
Principaux avantages
Les en-têtes d'accès au stockage sont une méthode recommandée et plus performante pour utiliser l'API Storage Access. Ce changement apporte plusieurs améliorations :
- Compatibilité avec les intégrations non iframe : permet d'activer l'analyse de l'accessibilité et de l'assistance pour un plus grand nombre de ressources.
- Utilisation réduite du réseau : moins de requêtes et des 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 à la phase d'évaluation de l'origine
Les essais Origin Trial vous permettent de tester de nouvelles fonctionnalités et de donner votre avis sur leur facilité d'utilisation, leur praticité et leur efficacité. Pour en savoir plus, consultez Premiers pas avec les versions d'essai d'origine.
Vous pouvez essayer la fonctionnalité d'en-têtes d'accès au stockage en vous inscrivant aux phases d'évaluation de l'origine à partir de Chrome 130. Pour participer à la phase d'évaluation de l'origine :
- Accédez à la page d'inscription à la version d'essai des en-têtes d'accès au stockage.
- Suivez les instructions pour participer à l'Origin Trial.
Tester en local
Vous pouvez tester la fonctionnalité d'en-têtes Storage Access en local pour vous assurer que votre site Web est prêt pour ce changement.
Pour configurer votre instance Chrome, procédez comme suit :
- Activez le flag Chrome sur
chrome://flags/#storage-access-headers. - Redémarrez Chrome pour que les modifications prennent effet.
Interagir et envoyer des commentaires
Si vous avez des commentaires ou si vous rencontrez des problèmes, vous pouvez signaler un problème. Pour en savoir plus sur les en-têtes d'accès au stockage, consultez l'explication sur GitHub.