Cookies de scraping : état entre deux exécutions

Des cookies de scraping peuvent être présents au lancement suivant alors que l’application considère la session fermée. Réserve de cookies, base applicative et profil d’empreinte représentent des états différents. BotBrowser documente les profils réutilisables et les contextes isolés, mais ne garantit pas l’accès et ne restaure pas une connexion tierce. Un travail autorisé exige deux relevés : l’état client ayant franchi la frontière déclarée et l’acceptation de la requête par l’application.

Résumé

• Définissez réutilisation d’onglet, nouveau contexte ou nouveau processus. Les frontières diffèrent.
• Séparez cookies, localStorage, IndexedDB et sessionStorage selon portée et durée.
• Playwright inclut IndexedDB sur activation explicite dans les versions compatibles ; sessionStorage exige une décision applicative distincte.
• Un profil d’empreinte BotBrowser ne remplace ni répertoire de données ni capture du framework.
• Vérifiez une fixture propre avec des marqueurs inoffensifs, excluez les secrets et consignez séparément l’acceptation serveur.

Sommaire

• Déclarer la frontière entre exécutions
• Quatre stockages et quatre questions de continuité
• Présence du cookie et admissibilité de la requête
• Choisir le transfert d’état
• Contrôle préalable sur une origine propre
• Signatures de panne sans cause inventée
• Identité BotBrowser et état applicatif
• Conclusion pratique

Déclarer la frontière entre exécutions

Nommez l’opération de cycle de vie. Recharger un onglet, ouvrir un onglet indépendant, créer un contexte et relancer un processus sont des événements différents. L’identifiant de l’ordonnanceur ne les définit pas automatiquement. Gardez contexte choisi et politique de stockage dans la configuration afin de distinguer vide intentionnel et perte inattendue. Relancer le même exécutable ne prouve pas la persistance si chaque travail crée un contexte neuf.

Une fixture propre peut, par exemple, garder une préférence inoffensive dans localStorage et un marqueur temporaire dans sessionStorage. Rechargement et contexte neuf ne constituent pas des expériences interchangeables. Le premier peut garder la session de page ; le second exige un transfert explicite des stockages applicables. C’est un dispositif proposé, pas une mesure réalisée. Déclarez les résultats attendus avant de comparer les frontières.

Consignez origine et révision applicative. Une origine comprend schéma, hôte et port ; changer le port local change la question de stockage. Les cookies suivent leurs règles d’hôte/domaine et de chemin, distinctes de l’origine de localStorage. Le modèle de stockage du navigateur sépare ces portées. Lire sous une autre origine n’observe pas le stockage original, même si les pages se ressemblent.

Déclarez aussi les réutilisations permises. Un travail sur données publiques peut n’exiger aucune authentification ; un test d’application propre peut utiliser un compte dédié. Les exigences de sécurité diffèrent. Ne conservez pas une session uniquement parce qu’un outil sait l’exporter. Autorisation et accord du service doivent permettre cette réutilisation, et le travail ne doit demander que l’état nécessaire. Notez comme intentionnelle l’absence requise par un contexte propre.

Quatre stockages et quatre questions de continuité

Le guide MDN des cookies distingue cookies persistants avec expiration et cookies de session sans expiration. La restauration du navigateur peut récupérer ces derniers : redémarrer ne prouve pas leur disparition totale. À l’inverse, une expiration ne promet pas leur présence jusqu’à cet instant. Rétention, admissibilité d’envoi et validité serveur ne se résument pas à un indicateur de présence.

La référence localStorage de MDN décrit un stockage par origine conservé entre sessions sans expiration intrinsèque. Cela ne garantit rien après effacement, changement de contexte ou fin de navigation privée. Une application peut aussi rejeter une valeur selon son propre horodatage. Vérifiez stockage et règle déclarés ; absence d’expiration intégrée ne signifie pas authentification permanente.

La référence sessionStorage de MDN sépare origine et contexte de navigation supérieur. Les rechargements gardent les données dans la session de page ; fermer l’onglet termine celle-ci. Un opener peut transmettre une copie initiale à un autre onglet, sans créer un stockage vivant partagé ensuite. Cette exception ne garantit pas l’héritage par un lancement indépendant.

La documentation d’authentification Playwright précise la couverture : état réutilisable pour cookies et stockage local, IndexedDB avec indexedDB: true, pas par défaut. Elle explique aussi que le stockage de session est propre à l’onglet et n’est pas automatiquement persisté par ce flux. Le répertoire du navigateur peut contenir davantage qu’une capture ; sa couverture documentée compte, pas son nom de fichier.

Stockage	Portée et durée à vérifier	Contrôle entre exécutions
Cookies	Quels hôte/domaine, chemin, attributs et expiration ?	Métadonnées applicables et requête observée par le serveur propre
localStorage	Même origine et contexte prévu ?	Marqueur non secret à cette origine
IndexedDB	La capture contient-elle la base requise ?	Option compatible et marqueur applicatif
sessionStorage	Même session de page ou nouvel onglet/contexte ?	Marqueur d’onglet ; aucune couverture automatique supposée

