Une API de résolution reCAPTCHA est différente de siteverify
Non : le point de terminaison siteverify de Google ne peut pas émettre de jeton de réponse reCAPTCHA. Il valide un jeton fourni par un client. Les évaluations Enterprise évaluent également un jeton existant ; aucun de ces points de terminaison n’en génère à partir d’une clé de site.
Sur cette page
Choisissez l’API adaptée à votre besoin
| API | Ce que vous fournissez | Ce que vous recevez |
|---|---|---|
| Google siteverify | Un jeton de réponse existant | Un résultat de vérification |
| Évaluations Google Enterprise | Un jeton de réponse existant | Une évaluation de ce jeton |
| Tâches solvethree | Le nom d’hôte d’un site pris en charge, une action et une configuration de proxy | Une tâche dont le résultat prêt contient un jeton de solution |
Dans le flux reCAPTCHA v3 de Google, le SDK client produit un jeton de réponse et le backend du propriétaire du site le valide avec siteverify. Dans le flux Enterprise, le SDK client produit le jeton et le backend crée une évaluation.
Si vous ajoutez une vérification à un site qui vous appartient, utilisez le flux Google approprié. Si vous avez besoin d’un service de résolution pour une cible prise en charge, utilisez l’API de tâches de solvethree. Le service de résolution fournit un jeton que la cible doit évaluer ; il ne remplace pas la vérification effectuée par la cible.
À quoi ressemble une véritable requête de résolution
Vérifiez d’abord qu’un profil actif du site cible est disponible dans votre espace de travail. 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 si ce prérequis n’est pas rempli.
Créez la tâche avec POST /v1/tasks sur l’API solvethree, en utilisant Authorization: Bearer suivi de la clé API de votre espace de travail. Conservez cette clé sur votre serveur.
{
"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 requête cible. site est un nom d’hôte, pas une URL complète. Les requêtes reCAPTCHA exigent exactement un des champs proxy ou proxyCandidates ; n’ajoutez ni type ni url. Cet exemple utilise la valeur par défaut de recaptchaType, enterprise-v3 ; la passerelle accepte également v3.
Récupérez la tâche avec GET /v1/tasks/:id. Continuez à interroger son état tant qu’il est pending ou solving. Seul l’état ready contient une solution utilisable. S’il passe à failed, arrêtez les interrogations et examinez errorCode et error.
Ne consommez pas un jeton Enterprise pour une évaluation de test
Google indique dans sa documentation que les jetons de réponse Enterprise pour les sites web expirent au bout de deux minutes et ne peuvent être évalués qu’une seule fois. Demandez la résolution peu avant la requête protégée. Créer une évaluation simplement pour vérifier que le jeton fonctionne peut le consommer avant que la cible prévue ne l’utilise.
Envoyez solution.token à la cible prévue, et non l’ID de la tâche. Utilisez l’identité du navigateur renvoyée dans userAgent et secChUa, ainsi que le proxy avec lequel la résolution a réussi. Changer de proxy ou combiner des en-têtes de navigateur sans rapport peut faire échouer la requête suivante.
Une tâche à l’état ready signifie qu’une solution est disponible, pas que la cible a accepté votre requête applicative. Déterminez si elle a été acceptée à partir de la réponse de la cible, et non de la création de la tâche ou de son passage à l’état prêt.
Sources et référence de l’API
Lancez votre première tâche.
Démarrez avec $5 de crédit dans votre espace de travail.