Cookies de scraping: estado entre ejecuciones

Las cookies de scraping pueden estar presentes en la siguiente ejecución mientras la aplicación considera cerrada la sesión. Un almacén de cookies, una base de datos y un perfil de huella representan estados diferentes. BotBrowser documenta perfiles reutilizables y contextos aislados, pero no garantiza acceso ni restaura un inicio de sesión de terceros. Un trabajo autorizado necesita dos registros: qué estado del cliente cruzó el límite declarado y si la aplicación aceptó la solicitud resultante.

Resumen

• Define si reutilizas pestaña, creas contexto o reinicias el proceso. Los límites son distintos.
• Separa cookies, localStorage, IndexedDB y sessionStorage por alcance y duración.
• Playwright incluye IndexedDB si se habilita expresamente en versiones compatibles; sessionStorage exige otra decisión específica de la aplicación.
• El perfil de huella BotBrowser no sustituye al directorio de datos ni a la captura del framework.
• Usa marcadores inocuos en una fixture propia, excluye secretos del diagnóstico y registra aparte la aceptación del servidor.

Contenido

• Declarar el límite entre ejecuciones
• Cuatro almacenes y cuatro preguntas de continuidad
• Presencia de cookie y elegibilidad de solicitud
• Elegir la transferencia de estado
• Comprobación previa en un origen propio
• Señales de fallo sin causas inventadas
• Identidad BotBrowser y estado de aplicación
• Conclusión práctica

Declarar el límite entre ejecuciones

Nombra la operación de ciclo de vida. Recargar una pestaña, abrir otra independiente, crear un contexto nuevo y reiniciar el proceso son eventos diferentes. El identificador del planificador no define ninguno automáticamente. Conserva contexto y política de almacenamiento con el trabajo para distinguir un contexto intencionadamente vacío de una pérdida inesperada. Iniciar el mismo ejecutable no demuestra persistencia si cada trabajo crea un contexto limpio.

Por ejemplo, una fixture propia puede guardar una preferencia inocua en localStorage y un marcador temporal en sessionStorage. Recargar y crear contexto no son experimentos intercambiables. Lo primero puede mantener la sesión de página; lo segundo necesita transferencia explícita de los almacenes aplicables. Es un diseño propuesto, no una medición realizada. Declara el resultado esperado para cada almacén antes de comparar límites.

Registra origen y revisión de aplicación. El origen incluye esquema, host y puerto; cambiar el puerto de una fixture cambia la pregunta sobre almacenamiento. Las cookies tienen reglas propias de host/dominio y ruta, distintas del origen de localStorage. El modelo de almacenamiento del navegador separa estos alcances. Una lectura correcta en otro origen no observa el almacén original aunque las páginas parezcan iguales.

Declara también qué puede reutilizar el siguiente trabajo. Recopilar datos públicos puede no requerir autenticación; probar una aplicación propia puede usar una cuenta dedicada. Son requisitos de seguridad distintos. No conserves sesiones solo porque existe una función de exportación. La autorización y el acuerdo del servicio deben permitirlo, y el trabajo debe solicitar únicamente el estado necesario. Si necesita limpieza, registra la ausencia como intencional.

Cuatro almacenes y cuatro preguntas de continuidad

La guía de cookies de MDN distingue persistentes con caducidad y cookies de sesión sin ella. La restauración del navegador puede recuperar cookies de sesión; reiniciar no demuestra que desaparecieran todas. Tampoco una caducidad promete conservación hasta ese instante. Retención, elegibilidad de envío y validez en servidor no caben en un único indicador de presencia.

La referencia localStorage de MDN describe almacenamiento por origen entre sesiones sin caducidad intrínseca. No promete conservarlo tras borrado, cambio de contexto o cierre de navegación privada. La aplicación puede aplicar una fecha propia y rechazar valores antiguos. Comprueba almacén y regla declarados; ausencia de caducidad incorporada no significa autenticación permanente.

La referencia sessionStorage de MDN separa datos por origen y contexto superior. Sobrevive a recargas dentro de la sesión; cerrar la pestaña termina esa sesión. Una pestaña con opener puede recibir una copia inicial, pero los cambios posteriores no comparten un almacén vivo. Esa excepción no promete herencia para una ejecución independiente.

La documentación de autenticación de Playwright concreta la transferencia: cookies y almacenamiento local son reutilizables, e IndexedDB se incluye con indexedDB: true, no por defecto. Explica además que el almacenamiento de sesión pertenece a la pestaña y carece de persistencia automática en este flujo. El directorio del navegador puede contener más que una captura del framework; manda su cobertura documentada, no el nombre del archivo.

Almacén	Alcance y ciclo de vida	Comprobación entre ejecuciones
Cookies	¿Qué host/dominio, ruta, seguridad y caducidad aplican?	Metadatos aplicables y observación de solicitud en servidor propio
localStorage	¿Mismo origen y contexto previsto?	Marcador no secreto en ese origen
IndexedDB	¿La captura incluyó la base necesaria?	Opción compatible y marcador de aplicación
sessionStorage	¿Misma sesión de página o pestaña/contexto nuevo?	Marcador de pestaña; no suponer cobertura automática

