Votre vérification API peut partager les cookies du navigateur.

Le test ouvre une page connectée puis appelle une API. On suppose une autre identité parce qu'aucun bouton n'a servi. Dans Playwright, le contexte de requêtes associé peut partager les cookies. Un appel API ne crée pas automatiquement une frontière d'authentification indépendante.

Ce guide utilise l'APIRequestContext, un serveur local et le cookie inventé demo_session. Aucun vrai compte ou secret. Nous montrons le stockage utilisé, pas un contournement d'accès.

Identifiez le contexte créé

browserContext.request et page.request partagent les cookies du navigateur. Les requêtes les utilisent; les réponses peuvent les mettre à jour. C'est utile pour une session volontairement commune, mais influence les preuves.

request.newContext possède un stockage séparé. Choisissez-le pour un état indépendant. L'isolation est un choix préalable, pas une étiquette après une réponse convenable.

const shared = await page.request.get('http://localhost:4181/who');
expect(await shared.text()).toBe('demo_session=fixture');

const isolated = await request.newContext();
try {
  const response = await isolated.get('http://localhost:4181/who');
  expect(await response.text()).toBe('no demo cookie');
} finally {
  await isolated.dispose();
}

Serveur local et cookie inventé préexistant sont requis. Importez request et expect de Playwright. Le serveur ne rapporte que ce cookie contrôlé. Ne publiez jamais de vrais en-têtes de session.

Définissez l'indépendance

Une requête partagée peut lire le résultat par une autre voie avec la même identité. C'est parfois une preuve indépendante du résultat, mais pas un autre utilisateur ou client anonyme. Nommez lecture, identité, stockage ou autorisation.

Un contexte sans cookie est une autre configuration. Il ne prouve pas une politique réelle sans endpoint et réponse attendue établis. Le serveur renvoie une chaîne inventée, pas une certification d'accès.

Copier un état change le sens. La même session copiée n'est pas anonyme. Même sans cookies, des en-têtes ou identifiants peuvent être configurés. Examinez toute la requête.

Montrez les effets des réponses

Le partage fonctionne dans les deux sens. Une réponse partagée peut définir un cookie affectant ensuite le navigateur. La préparation change donc parfois plus qu'un dossier serveur.

Le test définit un deuxième cookie inventé par réponse partagée et le retrouve dans le navigateur. Le contexte isolé reste séparé. C'est un mécanisme, pas une conclusion sur toutes les sessions.

Fermez les contextes jetables. La documentation décrit les corps gardés en mémoire et dispose pour libérer les ressources. Lisez les preuves nécessaires avant suppression.

Écrivez la frontière d'identité

Notez objet de requête, état initial, effets de réponse et identité attendue. Utilisez des sessions autorisées et ne publiez pas fichiers d'état ou en-têtes d'accès.

AnyTest décrit exploration et tests révisables. Demandez si la vérification partage la session ou utilise un état distinct. Aucune implémentation AnyTest n'est affirmée. L'indépendance nomme une frontière, pas seulement un transport.