Effacer les données du site sans franchir les limites du compte
Comprendre ce que supprime l’effacement des données du site, ce qui reste et comment protéger une session lors de la déconnexion.
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.
Réponse courte
Effacer les données du site réinitialise une partie de l’état local, mais ce n’est ni une suppression de compte ni une suppression des dossiers du service. Un navigateur peut conserver des cookies, localStorage, sessionStorage, des bases IndexedDB, Cache Storage, des enregistrements de service worker, des permissions et un cache HTTP. Le service peut encore avoir une session sur son serveur. La spécification Clear-Site-Data définit une demande envoyée par une origine; le navigateur décide de son application.
Il faut distinguer trois limites: l’état du navigateur, l’état du compte de l’application et les données du service. La déconnexion termine la session côté serveur. L’effacement retire l’état local choisi afin qu’un ancien compte ne soit pas restauré. Les sauvegardes, les autres appareils et les autres origines restent séparés. La référence MDN de Clear-Site-Data et l’API StorageManager décrivent des observations, pas une gomme universelle.
Ce qui compte comme donnée du site
Les cookies sont envoyés automatiquement avec les requêtes HTTP correspondantes. En supprimer un peut empêcher le navigateur de présenter un identifiant, mais le serveur doit révoquer ou faire expirer la session. localStorage persiste généralement après la fermeture d’un onglet; sessionStorage appartient au contexte de navigation et se termine normalement avec lui. Ces stockages ne partent pas seuls dans une requête, même si le code peut copier leurs valeurs.
IndexedDB conserve des objets structurés pour les bases locales, les brouillons et les files hors connexion. Cache Storage est souvent géré par un service worker; une ancienne cache peut survivre à une mise à jour ou à une déconnexion. Les enregistrements du worker, les permissions et le cache HTTP ont leurs propres cycles. Le guide du modèle de stockage compare ces mécanismes et le guide du cycle des caches décrit leur nettoyage.
Clear-Site-Data est limité à une origine
La réponse Clear-Site-Data vient d’une origine. Ses directives, comme "cache", "cookies", "storage" et "executionContexts", désignent des catégories que l’agent utilisateur peut nettoyer. Le support varie selon les navigateurs et les versions. Une réponse de compte.example ne peut pas effacer l’état d’une origine tierce ou d’un service intégré.
La directive est donc une demande, pas une preuve. Conservez l’origine, les directives, la version du navigateur et le résultat observé. "storage" ne supprime pas les bases du serveur, les sauvegardes, les autres appareils ni tout l’état en mémoire. Associez-la au code de nettoyage de l’application et à une action de session côté serveur.
Déconnexion et changement de compte
Invalidez d’abord la session du serveur, puis supprimez l’état local propre au compte et réinitialisez la mémoire de l’application. Si l’action serveur échoue, affichez l’erreur et ne présentez pas la session comme terminée. Une autre fenêtre peut encore afficher une ancienne vue; avertissez les autres onglets et vérifiez la session avant toute écriture.
Le changement de compte comporte le même risque. Avant de charger le second compte, supprimez ou isolez les jetons, réponses en cache, brouillons, données IndexedDB, files hors connexion et caches du worker du premier compte. Recharger la page ne nettoie rien. Le contrôle visible doit expliquer ce qui sera retiré et ne doit pas promettre l’effacement d’un compte fournisseur ou de données d’une autre origine.
Suppression partielle et reprise
Une opération peut être bloquée, non prise en charge ou oublier un magasin. Traitez l’absence de données comme un état normal et proposez une page de connexion, une nouvelle récupération ou une reprise documentée. Ne déduisez pas l’identité de la présence d’une seule clé.
Après le nettoyage, la prochaine requête doit exiger une session valide. Une file hors connexion peut appartenir à l’ancien compte: mettez-la en pause ou supprimez-la selon la politique du produit et ne la rejouez jamais sous le compte suivant. Conservez seulement des résultats minimaux, sans cookies, jetons ni contenu.
Contextes isolés pour les essais autorisés
BotBrowser fournit des BrowserContexts distincts avec cookies, stockage et état de session isolés, et permet de tester un parcours autorisé avec deux comptes. BotBrowser ne peut pas contrôler la réponse Clear-Site-Data, le code de nettoyage du site, l’invalidation serveur, l’éviction du navigateur ou les données hors contexte. Voir la documentation d’isolation multi-compte.
Créez deux contextes avec des données synthétiques, notez le navigateur et les magasins attendus, terminez le premier compte puis vérifiez qu’une nouvelle requête exige une authentification. Le second contexte doit garder sa propre session. L’isolement de test ne prouve pas que le service a supprimé ses données.
Liste pratique
- Inventoriez cookies, Web Storage, IndexedDB, Cache Storage, workers, permissions, cache HTTP, mémoire et files hors connexion.
- Donnez à chaque élément un propriétaire, une durée et une classification de compte.
- Invalidez la session serveur, puis nettoyez l’état local et informez les autres onglets.
- Notez directives, navigateur et résultat de
Clear-Site-Data; préparez un repli pour une couverture partielle. - Faites demander une nouvelle authentification et affichez un état vierge ou une reprise documentée.
- Répétez avec deux onglets, un changement de compte, une mise à jour du worker et un second contexte.
Un cadre intégré peut appartenir à une autre origine et gérer ses propres cookies. La page principale ne doit pas promettre de supprimer cet état.
Classez chaque valeur: identifiant, préférence, opération hors connexion ou ressource publique. Cette classe indique s’il faut révoquer, supprimer, conserver ou recréer.
Un cookie expiré n’est pas une session révoquée. Le serveur doit refuser un identifiant réutilisé selon sa politique d’authentification.
Le nettoyage doit être idempotent. Deux exécutions doivent produire le même état sûr même si une base, une cache ou un worker manque.
Vérifiez le worker actif et sa version lorsqu’un déploiement change le nettoyage. Un ancien worker peut encore intercepter une réponse.
Ne déduisez pas le compte de la présence d’un stockage. Le navigateur peut avoir été restauré, partagé ou avoir évincé ses données.
Les messages de conservation doivent distinguer suppression locale et conservation par le service afin de guider le choix de l’utilisateur.
Pour le support, notez l’origine, la version du navigateur, les directives et le résultat de la requête suivante, sans valeur privée.
Les sessions sans mot de passe, cookies d’appareil mémorisé et chargements temporaires ont aussi besoin d’un propriétaire et d’un repli.
Si plusieurs rôles partagent un profil, utilisez des contextes distincts ou une politique explicite. Un sélecteur de compte ne sépare pas le stockage.
Testez une opération bloquée. Les quotas, politiques privées et réglages administrés peuvent rendre un magasin indisponible.
Utilisez des données synthétiques et excluez les identifiants réels des journaux de test.
Expliquez si l’application recharge, revient à la connexion ou conserve une préférence non sensible après l’action.
Le guide de partitionnement du stockage aide pour les cadres intégrés; le partitionnement ne remplace pas le nettoyage du compte.
Une politique de confidentialité peut bloquer une opération pourtant correcte. Traitez ce résultat comme un repli, pas comme une identité.
Le propriétaire de l’origine choisit la durée de conservation des diagnostics et les rôles qui peuvent les lire.
Une réponse vide peut être normale après la déconnexion; l’interface doit la distinguer d’une erreur.
Le serveur doit vérifier l’état lors de chaque opération sensible, pas seulement au premier chargement.
Les préférences non sensibles peuvent rester si cela est expliqué; les jetons et réponses privées doivent avoir une fin claire.
Une migration de schéma doit tester l’absence de données avant le déploiement.
Répétez la vérification après un changement d’attribut de cookie, de code de cache ou de règle de session.
Le journal de test peut contenir catégories et résultats, jamais les valeurs d’un compte.
Les personnes utilisant un appareil partagé ont besoin d’un contrôle visible et compréhensible.
Un effacement d’origine ne doit pas être présenté comme une suppression juridique du compte.
Une file en attente demande une décision explicite à chaque changement de compte.
La documentation de support doit préciser le responsable du navigateur, de l’application et du serveur.
La reprise doit préserver le travail non sensible sans réutiliser une session ancienne.
Questions fréquentes
Effacer les cookies supprime-t-il le compte?
Non. Les cookies locaux disparaissent; le compte, les données serveur et les sessions d’autres appareils restent sous la responsabilité du service.
Clear-Site-Data: "*" efface-t-il tout?
Non. La portée reste celle de l’origine et de l’implémentation du navigateur. Vérifiez les navigateurs pris en charge et expliquez le résultat réel.
Un contexte neuf équivaut-il à une suppression?
Non. C’est un point de départ isolé pour un essai autorisé, pas une commande adressée au serveur ou à une autre origine.
Un service worker peut-il rétablir une donnée?
Oui, s’il garde une réponse en cache ou en mémoire. Versionnez les caches, limitez les données de compte et vérifiez la requête suivante.
Que doit voir l’utilisateur si le nettoyage échoue?
Une connexion, une nouvelle tentative ou une reprise expliquée. Ne prétendez pas que tout est supprimé sans invalidation effective du service.
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.