La tabla guía la transferencia; no especifica una serialización completa. No cubre todo almacén ni todo mecanismo de autenticación. Una caché de service worker, una variable en memoria o una clave de aplicación pueden añadir dependencias. Nómbralas y consulta su ciclo documentado en vez de ampliar artificialmente lo que significa exportar cookies.

Presencia de cookie y elegibilidad de solicitud

RFC 6265 define gestión de estado HTTP y selección de cookies. Nombre y valor omiten alcance importante. Una cookie exclusiva del host difiere de otra de dominio; la ruta puede excluir la solicitud investigada. Conserva atributos en la transferencia autorizada en lugar de convertir todo en pares irrestrictos. El servidor recibe las cookies elegibles, no todo el almacén del navegador.

La referencia Document.cookie describe una interfaz de página, no una exportación universal de credenciales. HttpOnly no está disponible al JavaScript de página. Por tanto, document.cookie vacío no prueba ausencia total de cookies. Usa la interfaz documentada del framework para metadatos autorizados, sin exponer tokens para aparentar un diagnóstico más completo.

Secure y SameSite afectan al envío; una redirección o solicitud entre sitios cambia la pregunta aunque el almacén siga igual. Conserva sitio superior, destino y contexto de navegación sin valores privados. En casos particionados o incrustados, comprueba también la partición documentada. Copiar una cookie no garantiza su envío a toda solicitud de un host de nombre parecido.

La guía de gestión de cookies cubre atributos y configuración. Entre ejecuciones debes comprobar además la aceptación de la solicitud. El servidor puede invalidar la sesión independientemente del cliente. Una cookie retenida puede señalar una sesión caducada o revocada, y aceptar una página pública no autoriza una operación autenticada. Registra el resultado que necesita el trabajo, no solo cuántas cookies hay.

Elegir la transferencia de estado

La API storageState de BrowserContext documenta la captura. En una versión compatible, await context.storageState({ indexedDB: true }) solicita IndexedDB junto al estado admitido. El contexto restaurado es uno nuevo que recibe datos documentados, no la pestaña anterior continuando su ejecución. No restaura automáticamente sessionStorage, conexiones abiertas ni memoria JavaScript arbitraria.

Registra versión del framework y opciones. La API actual puede documentar una opción ausente en tu versión instalada. Resuelve esa incompatibilidad explícitamente, sin presentarla como detección del scraper. Si necesitas IndexedDB, comprueba soporte y habilítalo antes de depender de la transferencia. Espera también la condición de disponibilidad previa a captura: guardar antes de finalizar una escritura puede conservar fielmente un estado incompleto.

Directorios y capturas tienen propiedad operativa distinta. El directorio pertenece al ciclo de almacenamiento del navegador; no debe compartirse casualmente entre procesos independientes concurrentes como sincronización. Usa la configuración persistente admitida por navegador y framework. La captura transfiere datos seleccionados y verificables por separado. Ninguna opción justifica mezclar cuentas o sustituir un contexto limpio requerido por el directorio de otra cuenta.

Trata el estado guardado como sensible. Playwright advierte que esos archivos pueden permitir suplantación y no deben entrar en repositorios. Usa el circuito de secretos con control de acceso, separado de pruebas del blog, capturas y registros ordinarios. El diagnóstico debe contener presencia, marcador no secreto y referencia opaca, no cookies reales, contraseñas ni todo el almacenamiento de una cuenta.

Comprobación previa en un origen propio

Usa una aplicación o fixture controlada. Pon un valor inocuo continuity-marker en cookie legible, localStorage y sessionStorage, y un marcador IndexedDB específico si importa esa base. Usa una cookie sintética, no credenciales. La fixture define cuándo se completan las escrituras y qué debe sobrevivir al límite elegido. Si depende de HttpOnly, el servidor debe observarlo; JavaScript de página no puede hacerlo.

Esta función recibe una página ya situada en el origen propio declarado. Comprueba tres marcadores legibles y devuelve booleanos. El llamador proporciona el marcador inocuo y controla el registro. No navega, crea ni exporta una sesión; la aserción de origen evita leer silenciosamente otro tras una redirección. Es un comprobador ilustrativo, no un resultado de prueba:

export async function checkReadableMarkers(page, ownedOrigin, marker) {
  return page.evaluate(
    ({ ownedOrigin, marker }) => {
      if (location.origin !== ownedOrigin) throw new Error('Origin mismatch');
      const cookies = document.cookie.split(';').map(value => value.trim());
      return {
        cookie: cookies.includes(`continuity-marker=${encodeURIComponent(marker)}`),
        local: localStorage.getItem('continuity-marker') === marker,
        tab: sessionStorage.getItem('continuity-marker') === marker,
      };
    },
    { ownedOrigin, marker }
  );
}