Cette matrice guide un transfert, sans spécifier une sérialisation complète. Elle ne couvre pas tous les stockages ou mécanismes d’authentification. Cache de service worker, variable en mémoire ou clé applicative peuvent ajouter des dépendances. Nommez-les et suivez leur cycle documenté, au lieu d’élargir arbitrairement la signification d’un export de cookies.

Présence du cookie et admissibilité de la requête

RFC 6265 définit gestion d’état HTTP et sélection des cookies. Nom et valeur seuls omettent la portée. Un cookie limité à l’hôte diffère d’un cookie de domaine ; le chemin peut exclure la requête. Conservez ces attributs dans le transfert autorisé plutôt que de produire des paires universelles. Le serveur reçoit les cookies admissibles pour la requête, pas tout le réservoir du navigateur.

La référence Document.cookie décrit une interface de page, pas un export universel de secrets. HttpOnly est inaccessible au JavaScript de page. Un document.cookie vide ne prouve donc pas l’absence de cookies applicatifs. Utilisez l’interface documentée du framework pour contrôler des métadonnées autorisées, sans exposer de jetons pour rendre le relevé artificiellement complet.

Secure et SameSite influencent l’envoi ; redirection et requête intersite changent la question même si le stockage reste identique. Conservez site supérieur, destination et contexte de navigation sans valeurs privées. Pour un cas partitionné ou intégré, vérifiez aussi sa partition documentée. Copier un cookie ne garantit pas son envoi à toute requête d’un hôte au nom similaire.

Le guide de gestion des cookies détaille attributs et configuration. Entre exécutions, vérifiez aussi l’acceptation de la requête par l’application. Le serveur peut invalider sa session indépendamment du client. Un cookie conservé peut désigner une session expirée ou révoquée ; accepter une page publique n’autorise pas une opération authentifiée. Gardez le résultat requis par le travail, pas seulement le nombre de cookies.

Choisir le transfert d’état

L’API BrowserContext storageState documente la capture. Dans une version compatible, await context.storageState({ indexedDB: true }) demande IndexedDB avec l’état pris en charge. Le contexte restauré reçoit des données documentées ; ce n’est pas l’ancien onglet poursuivant son exécution. Il ne restaure pas automatiquement sessionStorage, connexions ouvertes ou mémoire JavaScript arbitraire.

Consignez version du framework et options choisies. Une option de la documentation actuelle peut manquer dans une ancienne installation. Traitez cela comme compatibilité à résoudre, pas comme détection du scraper. Si IndexedDB est nécessaire, confirmez le support et activez-le avant de dépendre du transfert. Gardez aussi une condition de disponibilité avant capture : sauvegarder avant la fin d’une écriture peut fidèlement préserver un état incomplet.

Répertoires et captures ont des responsabilités opérationnelles différentes. Le répertoire appartient au cycle de stockage du navigateur ; ne le partagez pas entre processus indépendants simultanés comme mécanisme informel de synchronisation. Utilisez la configuration persistante prise en charge. Une capture transfère des données sélectionnées contrôlables séparément. Aucun choix ne justifie le mélange de comptes ou le remplacement d’un contexte propre requis par le répertoire d’un autre compte.

Traitez l’état sauvegardé comme sensible. Playwright avertit qu’il peut permettre l’usurpation et déconseille son dépôt dans des référentiels. Utilisez le circuit de secrets à accès contrôlé, séparé des preuves du blog, captures et journaux ordinaires. Le diagnostic doit contenir présence, marqueur inoffensif et référence opaque, pas cookies réels, mots de passe ou contenu complet d’un compte.

Contrôle préalable sur une origine propre

Utilisez une application ou fixture contrôlée. Placez un continuity-marker inoffensif dans un cookie lisible, localStorage et sessionStorage, et un marqueur IndexedDB défini par l’application si nécessaire. Le cookie doit être synthétique, pas un secret de compte. La fixture définit fin des écritures et état attendu après la frontière choisie. Pour HttpOnly, le serveur doit observer la dépendance ; JavaScript ne le peut pas.

Cette fonction reçoit une page déjà placée à l’origine propre déclarée. Elle vérifie trois marqueurs lisibles et renvoie des booléens. L’appelant fournit le marqueur inoffensif et contrôle la journalisation. Elle ne navigue pas, ne crée ni n’exporte une session ; l’assertion d’origine évite une lecture silencieuse ailleurs après redirection. C’est un exemple de contrôle, pas un résultat mesuré :

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 }
  );
}

Contrôlez les deux côtés d’une frontière avec mêmes révision et origine. Conservez heure et type de frontière avec les booléens. Vérifiez IndexedDB par une lecture de fixture après fin de transaction ; cette fonction ne l’inspecte pas. Un contrôle absent est une lacune explicite, pas un succès implicite. Évitez les vidages génériques exposant des données applicatives étrangères au diagnostic.

