Обработка CAPTCHA в собственных страницах поиска

Безопасный scope: Это руководство применимо только к собственным или явно авторизованным QA-, staging- и production-средам. Описаны сценарии диагностики, тестирования и наблюдаемости вашей собственной CAPTCHA-интеграции — не для сторонних сайтов и не для несанкционированных workflow.

Неверно выставленный порог CAPTCHA на поиске обходится дороже, чем её отсутствие: слишком мягкий — форма принимает сотни автоматических запросов в минуту, слишком жёсткий — живой пользователь получает проверку на третьем уточнении запроса. Рабочую середину находят измерением: прогоняют один и тот же набор сценариев в staging, смотрят, на каком по счёту запросе включается проверка, и убеждаются, что после её решения поиск продолжается с теми же фильтрами. CaptchaAI закрывает здесь одну задачу — выдаёт валидный токен для вашего staging-домена, чтобы автотест проходил проверку без ручного клика.

Ниже — сценарии регрессии, схема логирования, расчёт потоков под нагрузку CI и таблица типичных сбоев.

Что именно проверяет QA на защищённом поиске

Поиск — не форма логина: у него нет чёткого «успеха» и «отказа», есть выдача, которая должна остаться корректной после прохождения проверки. Отсюда набор проверок:

• Порог срабатывания. На каком по счёту запросе в минуту появляется проверка и совпадает ли это с конфигурацией.
• Сохранение состояния. После решения CAPTCHA пользователь возвращается к своей выдаче с теми же фильтрами, а не на пустую форму.
• Серверная проверка токена. Backend валидирует токен сам; клиентскому флагу «проверка пройдена» доверять нельзя.
• Поведение при отказе. Если провайдер CAPTCHA недоступен, поиск деградирует предсказуемо, а не отдаёт 500.
• Ложные срабатывания. Пользователь, уточняющий запрос пять раз подряд, проверку получать не должен.

Базовый набор сценариев регрессии

Минимальный прогон, который имеет смысл держать в CI и повторять перед каждым релизом поиска:

1. одиночный пользовательский запрос — проверка не появляется;
2. серия из 30 запросов в минуту с одного адреса — проверка появляется;
3. решение CAPTCHA через API — поиск продолжается, фильтры сохранены;
4. восстановление состояния после блокировки — пользователь возвращается к своей выдаче;
5. недоступность провайдера CAPTCHA — понятная ошибка вместо 500.

Порядок важен: 1 и 2 задают границу порога, 3 и 4 проверяют продолжение сессии, 5 закрывает деградацию. Если запускать их вразнобой, накопленный счётчик запросов от предыдущего сценария сдвигает момент срабатывания, и результат перестаёт быть воспроизводимым.

Как подключается CaptchaAI

Схема одинакова независимо от типа проверки: автотест обнаруживает её, отправляет sitekey и pageurl вашего staging-домена в API, дожидается токена и подставляет его в форму так же, как сделал бы браузер. На поисковых формах чаще всего встречаются reCAPTCHA v2 и v3, Cloudflare Turnstile и GeeTest v3 — по каждому типу есть отдельный разбор: reCAPTCHA v2 через API, Cloudflare Turnstile через API, GeeTest v3 через API. Если API-ключа ещё нет, начните с быстрого старта.

Все запросы идут только на собственные или явно авторизованные endpoints — для чужого домена сценарий неприменим.

Сколько потоков нужно прогону

CaptchaAI тарифицируется по потокам, а не по числу решений: поток — одна проверка в работе, освободился — берёт следующую. Для CI считайте пиковую параллельность, а не объём за месяц.

Пример: команда из Алматы держит ночной регрессионный прогон поиска — 40 сценариев, из которых 12 доходят до CAPTCHA, тесты идут в 6 параллельных потоках Selenium. Одновременно в работе не больше шести проверок, значит BASIC ($15/мес, 5 потоков) уже впритык, а STANDARD ($30/мес, 15 потоков) закрывает прогон с запасом на второй стенд. Если добавляется дневной smoke-прогон на каждом merge, смотрите на ADVANCE ($90/мес, 50 потоков). Стоимость при этом не растёт вместе с числом сценариев — растёт только требуемая параллельность.

