Résoudre reCAPTCHA Enterprise avec Python

Installez le SDK Python officiel :

python -m pip install https://solvethree.com/downloads/solvethree_sdk-0.1.0-py3-none-any.whl

1. 1.

   Créer le profil de site

   Configurez le nom d’hôte cible dans la console solvethree et vérifiez que son profil est actif et accessible à votre espace de travail. Envoyer un nom d’hôte dans une demande de résolution ne crée pas de profil. Consultez la configuration du profil de site si vous n’en avez pas encore configuré.

2. 2.

   Définir SOLVETHREE_API_KEY

   Dans le shell ou l’environnement de déploiement qui exécutera le script, définissez SOLVETHREE_API_KEY sur la clé API de votre espace de travail. Conservez-la sur le serveur, pas dans le code du navigateur ni dans un fichier source versionné.

3. 3.

   Définir SOLVETHREE_PROXY

   Définissez SOLVETHREE_PROXY sur l’URL du proxy à utiliser pour la résolution et la requête applicative qui suivra. L’exemple utilise un seul proxy : n’ajoutez donc pas proxyCandidates.

Enregistrez cet exemple sous solve.py. Remplacez accounts.example.com par votre nom d’hôte configuré, sans schéma ni chemin, et remplacez login par l’action utilisée par la page cible.

import os
from uuid import uuid4
from solvethree import Solvethree, SolvethreeError, TaskFailedError

client = Solvethree(os.environ["SOLVETHREE_API_KEY"])
request = {
    "site": "accounts.example.com",  # Use your configured hostname.
    "action": "login",              # Use the page's actual action.
    "proxy": os.environ["SOLVETHREE_PROXY"],
    "requestId": str(uuid4()),
}
try:
    result = client.solve(request, timeout=180)
except TaskFailedError as error:
    raise SystemExit(f"Task failed: {error.error_code}") from None
except SolvethreeError as error:
    # Keep these IDs so an interrupted request can be recovered.
    raise SystemExit(f"Recover request {error.request_id}, task {error.task_id}") from None

solution = result["solution"]
token = solution["token"]
user_agent = solution["userAgent"]
client_hints = solution["secChUa"]
print("Ready task:", result["id"])  # Do not print the token or proxy password.

La requête utilise enterprise-v3 par défaut ; le champ recaptchaType n’est donc pas nécessaire. N’ajoutez pas type ni url : ce ne sont pas des champs de requête reCAPTCHA.

Solvethree est synchrone. client.solve crée la tâche une seule fois, puis interroge son état jusqu’à renvoyer un résultat prêt ou à lever une exception. Ici, timeout=180 limite l’attente du client à 180 secondes. En cas de réussite, le script extrait le jeton, l’agent utilisateur et les indications client sans afficher de valeurs sensibles.

Continuez dans le même script après la résolution. Installez requests séparément, comme indiqué dans l’exemple. Remplacez l’URL de connexion et les données du formulaire par la requête réelle de votre application, en incluant les identifiants, le jeton CSRF et les cookies de session nécessaires.

# Continue after client.solve(). Install requests separately: pip install requests.
import requests

# This example endpoint accepts the standard reCAPTCHA form field.
# Use your application's real URL, form fields, CSRF token and session.
response = requests.post(
    "https://accounts.example.com/login",
    data={"g-recaptcha-response": solution["token"]},
    headers={
        "User-Agent": solution["userAgent"],
        "sec-ch-ua": solution["secChUa"],
    },
    proxies={"http": request["proxy"], "https": request["proxy"]},
    timeout=30,
    allow_redirects=False,
)
# Inspect the application's response to determine whether it accepted the request.
print("Application HTTP status:", response.status_code)

Cet exemple suppose que l’application accepte le jeton dans g-recaptcha-response. Vérifiez la requête réelle plutôt que de supposer qu’elle utilise ce nom de champ. Si le formulaire dépend d’une session existante, envoyez-le via cette session plutôt que d’effectuer une nouvelle requête sans cookies.

Conservez les valeurs userAgent et secChUa renvoyées et utilisez le même proxy que pour la résolution. Changer d’adresse IP ou utiliser une identité de navigateur sans rapport peut faire échouer la requête.

Une tâche prête signifie qu’une solution a été générée, pas que l’application l’a acceptée. Examinez la réponse de l’application et la session obtenue : un statut HTTP seul ne permet pas de confirmer une connexion réussie. Si l’application rejette le jeton, vérifiez la requête sortante avant de payer une nouvelle résolution : elle doit contenir solution.token, et non l’ID de la tâche ou un ancien jeton. Consultez le diagnostic d’un jeton rejeté.

L’exemple génère un nouveau requestId à chaque démarrage du script. Enregistrez cet ID et la requête d’origine avant d’appeler solve si vous devez pouvoir reprendre après un redémarrage du processus. Relancer simplement le script crée une nouvelle requête logique.

• Si une exception contient task_id, utilisez get_task pour reprendre l’interrogation de cette tâche. Ne créez pas de tâche de remplacement simplement parce que la connexion a expiré.
• Si la création a été interrompue et que vous ne disposez que de request_id, renvoyez une demande de tâche identique avec le même requestId. Elle renvoie la tâche existante ; modifier les paramètres de la tâche tout en réutilisant l’ID provoque un conflit.
• En cas de TaskFailedError, cessez d’interroger cette tâche. Examinez ses champs errorCode et error avant de réessayer ; une nouvelle résolution ne corrigera pas des paramètres invalides inchangés. Les résolutions échouées sont remboursées.

Le SDK ne réessaie pas automatiquement de créer une tâche. Il respecte toutefois Retry-After lors d’échecs temporaires d’interrogation, dans la limite du délai de résolution. Pour mieux contrôler l’attente et la reprise, consultez l’interrogation des tâches et les délais d’expiration.