La tâche est prête. Pourquoi le jeton reCAPTCHA est-il rejeté ?
Une tâche ready signifie que solvethree a renvoyé une solution, pas que le site l’a acceptée. Avant de payer une nouvelle résolution, inspectez la requête protégée que votre client a réellement envoyée. La valeur du jeton doit être solution.token.
Sur cette page
Commencez par la requête sortante
{
"id": "example-task",
"status": "ready",
"solution": {
"token": "EXAMPLE_TOKEN",
"userAgent": "EXAMPLE_USER_AGENT",
"secChUa": "EXAMPLE_CLIENT_HINTS"
}
}Dans cet exemple, solution.token est la valeur à soumettre à l’endroit où la cible attend son jeton reCAPTCHA. id identifie la tâche solvethree ; ce n’est pas un jeton. N’envoyez pas non plus l’objet solution complet.
Inspectez la requête sortante finale, pas seulement la variable contenant la réponse. Vérifiez qu’elle contient le jeton actuel, plutôt qu’une valeur vide ou un ancien jeton resté dans le formulaire. Ne consignez pas les jetons dans des journaux partagés.
Faites correspondre le nom d’hôte, l’action et le produit
- Le jeton soumis est correct, mais la cible le rejette toujours.
Comparez le nom d’hôte du site de la tâche avec celui de la requête protégée. Recherchez un sous-domaine ou un environnement différent.
Essayez ceci : Demandez le jeton pour le nom d’hôte prévu et envoyez-le à cette cible. Le site cible doit disposer d’un profil actif accessible à votre espace de travail.
- Un jeton demandé pour une interaction est utilisé pour une autre.
Comparez l’action de la tâche à l’action exacte attendue pour cette requête protégée.
Essayez ceci : Utilisez l’action associée à l’interaction que vous soumettez.
- L’intégration utilise la mauvaise variante de reCAPTCHA.
Examinez recaptchaType dans la requête de tâche. Sa valeur par défaut est enterprise-v3 ; la passerelle accepte aussi v3.
Essayez ceci : Indiquez explicitement le produit utilisé par la cible. Pour Enterprise v3, utilisez enterprise-v3.
Vérifiez l’âge et la réutilisation du jeton, y compris pour Enterprise
Les jetons de réponse de site web reCAPTCHA classique et reCAPTCHA Enterprise expirent après deux minutes et sont à usage unique. Les jetons classiques ne peuvent être vérifiés qu’une fois ; les jetons Enterprise ne peuvent être évalués qu’une fois. Effectuez la résolution juste avant la requête protégée plutôt que de conserver un stock de jetons prêts à l’emploi.
- Si l’envoi est différé, vérifiez le temps écoulé entre la résolution et l’envoi du jeton.
- Si le jeton a déjà été vérifié ou évalué, ne le réutilisez pas pour un autre envoi.
- N’effectuez pas de vérification distincte ni d’évaluation Enterprise uniquement pour tester le jeton avant de l’envoyer à la cible. Ce test peut le consommer.
Conservez le proxy qui a réussi et l’identité renvoyée
- La résolution réussit, mais l’envoi utilise une autre connexion.
Comparez le proxy ayant permis la résolution au proxy utilisé pour la requête protégée. Si vous avez fourni proxyCandidates, ne supposez pas que le premier candidat a réussi.
Essayez ceci : Effectuez l’envoi via le proxy qui a réussi. Changer d’adresse IP entre la résolution et l’envoi peut faire échouer la requête.
- Le client qui effectue l’envoi utilise ses propres en-têtes de navigateur par défaut.
Comparez les valeurs User-Agent et Sec-CH-UA sortantes à solution.userAgent et solution.secChUa.
Essayez ceci : Utilisez l’identité de navigateur renvoyée avec le proxy qui a réussi. N’associez pas le jeton à des valeurs user-agent ou client-hint sans rapport.
Utilisez les détails du rejet pour choisir la prochaine correction
Examinez le corps de la réponse de la cible ainsi que son statut HTTP. Un statut 403 ne suffit pas à identifier la protection qui a rejeté la requête. Recherchez une erreur de jeton explicite ou une incompatibilité de nom d’hôte ou d’action avant de demander un autre jeton.
Si les détails de vérification sont disponibles, consultez le résultat success de reCAPTCHA classique ainsi que les informations de contexte et d’erreur renvoyées. Pour Enterprise, examinez la validité du jeton et les motifs d’évaluation pertinents. Ne supposez pas qu’un score suffit à expliquer le rejet : c’est le site web qui décide comment utiliser l’évaluation.
Si vous ne parvenez toujours pas à identifier la cause, contactez [email protected] en indiquant l’ID de tâche et requestId si utilisé, le produit, l’horodatage, le nom d’hôte et l’action cibles, le statut HTTP ou l’erreur de tâche, ainsi qu’une description de la réponse expurgée des données sensibles. Supprimez les clés API, mots de passe de proxy, jetons, cookies et données client.
Sources et référence de l’API
Toujours bloqué ?
Envoyez au support l’ID de votre tâche et l’erreur reçue.