Cookie Store API : cookies asynchrones et confidentialité
Comprendre les lectures-écritures asynchrones, la visibilité du Service Worker et les limites d’origine du Cookie Store API.
BotBrowser Team
Vous voulez la documentation structurée pour Identité ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
Cookie Store API transforme les opérations sur les cookies en promesses et expose un événement change. Cela ne crée pas un état partagé entre origines et ne contourne pas Secure, SameSite, HttpOnly, Domain ou Path. Cette note distingue le résultat observable par la page, le Service Worker et une autre origine au moyen d’un fixture contrôlé.
Résumé : BotBrowser peut rejouer le fixture avec des cookies synthétiques, mais ne peut pas modifier la politique de cookies du navigateur ni prouver l’état d’un compte serveur. La frontière de connaissance vient de la spécification Cookie Store du WICG et de MDN.
Résumé
L’API est asynchrone, les événements sont des observations locales et le worker doit réconcilier l’état à son activation. L’origine et les attributs du cookie restent les limites de contrôle.
Sommaire
- Opérations asynchrones
- Événements change
- Visibilité du Service Worker
- Confidentialité et validation
Opérations asynchrones
get(), getAll(), set() et delete() renvoient des promesses. Une résolution signifie que ce contexte a accepté la mutation demandée, pas que toutes les requêtes suivantes, un autre onglet ou le serveur verront la valeur. Détectez l’API et séparez les états « indisponible », « écrit », « supprimé » et « refusé », avec une solution de repli de même portée.
Événements change
L’événement cookieStore change sert à actualiser une interface dérivée. Ce n’est ni un webhook ni une preuve de réception côté serveur. Relisez l’état après l’événement et prévoyez les notifications tardives, dupliquées ou manquées. Un Service Worker reste limité par son enregistrement et son origine ; à l’activation, il doit réconcilier l’état après une période d’arrêt.
Visibilité du Service Worker
Utilisez une page HTTPS et un worker de même origine, un profil propre et un marqueur synthétique. Notez la version du navigateur, le contexte sécurisé, les attributs du cookie, l’enregistrement du worker et le résultat visible. HttpOnly n’est pas lisible par script. Une lecture réussie ne prouve ni identité, ni consentement, ni état de compte serveur.
BotBrowser peut préparer des cookies synthétiques avec --bot-cookies dans un BrowserContext déclaré. Il n’accorde pas de permission, n’expose pas HttpOnly et ne modifie pas SameSite. Rejouez le fixture après une mise à jour du navigateur, du worker, des attributs ou de la session.
Confidentialité et validation
À lire ensuite
Voir Storage Access API for Embedded Content et Cookie Management.
Conclusion pratique
Gardez les opérations asynchrones, réconciliez l’état à l’activation du worker et notez la version du navigateur et les attributs du cookie.
Tableau de décision
| Question | À noter | Ne pas déduire |
|---|---|---|
set() est résolu ? | La mutation est acceptée dans cette origine | Persistance serveur ou identité |
change est livré ? | Un contexte éligible observe le changement | Journal d’audit complet |
| Le worker lit le marqueur ? | Cycle de vie et portée actifs | Accès à une autre origine |
Sources
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.