Utiliser APIRequestContext de Playwright avec une solution CAPTCHA

1. 1.

   Installer les dépendances

   Utilisez Node.js 22+ et installez le paquet playwright. Installez le SDK JavaScript officiel à partir de l’archive tar de solvethree en version 0.1.0 : solvethree-sdk-0.1.0.tgz, disponible sous /downloads/ sur solvethree.com. Il s’importe sous le nom @solvethree/sdk ; ne supposez pas qu’une version est disponible dans un registre.

2. 2.

   Définir les variables d’environnement

   Fournissez SOLVETHREE_API_KEY, SOLVETHREE_PROXY et TARGET_URL au processus Node.js. Conservez la clé API de l’espace de travail côté serveur. TARGET_URL doit être le véritable point de terminaison POST de l’application, et non simplement la page qui affiche le CAPTCHA. Utilisez une URL de proxy HTTP ou HTTPS sans chemin, paramètres de requête ni fragment.

3. 3.

   Vérifier le profil du site et l’action

   Le nom d’hôte cible doit disposer d’un profil actif accessible à votre espace de travail. Configurez-le dans la console avant de lancer la résolution ; transmettre un nom d’hôte ne crée pas de profil. L’exemple utilise l’action login ; modifiez-la si la cible attend une autre action. La requête utilise reCAPTCHA Enterprise v3 par défaut.

Préparez les champs de formulaire requis par l’application et les éléments nécessaires à la session avant d’exécuter l’exemple. Celui-ci envoie uniquement le champ de réponse CAPTCHA. Consultez la configuration du profil de site si le nom d’hôte n’est pas encore configuré.

import { request } from 'playwright';
import { Solvethree } from '@solvethree/sdk';
const client = new Solvethree({ apiKey: process.env.SOLVETHREE_API_KEY });
const target = new URL(process.env.TARGET_URL);
const proxy = new URL(process.env.SOLVETHREE_PROXY);
const result = await client.solve({ site: target.hostname, action: 'login', proxy: process.env.SOLVETHREE_PROXY });
const proxyConfig = { server: `${proxy.protocol}//${proxy.host}`, username: decodeURIComponent(proxy.username), password: decodeURIComponent(proxy.password) };

const targetClient = await request.newContext({
  proxy: proxyConfig, timeout: 30000,
  extraHTTPHeaders: { 'User-Agent': result.solution.userAgent, 'sec-ch-ua': result.solution.secChUa },
  // storageState: 'your-application-session.json', // only if your flow needs it
});
try {
  const response = await targetClient.post(target.href, {
    form: { 'g-recaptcha-response': result.solution.token }, maxRedirects: 0,
  });
  console.log('Application HTTP status:', response.status());
  // Inspect the response and supply the application's actual fields/CSRF/session.
} finally { await targetClient.dispose(); }

client.solve() crée la tâche une seule fois et interroge son état jusqu’à ce qu’elle soit prête ou qu’une exception soit levée. L’exemple utilise le même proxy pour la résolution et la soumission. Pour Playwright, il sépare l’adresse du serveur proxy de ses identifiants et décode le nom d’utilisateur et le mot de passe.

Le contexte de requête applique solution.userAgent et solution.secChUa comme en-têtes. Le formulaire envoie solution.token dans g-recaptcha-response, et non l’identifiant de la tâche. Conservez ensemble le proxy et l’identité renvoyée ; ne les remplacez pas par des en-têtes de navigateur sans rapport et n’envoyez pas le jeton à une autre cible.

Complétez le formulaire avec les champs réels de l’application, notamment les identifiants ou les données CSRF si nécessaire. Si vous disposez déjà de la session requise par l’application, activez le paramètre facultatif storageState et faites-le pointer vers l’état enregistré de cette session.

APIRequestContext gère son propre magasin de cookies : les requêtes effectuées dans le même contexte conservent donc les cookies qu’il reçoit. Il ne partage pas automatiquement les cookies avec un contexte de navigateur distinct. Effectuez les éventuelles requêtes préalables de session et le POST final dans le même contexte lorsqu’ils doivent partager des cookies. Le bloc finally libère le contexte une fois la soumission terminée.

L’exemple journalise le statut HTTP de l’application ; il ne prouve pas que la connexion a réussi. Avec maxRedirects défini sur zéro, vous voyez la réponse initiale au lieu de suivre une redirection. Examinez son corps, ses en-têtes et ses cookies en les comparant à la réponse de réussite attendue par l’application. Une redirection ou un statut HTTP 200 ne suffit pas nécessairement à déterminer si l’opération a réussi.

La tâche est prête, mais l’application rejette le POST.

Examinez d’abord la requête sortante : champ du jeton, nom d’hôte et action, proxy, identité renvoyée, champs de formulaire requis, valeur CSRF et cookies de session.

Essayez ceci : Corrigez les données de requête manquantes ou incohérentes avant de payer une nouvelle résolution. Une tâche prête fournit une solution utilisable, mais ne garantit pas son acceptation par l’application cible.

La résolution se termine par une tâche en échec.

Lisez errorCode et error ; ne considérez pas chaque échec comme un problème de crédits.

Essayez ceci : Arrêtez d’interroger cette tâche et traitez la cause signalée. Les résolutions en échec sont remboursées. Pour interpréter les erreurs, consultez la gestion des erreurs de l’API.

La création de la tâche dépasse le délai imparti ou la connexion est interrompue.

Déterminez si vous disposez d’un identifiant de tâche ou si vous avez utilisé un requestId. Un délai de connexion dépassé ne prouve pas que la création a échoué.

Essayez ceci : Récupérez la tâche existante si vous disposez de son identifiant. Pour pouvoir reprendre une requête de création, fournissez un requestId et réutilisez-le avec exactement les mêmes données d’entrée ; cela renvoie la tâche existante. Ne lancez pas immédiatement une nouvelle résolution distincte.

La requête adressée à l’application renvoie une erreur HTTP.

Examinez la réponse de la cible séparément du résultat de la tâche solvethree.

Essayez ceci : Traitez la réponse d’échec avant d’interpréter son corps comme des données de réussite. Corrigez la requête adressée à l’application ou l’erreur serveur signalée plutôt que de supposer que le jeton en est la cause.