Использование API задач CAPTCHA в Make

Сначала настройте в рабочем пространстве активный профиль для целевого имени хоста. Передача site и action не создаёт профиль. Если целевой сайт ещё не настроен, см. настройку профиля сайта.

1. 1.

   Настройте аутентификацию HTTP v4

   Выберите тип аутентификации API key и создайте связку учётных данных Credentials. В поле Key укажите Bearer, затем пробел и API-ключ рабочего пространства; для размещения выберите In the header, а в качестве имени параметра — Authorization. Ограничьте Allowed service origins значением https://api.solvethree.com. Храните ключ в связке учётных данных, а не передавайте его через данные сценария.

2. 2.

   Введите настройки запроса

   Используйте метод, URL, параметр запроса, заголовок и JSON-тело, показанные ниже. Введите каждый элемент в соответствующее поле модуля. В JSON-содержимое запроса нужно поместить только содержимое body; полный пример поясняет конфигурацию и не является импортируемой схемой Make.

{
  "method": "POST",
  "url": "https://api.solvethree.com/v1/tasks",
  "query": {
    "waitMs": "0"
  },
  "headers": {
    "Content-Type": "application/json"
  },
  "body": {
    "site": "accounts.example.com",
    "action": "login",
    "proxy": "http://USER:PASSWORD@PROXY:PORT",
    "requestId": "one-stable-id-for-this-logical-job"
  },
  "authentication": {
    "type": "API key",
    "Key": "Bearer YOUR_PRIVATE_WORKSPACE_KEY",
    "API key placement": "In the header",
    "API key parameter name": "Authorization",
    "Allowed service origins": [
      "https://api.solvethree.com"
    ]
  }
}

• Замените site настроенным именем хоста, а не полным URL. Установите action в соответствии с действием, используемым в целевом процессе.
• Замените proxy URL вашего прокси. Запрос требует ровно одно из полей: proxy или proxyCandidates; в примере используется один прокси.
• Назначайте каждой новой логической операции собственный requestId и сохраняйте его для восстановления. Значение в примере — заглушка, а не ID для повторного использования в несвязанных операциях.
• Не добавляйте type или url в этот запрос reCAPTCHA. Если recaptchaType не указан, используется значение по умолчанию — enterprise-v3.

После успешного ответа на запрос создания сохраните возвращённый ID задачи в привязке к логической операции, прежде чем продолжать работу. Добавьте отдельный модуль HTTP-запроса для получения данных этой задачи.

Обрабатывайте HTTP-ответы с ошибками до выбора ветки по статусу задачи. HTTP-ошибка — не то же самое, что задача со статусом failed; не считайте нечитаемый ответ или ответ с ошибкой очередным результатом pending.

После успешного GET добавьте маршрутизатор с явными фильтрами по возвращённому status. Не направляйте каждый успешный HTTP-ответ в ветку обработки решения.

Задайте явный фильтр для незавершённых задач, а не используйте его как ветку для всех остальных случаев. Отсутствующий или неожиданный статус нужно проверить, а не молча продолжать опрос бесконечно. В ветке ошибок выясните причину указанной ошибки, прежде чем создавать другую задачу; повторные попытки с теми же некорректными данными не помогут.

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

1. 1.

   Выберите начальную ветку

   Если у операции уже есть ID задачи, сразу переходите к GET. В ветку создания должна попадать только новая операция без существующей задачи.

2. 2.

   Завершайте запуски с незавершёнными задачами

   При pending или solving сохраните ID задачи и завершите запуск. При возобновлении запросите данные по тому же ID. Помечайте задачи в конечных статусах как закрытые, чтобы последующие запуски опроса не обрабатывали их результаты повторно.

3. 3.

   Ограничьте число повторений

   Если вместо этого вы добавите повторитель, задайте конечное максимальное число повторений и повторяйте только GET для сохранённого ID. После ready или failed прекратите дальнейший опрос и обработку результата. Достижение лимита повторений означает, что нужно остановиться и сохранить ID, а не создавать задачу на замену.

Для этого запроса reCAPTCHA отправлять нужно значение solution.token, а не ID задачи. При отправке целевому сайту используйте возвращённые параметры идентификации браузера userAgent и secChUa вместе с прокси, на котором решение было успешно получено.

Не предполагайте, что HTTP-модуль Make может использовать предоставленный клиентом прокси сервиса решения для этого финального запроса. Передайте готовый результат клиенту, который поддерживает необходимые прокси и параметры идентификации браузера. ready означает, что решение сгенерировано; его принятие определяется ответом целевого сайта на последующую отправку.