Faites enfin confirmer au serveur propre sa requête inoffensive et le résultat attendu. Séparez-le des marqueurs client. S’ils survivent mais que l’opération est refusée, examinez session ou autorisation côté serveur. Ne répétez pas une requête non autorisée pour transformer la rétention en réussite. Ce contrôle valide seulement les conditions de la fixture, pas l’acceptation d’un service tiers.

Signatures de panne sans cause inventée

Si tous les marqueurs locaux disparaissent avec un nouveau contexte, vérifiez d’abord démarrage intentionnellement vide ou chargement du bon artefact. Gardez référence et opération de création. Si localStorage reste mais que le marqueur d’onglet disparaît, la frontière de session est une différence à examiner. Rien n’identifie une détection d’empreinte. Reliez le stockage perdu à sa portée avant de changer d’autres réglages ou d’augmenter le trafic. Diagnostic du scraper par couche distingue transfert incomplet, refus HTTP reçu et erreur des données de page.

Si un cookie apparaît dans des métadonnées autorisées mais pas dans la requête propre, examinez destination, chemin, attributs, contexte de site et partition pertinente. S’il accompagne la requête refusée, la question devient validité serveur ou autorisation. Sa présence navigateur ne les établit pas. Gardez ces résultats séparés pour distinguer transfert défaillant et session invalide à l’aide d’une référence expurgée.

Si des données manquent seulement après restauration, examinez moment de capture et couverture. Confirmez nécessité d’IndexedDB, activation de indexedDB: true et fin des écritures. Une écriture asynchrone tardive diffère d’un stockage omis. Si une redirection change l’origine, retenez cette route avant d’interpréter un stockage vide. Une lecture à la mauvaise origine ne mesure pas une perte à l’origine initiale.

Bornez le contrôle et ses effets. Préférez une lecture de fixture à un achat réel, un envoi de message ou une autre modification pour vérifier la continuité. Arrêtez sur un prérequis échoué et examinez le relevé. Sans preuve serveur autorisée, notez inconnu. La liste est utile parce qu’elle réduit l’investigation sans inventer un détecteur ni promettre l’accès durable au compte.

Identité BotBrowser et état applicatif

La gestion des profils BotBrowser distingue modèle réutilisable et cookies ou réglages de session. Les processus utilisent leurs propres répertoires ; BrowserContexts isolent cookies et stockage dans un processus commun. Le paquet d’empreinte n’est donc pas la session applicative. Réutiliser --bot-profile ne remplit pas un contexte neuf avec les cookies ou localStorage précédents.

La référence de configuration des profils décrit priorité et surfaces du navigateur. Gardez référence, modifications actives et politique d’état comme entrées distinctes. Changement de fuseau et base absente sont des observations différentes ; aucune ne remplace l’autre. Excluez les secrets des paquets partagés et vérifiez le stockage du contexte prévu plutôt que de le déduire d’un rapport d’empreinte familier.

La cohérence d’identité exprime une intention de configuration ; la continuité applicative décrit des données retenues. L’acceptation serveur est une troisième question. BotBrowser ne maintient pas une session tierce, n’accorde pas d’autorisation et ne garantit pas une capture acceptée. Une intégration permise exige frontière connue, stockages requis contrôlés et résultat applicatif établi séparément.

FAQ

Les cookies suffisent-ils à restaurer une application ?

Pas nécessairement. localStorage ou IndexedDB peuvent être nécessaires et le serveur peut rejeter une session conservée. Déclarez l’état et vérifiez le résultat séparément.

Une capture Playwright inclut-elle sessionStorage ?

Pas automatiquement dans le flux d’authentification documenté. Il dépend de la session de page ; son transfert exige décision et autorisation propres à l’application.

Pourquoi un cookie présent peut-il rester inutilisé ?

Portée ou attributs de sécurité peuvent exclure la requête. Même envoyé, validité serveur et rétention client restent distinctes.

Le même profil BotBrowser restaure-t-il les cookies précédents ?

Non. Paquet d’empreinte et stockage ont des rôles différents. Utilisez le cycle du contexte ou des données persistantes, pas le paquet comme capture de compte.

Sources

• MDN : Document.cookie
• MDN : cookies HTTP
• MDN : sessionStorage
• MDN : localStorage
• RFC 6265 : gestion d’état HTTP
• Playwright : authentification
• Playwright : BrowserContext storageState
• Playwright : contextes persistants
• BotBrowser : configuration des profils
• BotBrowser : gestion des profils
• Modèle de stockage
• Gestion des cookies

Conclusion pratique

Définissez la frontière avant de choisir les données à conserver. Vérifiez chaque stockage requis à la bonne portée, utilisez un transfert documenté et séparez secrets et diagnostic. Profil d’empreinte, rétention client et acceptation serveur répondent à des questions différentes. Ne poursuivez le travail autorisé qu’après établissement de l’état et du résultat requis ; la présence d’un cookie ne suffit pas.