Безопасная обработка результатов задач CAPTCHA в TypeScript

Используйте экспортируемые SDK типы TaskRequest для входных данных и TaskResult для ответов. Сужение типа по статусу позволяет TypeScript различать незавершённую работу, ошибку и готовность без any или приведения типа, которое лишь предлагает компилятору довериться вам.

import { Solvethree, type TaskRequest, type TaskResult } from '@solvethree/sdk';
const client = new Solvethree({ apiKey: process.env.SOLVETHREE_API_KEY! });
const input: TaskRequest = { site: 'accounts.example.com', action: 'login', proxy: process.env.SOLVETHREE_PROXY! };
function inspect(result: TaskResult): void {
  switch (result.status) {
    case 'pending':
    case 'solving':
      console.log('Retrieve this task again:', result.id);
      return;
    case 'failed':
      console.error('Failed task:', result.id, result.errorCode);
      return;
    case 'ready':
      // Solution fields depend on the requested product; check optional fields.
      if (!result.solution.token || !result.solution.userAgent || !result.solution.secChUa) {
        throw new Error('Expected a complete reCAPTCHA solution');
      }
      console.log('Ready task:', result.id);
      // Submit token privately with its browser identity and original proxy.
      return;
  }
}
inspect(await client.createTask(input, { waitMs: 0 }));
// Save the returned ID and call getTask while pending/solving with a deadline.

Пример создаёт одну задачу и проверяет немедленный ответ. Статусы pending и solving означают, что нужно повторно запросить задачу; failed останавливает обработку; ready переводит к проверкам решения. Если вы выносите ветку ready в отдельную функцию, используйте для её параметра экспортируемый тип ReadyTask. Это сужает статус, но не делает обязательными все поля решения, специфичные для продукта.

Проверки проверяют наличие токена и обоих полей идентификации браузера, поскольку эти входные данные запрашивают reCAPTCHA. Они не доказывают, что целевой сайт примет токен. В примере токен намеренно не выводится.

• Используйте Node.js 22+ и установку официального SDK из tarball-архива, описанную в документации API; не предполагайте, что в реестре npm есть опубликованная версия.
• Задайте SOLVETHREE_API_KEY и SOLVETHREE_PROXY в окружении сервера. Утверждения ! не проверяют наличие переменных окружения во время выполнения.
• Замените accounts.example.com и login на нужные имя хоста и действие. Для сайта уже должен быть активный профиль в рабочем пространстве; см. настройку профиля сайта.

В примере опрос оставлен вызывающему коду. Создание должно оставаться вне этого цикла: повторный вызов createTask — не способ проверить, завершилась ли первая задача.

1. 1.

   Сохраните ID из результата создания

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

2. 2.

   Получайте ту же задачу

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

3. 3.

   Остановитесь при конечном результате

   При ready проверьте поля, необходимые для запрошенного продукта. При failed проверьте и errorCode, и error, затем прекратите опрос этой задачи. Обрабатывайте ошибки запросов отдельно: неудачный запрос получения сам по себе не означает окончательный сбой задачи.

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

Выберите обработчик по исходному запросу, затем проверьте ожидаемые поля решения. Одно лишь наличие токена не позволяет отличить ответ reCAPTCHA от значения cookie TMPT.

Отдельное решение Kasada сейчас поддерживает HTTPS-цели на www.ticketmaster.com, а не произвольные сайты. Его обработчик заголовков не является универсальной интеграцией Kasada.

Для каждого продукта отправляйте решение с возвращёнными userAgent и secChUa через прокси, с которым задача была успешно решена. При использовании кандидатов прокси вызывайте successfulProxy(originalTask, readyResult), а не считайте, что сработал первый кандидат. SDK не применяет решение к целевому сайту за вас, а ready не гарантирует принятие последующего запроса.