Référence

Chrome DevTools Protocol + CaptchaAI : diagnostic CAPTCHA dans vos environnements de test

Périmètre : ce guide s'applique uniquement à vos propres environnements QA et staging, ou à des environnements explicitement autorisés. Il décrit des étapes de diagnostic et de vérification pour votre propre intégration CAPTCHA, pas pour des sites tiers ni pour des workflows non autorisés.

Le Chrome DevTools Protocol est utile pour observer de manière transparente l'état du navigateur et du réseau dans vos environnements de test. Combiné à CaptchaAI, il ne sert pas de couche d'automatisation, mais de surface de diagnostic précise : vous voyez quand les widgets se chargent, quels sitekeys sont utilisés et comment vos requêtes de vérification arrivent côté backend.


Périmètre sûr

CDP est particulièrement utile en QA quand vous avez besoin de réponses concrètes :

  • Le widget CAPTCHA se charge-t-il au bon moment sur votre page de staging ?
  • Votre page utilise-t-elle le bon sitekey selon l'environnement ?
  • La requête de vérification arrive-t-elle au backend avec les paramètres attendus ?
  • Les codes de réponse, messages d'erreur et événements de télémétrie correspondent-ils à votre documentation de test ?

Pour ces questions, aucune logique de contournement ou de dissimulation n'est nécessaire. Ce qui compte, c'est que les requêtes, les messages console et les réponses serveur restent traçables dans votre propre environnement.


CDP pour le diagnostic réseau

Une session CDP peut rendre visibles plusieurs signaux simultanément :

Observation Pourquoi c'est utile en QA À vérifier
Requête réseau du widget Confirme le chargement du script CAPTCHA Hôte, paramètres, code de statut
État DOM du widget Montre si le sitekey et le callback sont corrects data-sitekey, conteneur, état d'erreur
Requête de vérification Confirme le chemin backend Endpoint cible, identifiant de requête, latence
Réponse serveur Explique succès ou échec du test success, code d'erreur, métadonnées staging

Une configuration CDP minimale pour le diagnostic peut ressembler à ceci :

import http from "node:http";
import WebSocket from "ws";

async function connectToCdp(port = 9222) {
  const targets = await new Promise((resolve, reject) => {
    http.get(`http://127.0.0.1:${port}/json/list`, (res) => {
      let body = "";
      res.on("data", (chunk) => (body += chunk));
      res.on("end", () => resolve(JSON.parse(body)));
    }).on("error", reject);
  });

  const pageTarget = targets.find((target) => target.type === "page");
  const ws = new WebSocket(pageTarget.webSocketDebuggerUrl);

  await new Promise((resolve, reject) => {
    ws.once("open", resolve);
    ws.once("error", reject);
  });

  let id = 0;
  const send = (method, params = {}) => {
    const requestId = ++id;
    ws.send(JSON.stringify({ id: requestId, method, params }));
    return requestId;
  };

  send("Page.enable");
  send("Runtime.enable");
  send("Network.enable");

  return { ws, send };
}

Détecter une sitekey sur une page de test interne

En QA, mieux vaut lire le sitekey directement depuis la page de staging chargée que de le supposer. Vous détectez ainsi tôt les dérives de configuration.

async function readSitekey(pageUrl) {
  const targetResponse = await fetch(
    "http://127.0.0.1:9222/json/new?" + encodeURIComponent(pageUrl)
  );
  const target = await targetResponse.json();
  const ws = new WebSocket(target.webSocketDebuggerUrl);

  await new Promise((resolve, reject) => {
    ws.once("open", resolve);
    ws.once("error", reject);
  });

  ws.send(JSON.stringify({ id: 1, method: "Runtime.evaluate", params: {
    expression: `(() => {
      const widget = document.querySelector('[data-sitekey]');
      if (!widget) return null;
      return {
        sitekey: widget.getAttribute('data-sitekey'),
        widgetType: widget.className,
        pageUrl: location.href,
      };
    })()`,
    returnByValue: true,
  }}));

  return await new Promise((resolve) => {
    ws.on("message", (payload) => {
      const message = JSON.parse(payload);
      if (message.id === 1) {
        resolve(message.result.result.value);
        ws.close();
      }
    });
  });
}