Comprueba ambos lados de un límite con la misma revisión y origen. Guarda hora y tipo de límite junto a los booleanos. Comprueba IndexedDB mediante una lectura de la fixture al terminar la transacción; esta función no lo inspecciona. No comprobar la base es una carencia explícita, no un aprobado implícito. Evita volcados genéricos que expongan datos ajenos a la comprobación.

Finalmente, el servidor propio debe confirmar su solicitud inocua y el resultado necesario. Separa ese resultado de los marcadores cliente. Si sobreviven pero el servidor rechaza, investiga su registro de sesión o autorización. No repitas solicitudes sin permiso para transformar retención en éxito. La comprobación solo satisface las condiciones de la fixture; no prueba aceptación de un tercero.

Señales de fallo sin causas inventadas

Si desaparecen todos los marcadores locales al crear contexto, comprueba primero si debía comenzar vacío o cargar el artefacto previsto. Conserva referencia y operación de creación. Si persiste localStorage pero desaparece el marcador de pestaña, inspecciona el límite de sesión. Ninguna observación identifica detección de huella. Relaciona el almacén perdido con su alcance antes de cambiar ajustes ajenos o aumentar tráfico. Diagnóstico del scraper por capas distingue una transferencia incompleta de un rechazo HTTP recibido o un error de datos de página.

Si una cookie aparece en metadatos permitidos pero falta en la solicitud propia, comprueba destino, ruta, atributos, contexto de sitio y partición pertinente. Si se envía pero la aplicación la rechaza, investiga validez o autorización del servidor. Su presencia en navegador no establece ninguna. Registra resultados separados para distinguir fallo de transferencia y sesión inválida mediante una referencia de artefacto anonimizada.

Si faltan datos solo al restaurar captura, revisa momento y cobertura. Confirma necesidad de IndexedDB, activación de indexedDB: true y finalización de escrituras. Una escritura asíncrona tardía y un almacén omitido dejan señales diferentes. Si una redirección cambia el origen, consérvalo antes de interpretar vacío. No encontrar almacenamiento en el origen equivocado no mide pérdida en el original.

Acota la comprobación y sus efectos. Prefiere lectura de fixture a compra real, mensaje u otra operación modificadora para probar continuidad. Para ante un requisito fallido y consulta su registro. Sin pruebas autorizadas del servidor, registra desconocido. La lista sirve para acotar investigación sin inventar detector ni prometer acceso continuado a la cuenta.

Identidad BotBrowser y estado de aplicación

La gestión de perfiles BotBrowser distingue modelo reutilizable de dispositivo y cookies o ajustes de sesión. Los procesos usan directorios propios; BrowserContexts aíslan cookies y almacenamiento dentro de un proceso. El paquete de huella no es la sesión de aplicación. Reutilizar --bot-profile no llena un contexto nuevo con cookies o localStorage anteriores.

La referencia de configuración de perfiles documenta prioridades y superficies. Conserva referencia del perfil, modificaciones activas y política de estado como entradas distintas. Un cambio horario y una base ausente son observaciones diferentes; no pueden sustituirse. Separa credenciales de paquetes compartidos y verifica almacenamiento del contexto previsto, sin inferirlo de un informe de huella conocido.

La coherencia de identidad expresa intención de configuración; la continuidad de aplicación expresa datos retenidos concretos. La aceptación del servidor es una tercera pregunta. BotBrowser no mantiene viva una sesión de terceros, no otorga autorización ni garantiza aceptación de una captura. Para una integración permitida, el resultado útil combina límite conocido, almacenes requeridos comprobados y resultado de aplicación independiente.

Preguntas frecuentes

¿Bastan las cookies para restaurar una aplicación?

No necesariamente. Puede necesitar localStorage o IndexedDB, y el servidor puede rechazar una sesión retenida. Declara el estado y comprueba aparte el resultado.

¿La captura de Playwright incluye sessionStorage?

No automáticamente en el flujo de autenticación documentado. Pertenece a la sesión de página; transferirlo exige decisión y autorización específicas.

¿Por qué una cookie presente puede no usarse?

Alcance o seguridad pueden excluir la solicitud. Aunque se envíe, validez del servidor y retención del cliente siguen separadas.

¿El mismo perfil BotBrowser restaura las cookies anteriores?

No. Huella y almacenamiento tienen funciones distintas. Usa el ciclo de contexto o datos persistentes previsto, no el paquete como captura de cuenta.

Fuentes

• MDN: Document.cookie
• MDN: cookies HTTP
• MDN: sessionStorage
• MDN: localStorage
• RFC 6265: gestión de estado HTTP
• Playwright: autenticación
• Playwright: BrowserContext storageState
• Playwright: contextos persistentes
• BotBrowser: configuración de perfiles
• BotBrowser: gestión de perfiles
• Modelo de almacenamiento
• Gestión de cookies

Conclusión práctica

Define el límite antes de decidir qué conservar. Comprueba cada almacén necesario en su alcance, usa transferencia documentada y separa secretos y diagnóstico. Perfil de huella, retención cliente y aceptación del servidor contestan preguntas distintas. Continúa el trabajo autorizado solo con su estado y resultado establecidos; la mera presencia de cookies no basta.