Tester l’API CAPTCHA avec HTTPie

• Installez HTTPie et jq, puis exécutez l’exemple dans Bash. Ces commandes utilisent l’exécutable http de HTTPie, et non curl ou un alias shell de curl.
• Définissez la variable d’environnement SOLVETHREE_API_KEY sur la clé API de votre espace de travail. Exécutez cet exemple sur une machine de confiance ; ne placez pas la clé dans du code exécuté dans le navigateur.
• Configurez un profil actif pour le nom d’hôte cible dans la console. L’envoi d’un nom d’hôte et d’une action ne crée pas de profil. Consultez la configuration du profil de site.
• Remplacez le nom d’hôte, l’action et l’URL du proxy de l’exemple. Utilisez une URL de proxy HTTP ou HTTPS sans chemin, paramètres de requête ni fragment.
• Remplacez la valeur fictive de requestId par un ID unique pour cette tâche logique : 1–64 lettres ASCII, chiffres, traits de soulignement ou traits d’union. Enregistrez-le avant d’envoyer la requête.

La requête concerne reCAPTCHA Enterprise : recaptchaType vaut enterprise-v3 par défaut. Elle nécessite site, action et exactement un des champs proxy ou proxyCandidates ; cet exemple utilise un seul proxy. N’ajoutez pas de champs type ou url.

set -eu
umask 077
# Install HTTPie and jq. Keep the same request.json for recovery.
cat > request.json <<'JSON'
{
  "site": "accounts.example.com",
  "action": "login",
  "proxy": "http://USER:PASSWORD@PROXY:PORT",
  "requestId": "replace-with-one-unique-logical-task-id"
}
JSON
# This file contains proxy credentials; keep it private.
http --check-status --timeout=30 POST https://api.solvethree.com/v1/tasks \
  Authorization:"Bearer $SOLVETHREE_API_KEY" waitMs==0 < request.json > task.json
TASK_ID=$(jq -r '.id' task.json)
http --check-status --timeout=30 GET "https://api.solvethree.com/v1/tasks/$TASK_ID" \
  Authorization:"Bearer $SOLVETHREE_API_KEY" waitMs==15000
# pending/solving: retrieve the same ID again, within a finite deadline.
# ready: use solution. failed: stop and inspect errorCode/error.
# A timed-out POST is recovered with the unchanged file and requestId.

Les chaînes JSON entre guillemets sont placées dans request.json, que HTTPie lit depuis l’entrée standard. L’en-tête Authorization envoie votre clé avec l’authentification Bearer. Gardez request.json privé, car il contient les identifiants du proxy.

waitMs==0 et waitMs==15000 sont des paramètres de requête HTTPie, pas des champs du corps JSON. Le POST ne demande aucune attente ; le GET utilise une attente de 15,000 ms. L’option distincte --timeout=30 de HTTPie définit un délai client de 30 secondes.

La réponse au POST est enregistrée dans task.json, et jq en extrait l’id pour le GET. Exécutez les commandes dans l’ordre. set -eu arrête le script si HTTPie signale un échec, avant qu’une réponse incomplète puisse être utilisée pour la récupération.

--check-status détecte les réponses HTTP en échec. Traitez-les avant de considérer le corps comme une réponse de tâche réussie. Une requête HTTP réussie peut tout de même renvoyer une tâche inachevée ou en échec ; lisez ensuite le champ JSON status.

L’exemple effectue une seule récupération, sans boucle d’interrogation. Lorsque vous soumettez une solution prête à sa cible prévue, utilisez les valeurs userAgent et secChUa renvoyées avec le proxy ayant permis la résolution. Le statut prêt signifie que solvethree a généré une solution, pas que votre requête applicative a réussi.

Un dépassement du délai client ne prouve pas que la création de tâche a échoué. Si vous avez déjà l’ID de tâche, récupérez-la. Si le délai du POST a expiré avant la réception d’un ID, renvoyez le POST avec request.json inchangé, y compris son requestId d’origine. Le même ID et les mêmes entrées de tâche renvoient la tâche existante.

N’extrayez pas d’ID d’un fichier task.json vide ou incomplet ; récupérez d’abord le POST. Ne modifiez pas le proxy, l’action ou les autres entrées de tâche en réutilisant ce requestId : des entrées différentes provoquent un conflit. Utilisez un nouveau requestId uniquement si vous souhaitez créer une nouvelle tâche logique.