Задача готова. Почему токен reCAPTCHA отклонён?

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

В этом примере solution.token — значение, которое нужно отправлять там, где целевой сайт ожидает свой токен reCAPTCHA. id идентифицирует задачу solvethree; это не токен. Не отправляйте и весь объект решения.

Изучите окончательный исходящий запрос, а не только переменную с ответом. Убедитесь, что он содержит текущий токен, а не пустое значение или старый токен, оставшийся в форме. Не допускайте попадания токенов в общие журналы.

Отправленный токен корректен, но целевой сайт всё равно его отклоняет.

Сравните имя хоста сайта в задаче с именем хоста защищённого запроса. Проверьте, не используется ли другой поддомен или окружение.

Попробуйте: Запросите токен для нужного имени хоста и отправьте его на этот целевой сайт. Для целевого сайта должен быть активный профиль, доступный вашему рабочему пространству.

Токен, запрошенный для одного взаимодействия, используется для другого.

Сравните action задачи с точным значением action, ожидаемым для этого защищённого запроса.

Попробуйте: Используйте action, соответствующий отправляемому взаимодействию.

Интеграция использует неверный вариант reCAPTCHA.

Проверьте recaptchaType в запросе задачи. По умолчанию используется enterprise-v3; шлюз также принимает v3.

Попробуйте: Явно укажите продукт, используемый целевым сайтом. Для Enterprise v3 используйте enterprise-v3.

Токены ответа для сайтов как в классической reCAPTCHA, так и в reCAPTCHA Enterprise действуют две минуты и могут использоваться только один раз. Классический токен можно проверить один раз; токен Enterprise можно оценить один раз. Выполняйте решение непосредственно перед защищённым запросом, а не накапливайте готовые токены.

• Если отправка происходит с задержкой, проверьте, сколько времени прошло между решением и отправкой токена.
• Если токен уже был проверен или оценён, не используйте его повторно для другой отправки.
• Не выполняйте отдельную проверку или оценку Enterprise только ради тестирования токена перед отправкой на целевой сайт. Такой тест может израсходовать его единственное использование.

Решение проходит успешно, но отправка выполняется через другое соединение.

Сравните прокси, на котором решение прошло успешно, с прокси для защищённого запроса. Если вы передали proxyCandidates, не считайте, что сработал первый кандидат.

Попробуйте: Отправляйте запрос через прокси, на котором решение прошло успешно. Смена IP-адреса между решением и отправкой может привести к сбою запроса.

Отправляющий клиент использует собственные браузерные заголовки по умолчанию.

Сравните исходящие значения User-Agent и Sec-CH-UA с solution.userAgent и solution.secChUa.

Попробуйте: Используйте возвращённые идентификационные данные браузера вместе с прокси, на котором решение прошло успешно. Не сочетайте токен с посторонними значениями user-agent или client hints.

Проверьте не только HTTP-статус, но и тело ответа целевого сайта. Сам по себе 403 не показывает, какая защита отклонила запрос. Прежде чем запрашивать новый токен, поищите явную ошибку токена или несоответствие имени хоста/action.

Если доступны сведения о проверке, проверьте результат success классической reCAPTCHA и возвращённую информацию о контексте и ошибках. Для Enterprise проверьте действительность токена и соответствующие причины оценки. Не считайте, что одна лишь оценка объясняет отклонение: сайт сам решает, как использовать результаты оценки.

Если причину по-прежнему не удаётся определить, напишите на [email protected] и укажите ID задачи и requestId, если он использовался, продукт, временную метку, имя хоста/action целевого сайта, HTTP-статус или ошибку задачи, а также описание ответа без конфиденциальных данных. Удалите API-ключи, пароли прокси, токены, cookie и данные клиентов.