Prompt y contexto aplicable
Un sitio offline-first debe detectar cambios en las cookies de inicio de sesión en un Service Worker y actualizar su política de caché. Diseña un enfoque con la Cookie Store API que cubra el scope de suscripción, la semántica de eventos, las condiciones de carrera y el fallback para navegadores no compatibles.
La Cookie Store API proporciona lecturas y escrituras asíncronas de cookies y permite que los Service Workers se suscriban a los cambios de cookies coincidentes. Es una alternativa a la naturaleza bloqueante de document.cookie, pero no modifica las restricciones de same-origin, path, Secure, HttpOnly ni SameSite.
Qué evalúa el entrevistador
Aborda la diferencia entre la API de la página y la API de suscripción del Service Worker, el hecho de que cookiechange concierne a cambios visibles por script, el filtrado por nombre y URL, las suscripciones duplicadas, las carreras de eventos y por qué las cookies no son una base de datos confiable entre diferentes contextos.
Preguntas aclaratorias
Confirma si la cookie es HttpOnly, si su scope cruza diferentes paths, si la página y el Service Worker tienen el mismo origen (same-origin) y qué navegadores deben ser compatibles. Pregunta si el login, logout y refresh pueden competir en condiciones de carrera, si los cambios de caché deben ser inmediatos y cuánto tiempo es aceptable un estado de sesión obsoleto mientras se está offline.
Estructura de respuesta en 30 segundos
“Me suscribiría en el Service Worker a los nombres de cookies y URLs requeridos, luego volvería a leer solo las cookies relevantes tras cookiechange y avanzaría una máquina de estados de sesión idempotente o una versión de caché monotónica. Cookie Store es asíncrona, los eventos solo cubren cambios visibles por script y no proporcionan una transacción ni un orden global, por lo que el handler debe deduplicar y volver a leer el estado actual. Los navegadores no compatibles conservan las comprobaciones de cookies del lado del servidor y la sincronización explícita de páginas; la caché obsoleta nunca es prueba de autenticación.”
Análisis detallado paso a paso
Paso 1: Definir el límite de la API
Las páginas pueden leer y escribir de forma asíncrona a través de window.cookieStore; un Service Worker administra las suscripciones a través de registration.cookies y recibe cookiechange. Ambos permanecen sujetos a la política de cookies y no pueden leer un valor HttpOnly.
Paso 2: Crear la suscripción más pequeña
Suscríbete únicamente a los nombres de cookies requeridos y restringe la URL cuando sea necesario. Las cookies con el mismo nombre en diferentes paths pueden coexistir, por lo que el handler debe usar la información del evento y la URL actual para identificar el objetivo en lugar de adivinar solo a partir del nombre.
self.addEventListener("activate", (event) => {
event.waitUntil(
self.registration.cookies.subscribe([
{ name: "session", url: self.registration.scope },
]),
);
});Paso 3: Tratar los eventos como notificaciones, no como snapshots
El evento describe cambios en las cookies, pero puede ocurrir otro cambio antes de que se ejecute el manejo asíncrono. Vuelve a leer el estado actual con get() o getAll(), y haz que el procesamiento sea idempotente. No trates el objeto de evento como un registro de transacciones o una verdad definitiva.
Paso 4: Separar los cambios visibles por script de los HttpOnly
La especificación solo exige notificaciones para cambios de cookies visibles por script. Un servidor puede establecer o eliminar una cookie HttpOnly sin exponer su valor al Service Worker. Las conclusiones sobre la autenticación siguen proviniendo de las respuestas del servidor, no de la ausencia de un evento.
Paso 5: Modelar la sesión explícitamente
Utiliza estados como desconocido, verificado, sesión cerrada y expirado, y avánzalos a partir de versiones de respuesta, tiempos de expiración o resultados de revalidación. Un cambio de cookie desencadena una verificación; no demuestra por sí mismo el inicio o cierre de sesión.
Paso 6: Manejar condiciones de carrera entre pestañas
Varias páginas pueden refrescar o eliminar una cookie simultáneamente. Fusiona ráfagas cortas de eventos, aplica una única actualización de caché a partir de la lectura más reciente y utiliza una versión de sesión para que un evento antiguo no sobrescriba un estado más nuevo. La eliminación y el precaching de la caché también deben ser idempotentes.
Paso 7: Diseñar un fallback para navegadores no compatibles
Cuando Cookie Store no esté disponible, realiza una sincronización explícita después de navegaciones importantes o respuestas de red, manteniendo al servidor como la fuente autoritativa. No hagas sondeos (polling) de document.cookie en busca de un valor HttpOnly ni relajes la autenticación de la caché debido a la ausencia de la API.
Paso 8: Minimizar la exposición de privacidad y seguridad
Suscríbete solo a los nombres y URLs requeridos por el negocio. Nunca escribas valores de cookies en logs, Cache Storage o postMessage. Mantén las configuraciones de Secure, HttpOnly, SameSite, Path y expiraciones razonables, y limpia las cachés del cliente durante el cierre de sesión.
Respuesta de muestra de alta calidad
Utilizaría Cookie Store como un notificador de cambios, no como una base de datos de autenticación. Durante la activación del Service Worker, crea una suscripción idempotente para los nombres y el scope exactos. Al recibir cookiechange, vuelve a leer el estado actual visible por script, avanza una máquina de estados de sesión idempotente y actualiza o limpia las cachés utilizando una versión de sesión. Los valores HttpOnly siguen siendo validados por el servidor, y la ausencia de un evento nunca demuestra que la sesión no haya cambiado. Fusiona refrescos concurrentes desde múltiples pestañas para que una notificación antigua no pueda sobrescribir un estado más nuevo. Para navegadores no compatibles, mantén la validación del servidor en solicitudes críticas y usa sincronización explícita de página, nunca sondeos de document.cookie como sustituto de la protección HttpOnly. Delimita el scope de las suscripciones y operaciones de caché, y prueba el logout, la expiración, el uso offline y las actualizaciones del Service Worker.
Errores comunes
Tratar cookiechange como un log de auditoría completo
Es una notificación, no una secuencia de transacciones entre procesos. El handler debe volver a leer el estado actual y tolerar trabajo duplicado.
Asumir que un Service Worker puede leer cookies HttpOnly
HttpOnly sigue bloqueando las lecturas por script. Un Service Worker puede pedirle al servidor que valide una sesión a través de una solicitud, pero Cookie Store no revela el valor secreto.
Dejar que cualquier cambio de cookie decida la autenticación de la caché
Los cambios pueden provenir de un refresh, una expiración o de otro path. Espera la validación del servidor y el estado de la versión antes de alterar cachés sensibles a la autenticación.
Preguntas de seguimiento y respuestas
¿Cómo evitas eliminar la cookie con el mismo nombre incorrecta en otro path?
Conserva el scope de la URL al suscribirte y leer, y elimina con el nombre exacto, URL, Path y otros atributos. Si no se puede identificar el objetivo, permite que una respuesta del servidor realice la limpieza en lugar de emitir una eliminación amplia.
¿Puede una actualización del Service Worker perder suscripciones?
Durante la fase de activación del nuevo worker, asegúrate de forma idempotente de que la suscripción exista y vuelve a leer el estado actual de las cookies para reconstruir las cachés. No confíes en la memoria del worker anterior; la inicialización debe ejecutarse después de una actualización.
¿Qué sucede si una cookie expira offline y no hay red?
Marca el estado local como no verificado y limita las capacidades offline; el modo offline no puede extender una sesión de servidor. Revalida primero en cuanto vuelva la conectividad y luego restaura, limpia o degrada la caché.