Migrer une intégration reCAPTCHA de 2Captcha vers solvethree

Cette migration couvre reCAPTCHA v3 Enterprise via l’API v2 de 2Captcha. Elle ne décrit pas l’ancienne API in.php/res.php. De plus, la version de l’API de 2Captcha n’est pas celle du CAPTCHA : solvethree ne prend pas en charge reCAPTCHA v2.

La requête initiale utilise l’enveloppe documentée par createTask de 2Captcha : les identifiants sont placés en dehors d’un objet de tâche propre au fournisseur.

{
  "clientKey": "TWO_CAPTCHA_API_KEY",
  "task": {
    "type": "RecaptchaV3TaskProxyless",
    "websiteURL": "https://accounts.example.com/login",
    "websiteKey": "PUBLIC_SITE_KEY",
    "minScore": 0.7,
    "pageAction": "login",
    "isEnterprise": true
  }
}

Ne reprenezz pas cet objet tel quel dans la nouvelle API. En particulier, le type de tâche sans proxy et minScore n’ont pas leur place dans la requête solvethree ci-dessous.

Commencez par configurer le site cible dans la console solvethree. Votre espace de travail doit disposer d’un profil de site actif avant de pouvoir traiter les demandes pour ce nom d’hôte. L’envoi d’un nom d’hôte et d’une action ne crée pas de profil.

Créez de nouvelles tâches avec POST /v1/tasks sur https://api.solvethree.com, en utilisant Authorization: Bearer avec la clé API de votre espace de travail. Conservez cette clé côté serveur. Le contrat de création des tâches utilise un corps JSON à plat plutôt qu’un objet task imbriqué.

{
  "site": "accounts.example.com",
  "action": "login",
  "proxy": "http://user:[email protected]:8080",
  "requestId": "example_login_001"
}

Remplacez le nom d’hôte, l’action et le proxy de l’exemple par les valeurs de votre cible. Choisissez requestId avant d’envoyer la requête et conservez-le pour récupérer la tâche en cas de dépassement du délai ; utilisez une nouvelle valeur pour chaque nouvelle tâche logique.

L’exemple utilise un seul proxy. Vous pouvez aussi utiliser proxyCandidates, qui accepte au maximum douze URL de proxy HTTP ou HTTPS distinctes, sans chemin, paramètres de requête ni fragment. Envoyez l’un ou l’autre des champs, jamais les deux. Les candidats permettent au service d’essayer d’autres points de sortie ; ils ne garantissent pas qu’un proxy fonctionnera.

Pour les tâches 2Captcha en cours, continuez à utiliser son flux getTaskResult, avec ses identifiants d’authentification, ses identifiants de tâche et sa politique d’interrogation documentée. Un identifiant de tâche externe n’est pas une référence de tâche solvethree.

1. 1.

   Traiter la réponse de création

   Vérifiez si la réponse HTTP indique un échec avant de lire les données d’une réponse de succès. La création reCAPTCHA attend jusqu’à 15 secondes par défaut, mais peut renvoyer une tâche qui n’a pas atteint un état terminal. Si elle est déjà à l’état ready, utilisez la solution sans lancer de boucle d’interrogation.

2. 2.

   Interroger uniquement les tâches inachevées

   Récupérez la tâche solvethree avec GET /v1/tasks/:id. Remplacez l’ancienne vérification de processing par pending et solving ; ces deux états indiquent que la tâche n’est pas terminée. Seul ready contient une solution utilisable.

3. 3.

   Définir l’attente dans l’URL

   L’interrogation GET n’attend pas par défaut. Pour une interrogation longue, définissez le paramètre de requête URL waitMs sur une valeur maximale de 15000, et non un champ JSON. Prévoyez dans le délai d’expiration de votre client HTTP l’attente demandée, plus le temps supplémentaire lié au réseau.

4. 4.

   Arrêter à l’état failed

   Lisez errorCode et error, puis cessez d’interroger cette tâche. Les résolutions échouées sont remboursées. Une erreur telle que site-unreachable nécessite une investigation ; ne supposez pas que chaque échec est un problème de crédit et ne renvoyez pas sans modification des données d’entrée invalides.

Un dépassement du délai de connexion ne prouve pas que la création a échoué. Si vous avez reçu l’identifiant de la tâche, récupérez cette tâche. Sinon, répétez la même requête avec le même requestId pour récupérer la tâche existante au lieu de lancer une autre résolution. Modifier les données d’entrée tout en réutilisant ce requestId provoque un conflit.

Dans votre adaptateur, distinguez les erreurs HTTP des échecs terminaux des tâches. Le contrat d’interrogation et la gestion des échecs décrivent ces deux cas ; ne réutilisez pas l’analyseur des réponses d’erreur de 2Captcha.

Remplacez la recherche du jeton de l’ancien adaptateur par solution.token provenant d’une tâche solvethree à l’état ready. Envoyez ce jeton à l’endroit où la cible attend sa valeur reCAPTCHA, et non l’identifiant de la tâche ou l’objet solution entier.

Lors de l’envoi du jeton, utilisez l’identité de navigateur renvoyée dans userAgent et secChUa, ainsi que le proxy ayant réussi. Si vous avez fourni proxyCandidates, utilisez le proxy ayant réussi plutôt que de choisir un autre candidat pour l’envoi.

Une tâche à l’état ready signifie qu’une solution a été générée, pas que le site web a accepté votre requête applicative. Si la cible la rejette, vérifiez le jeton envoyé, l’action, l’URL cible, le proxy et l’identité du navigateur avant de payer une autre résolution.