A tarefa está pronta. Por que o token reCAPTCHA é rejeitado?

{
  "id": "example-task",
  "status": "ready",
  "solution": {
    "token": "EXAMPLE_TOKEN",
    "userAgent": "EXAMPLE_USER_AGENT",
    "secChUa": "EXAMPLE_CLIENT_HINTS"
  }
}

Neste exemplo, solution.token é o valor a enviar onde o destino espera seu token reCAPTCHA. id identifica a tarefa do solvethree; não é um token. Também não envie o objeto de solução inteiro.

Inspecione a solicitação final enviada, não apenas a variável que armazena a resposta. Verifique se ela contém o token atual, e não um valor vazio ou um token antigo que ficou no formulário. Mantenha os tokens fora de logs compartilhados.

O token enviado está correto, mas o destino ainda o rejeita.

Compare o hostname do site da tarefa com o hostname da solicitação protegida. Verifique se há um subdomínio ou ambiente diferente.

Experimente: Solicite o token para o hostname pretendido e envie-o a esse destino. O site de destino deve ter um perfil ativo disponível no seu workspace.

Um token solicitado para uma interação é usado em outra.

Compare a ação da tarefa com a ação exata esperada para esta requisição protegida.

Experimente: Use a ação associada à interação que você está enviando.

A integração usa a variante errada do reCAPTCHA.

Confira recaptchaType na requisição da tarefa. O padrão é enterprise-v3; o gateway também aceita v3.

Experimente: Especifique explicitamente o produto usado pelo destino. Para Enterprise v3, use enterprise-v3.

Os tokens de resposta para sites tanto do reCAPTCHA clássico quanto do reCAPTCHA Enterprise expiram após dois minutos e são de uso único. Tokens clássicos podem ser verificados uma vez; tokens Enterprise podem ser avaliados uma vez. Faça a resolução perto do momento da requisição protegida, em vez de manter um estoque de tokens prontos.

• Se houver um atraso antes do envio, verifique quanto tempo passou entre a resolução e o envio do token.
• Se o token já foi verificado ou avaliado, não o reutilize em outro envio.
• Não execute uma verificação separada ou uma avaliação Enterprise apenas para testar o token antes de enviá-lo ao destino. Esse teste pode consumi-lo.

A resolução é concluída com sucesso, mas o envio usa outra conexão.

Compare o proxy usado com sucesso na resolução com o proxy usado na requisição protegida. Se você forneceu proxyCandidates, não presuma que o primeiro candidato teve sucesso.

Experimente: Envie pelo proxy que teve sucesso. Trocar de IP entre a resolução e o envio pode fazer a requisição falhar.

O cliente que faz o envio usa seus próprios cabeçalhos padrão de navegador.

Compare os valores de User-Agent e Sec-CH-UA enviados com solution.userAgent e solution.secChUa.

Experimente: Use a identidade de navegador retornada junto com o proxy que teve sucesso. Não combine o token com valores de user-agent ou client hints sem relação com essa identidade.

Confira o corpo da resposta do destino e também o status HTTP. Um 403, por si só, não identifica qual proteção rejeitou a requisição. Procure um erro explícito de token ou uma incompatibilidade de hostname/ação antes de solicitar outro token.

Se os detalhes de verificação estiverem disponíveis, confira o resultado success do reCAPTCHA clássico e as informações de contexto/erro retornadas. Para Enterprise, confira a validade do token e os motivos relevantes da avaliação. Não presuma que uma pontuação, por si só, explica a rejeição: o site decide como usar a avaliação.

Se ainda não conseguir identificar a causa, entre em contato com [email protected] e informe o ID da tarefa e requestId, se usado, o produto, a data e hora, o hostname/ação de destino, o status HTTP ou erro da tarefa e uma descrição da resposta sem dados sensíveis. Remova chaves de API, senhas de proxy, tokens, cookies e dados de clientes.