Cookie Store API: cookies asíncronas y privacidad
Explica las lecturas y escrituras asíncronas, la visibilidad para Service Worker y los límites de origen del Cookie Store API.
BotBrowser Team
Quieres la documentación estructurada de Identidad?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
Cookie Store API convierte las operaciones de cookies en promesas y expone un evento change. Eso no convierte las cookies en estado compartido entre orígenes ni elimina las reglas Secure, SameSite, HttpOnly, Domain y Path. Esta guía separa el resultado observable en la página, en un Service Worker y en un origen distinto usando un fixture propio de control y candidato.
Resumen: BotBrowser puede repetir el fixture con cookies sintéticas, pero no puede cambiar la política de cookies del navegador ni probar el estado de una cuenta en el servidor. La frontera de conocimiento del navegador procede de la especificación Cookie Store de WICG y de MDN.
Resumen
La API es asíncrona, los eventos son observaciones locales y el worker debe reconciliar el estado al activarse. El origen y los atributos de la cookie siguen siendo los límites de control.
Contenido
- Operaciones asíncronas
- Eventos change
- Visibilidad del Service Worker
- Privacidad y validación
Operaciones asíncronas
get(), getAll(), set() y delete() devuelven promesas. Una promesa resuelta indica que el contexto aceptó la mutación solicitada; no prueba que todas las peticiones posteriores, otra pestaña o el servidor observen el valor. Detecta la API, separa los estados «no disponible», «escrito», «borrado» y «rechazado», y conserva una ruta alternativa con el mismo alcance.
Eventos change
El evento cookieStore change ayuda a actualizar una interfaz derivada. No es un webhook ni una confirmación de recepción del servidor. Vuelve a leer el estado actual después del evento y admite notificaciones tardías, duplicadas o perdidas. Un Service Worker compatible sigue limitado por su registro y origen; al activarse debe reconciliar el estado porque pudo estar detenido cuando ocurrió el cambio.
Visibilidad del Service Worker
Prueba con una página HTTPS y un worker del mismo origen, un profile limpio y un marcador sintético. Registra versión del navegador, contexto seguro, atributos de la cookie, registro del worker y resultado visible. HttpOnly no está disponible para scripts. Un get() correcto tampoco demuestra identidad, consentimiento ni estado de cuenta en el servidor.
BotBrowser puede preparar cookies sintéticas con --bot-cookies en un BrowserContext declarado. No concede permisos, no expone valores HttpOnly ni cambia SameSite. Repite el fixture después de cambios del navegador, worker, atributos o flujo de sesión.
Privacidad y validación
Lecturas relacionadas
Consulta Storage Access API for Embedded Content y Cookie Management.
Conclusión práctica
Mantén las operaciones asíncronas, reconcilia el estado al activar el worker y registra la versión del navegador y los atributos de la cookie.
Tabla de decisión
| Pregunta | Registra | No infieras |
|---|---|---|
¿set() resolvió? | La mutación fue aceptada en este origen | Persistencia del servidor o identidad |
¿Llegó change? | Un contexto elegible observó el cambio | Auditoría completa |
| ¿El worker leyó el marcador? | Ciclo de vida y alcance activos | Acceso a otro origen |
Fuentes
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.