Время решения влияет на длительность прогона: reCAPTCHA v3 обычно укладывается в 4 с, Cloudflare Turnstile — менее чем в 10 с, GeeTest v3 — менее чем в 12 с, reCAPTCHA v2 может занимать до 60 с. Закладывайте эти цифры в тайм-ауты шагов, иначе тест упадёт по собственному ожиданию, а не по ошибке приложения.

Логи и наблюдаемость

Структурированные логи помогают сравнивать поведение CAPTCHA между релизами и быстро находить регрессии в собственных формах:

import json, time, logging

log = logging.getLogger('captcha-qa')

def record(event: str, **fields) -> None:
    payload = {'ts': time.time(), 'event': event, **fields}
    log.info(json.dumps(payload, ensure_ascii=False))

Минимальный набор полей для каждой попытки: slug, captcha_type, task_id, wait_seconds, verify_status, env. Этого достаточно, чтобы построить дашборд медианы / P90 / P99 по типу CAPTCHA и по среде.

Поле env кажется избыточным до первого разбора инцидента: без него логи staging и production сливаются в одну выборку, и медиана времени ожидания перестаёт что-либо значить. Пишите и версию сборки — тогда рост P99 после релиза виден сразу.

Если в логи попадает поисковый запрос пользователя, это уже персональные данные: для читателей из РФ применим 152-ФЗ «О персональных данных», для трансграничных команд — практики уровня GDPR. Пишите хеш запроса или его длину, а не текст — для метрик CAPTCHA этого достаточно.

Разбор типичных сбоев

Отдельный случай — тест, который проходит через API, но падает в браузере. Обычно дело не в решении CAPTCHA, а в том, что токен подставлен в скрытое поле уже после отправки формы: браузерный тест падает, API проходит.

QA-чек-лист перед релизом

• Запрос отправляется только на собственные или авторизованные endpoints.
• Тестовые учётные записи, события и платежи помечены как фиктивные.
• CAPTCHA-токен проверяется на собственном backend, а не доверяется клиенту.
• Логи содержат task_id, тип CAPTCHA, время ожидания и pass/fail.
• Скрипт возвращает корректный exit code, чтобы CI мог принять решение.
• Сценарии прогоняются в фиксированном порядке, а счётчик запросов сбрасывается между ними.

FAQ

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

Универсального числа нет — порог зависит от поведения ваших обычных пользователей. Снимите распределение запросов на живом трафике, возьмите 99-й перцентиль обычной сессии и ставьте порог выше него, затем подтвердите выбор прогоном в staging.

Нужно ли проверять токен на сервере, если фронтенд уже показал успех?

Да. Клиентский результат — это только UX-сигнал, его можно подделать. Решение о выдаче результатов поиска принимает backend после серверной валидации токена.

Какие типы CAPTCHA закрывает CaptchaAI на таких формах?

reCAPTCHA v2 и v3 (включая Enterprise-варианты), Cloudflare Turnstile и Cloudflare Challenge, GeeTest v3, а также image/OCR, grid и BLS. CaptchaFox (beta), Friendly Captcha (beta) и Lemin (beta) доступны в статусе beta. hCaptcha и FunCaptcha не поддерживаются, GeeTest v4 заявлен как «скоро».

Что делать, если провайдер CAPTCHA недоступен во время прогона?

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

Как сравнивать результаты между релизами?

Сохраняйте логи в одном формате и стройте отчёт по медиане, P90 и P99 на одинаковом наборе сценариев. Сравнивайте только сопоставимые выборки: та же среда, тот же тип проверки, то же число потоков.

Безопасные связанные руководства

• Быстрый старт CaptchaAI
• QA-тестирование CAPTCHA в авторизованных средах
• Тестирование CAPTCHA API на собственных формах
• Отладка: браузерный тест падает, API проходит
• reCAPTCHA v2 через API
• Cloudflare Turnstile через API
• GeeTest v3 через API

Готовы укрепить поиск в собственной app? Подключите CaptchaAI.