Plus important que la commande du navigateur, l'alignement avec votre configuration de staging :

  • Le sitekey correspond-il à l'environnement attendu ?
  • Le widget est-il chargé uniquement sur les formulaires prévus ?
  • Le nom de callback ou d'action figure-t-il dans vos données de test ?

Envoyer une tâche CaptchaAI depuis un test QA

Une fois la page et le sitekey confirmés depuis votre propre environnement, vous pouvez déclencher une tâche CaptchaAI dans le même test QA et inclure le résultat dans votre chaîne de diagnostic.

async function submitCaptchaTask({ apiKey, pageUrl, sitekey }) {
  const body = new URLSearchParams({
    key: apiKey,
    method: "userrecaptcha",
    googlekey: sitekey,
    pageurl: pageUrl,
    json: "1",
  });

  const submit = await fetch("https://ocr.captchaai.com/in.php", {
    method: "POST",
    body,
  });
  const submitJson = await submit.json();

  if (submitJson.status !== 1) {
    throw new Error(`CaptchaAI submit failed: ${submitJson.request}`);
  }

  for (let attempt = 0; attempt < 30; attempt += 1) {
    await new Promise((resolve) => setTimeout(resolve, 5000));
    const poll = await fetch(
      `https://ocr.captchaai.com/res.php?key=${apiKey}&action=get&id=${submitJson.request}&json=1`
    );
    const pollJson = await poll.json();
    if (pollJson.status === 1) {
      return pollJson.request;
    }
  }

  throw new Error("CaptchaAI result timeout in QA run");
}

L'objectif en QA est de retracer toute la chaîne d'intégration : widget détecté, tâche soumise, résultat reçu. La validation finale doit se faire ensuite contre votre propre endpoint de test.


Vérifier la validation backend

L'étape la plus importante n'est souvent pas dans le navigateur, mais dans votre propre chemin de vérification. Faites en sorte que votre suite QA enregistre la réponse backend avec un identifiant de requête.

async function verifyInQaBackend({ token, testRunId }) {
  const response = await fetch("https://staging.example-app.test/qa/captcha/verify", {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({
      token,
      testRunId,
      expectedAction: "signup",
      environment: "staging",
    }),
  });

  if (!response.ok) {
    throw new Error(`QA verify endpoint returned ${response.status}`);
  }

  return response.json();
}

Une bonne réponse QA contient plus que success: true :

  • identifiant de requête ou de trace,
  • action ou identifiant de widget reconnu,
  • temps de réponse du chemin de vérification,
  • code d'erreur en cas de test négatif,
  • environnement (staging, qa, preprod).

Vous pouvez ainsi rejouer les cas de diagnostic sans toucher à des intégrations en production.


Dépannage

Problème Cause probable Solution
Le widget ne se charge pas Mauvais script ou feature flag Examiner les requêtes réseau et la configuration staging
Le sitekey ne correspond pas Dérive d'environnement Comparer la valeur déployée et la valeur lue dans le DOM
L'endpoint QA renvoie 400 Champs attendus manquants Aligner le journal backend avec votre schéma de test
Timeout pendant le polling File ou limite dans l'environnement de test Augmenter le délai et mesurer la charge séparément
Réponse backend incohérente Données de test différentes entre exécutions Utiliser des comptes de test fixes et des fixtures reproductibles

Guides connexes sûrs

  • Démarrage rapide CaptchaAI
  • Tests QA CAPTCHA dans des environnements autorisés
  • Tester les endpoints CAPTCHA dans vos formulaires web
  • Intégration continue avec des tests CAPTCHA

Analysez votre intégration CAPTCHA avec des données QA traçables — CaptchaAI facilite des exécutions de test reproductibles dans vos propres environnements.

Les commentaires sont désactivés pour cet article.