reCAPTCHA v3 и v2: обязанности владельца сайта

Практический выбор между reCAPTCHA v3 и v2 зависит от того, какое взаимодействие и какие серверные обязанности способен поддерживать сайт. V2 checkbox предусматривает явное действие пользователя; v2 invisible всё ещё может показать задание; v3 возвращает оценку, которую сайт должен превратить в решение приложения. BotBrowser предоставляет средства управления браузером на основе профилей для воспроизводимой клиентской среды, но не гарантирует нужный результат политики сайта, не выбирает эту политику, не проверяет токен провайдера за сайт и не раскрывает посетителю закрытую оценку. У существующей интеграции должны быть назначены ответственные и за браузерный сценарий, и за обработку серверного результата.

Эти названия относятся к существующим классическим веб-интеграциям, включая поддерживаемые интеграции, сохранённые после переноса учётной записи. Актуальная документация Google Cloud по ключам сопоставляет CHECKBOX с прежней v2 Checkbox, INVISIBLE с прежней v2 Invisible, а SCORE с прежней v3. Рекомендации Google по миграции подтверждают, что существующий клиентский код и серверные вызовы могут продолжать работать. Уведомление об устаревании классических руководств не означает прекращения работы этих развёрнутых контрактов; для новых возможностей Cloud и процедур миграции нужна их собственная актуальная документация.

Кратко

• Сравнивайте три реальные веб-интеграции: v2 checkbox, v2 invisible и v3. Invisible v2 не является другим названием v3.
• Каждая интеграция требует проверки токена на сервере. Успешный браузерный callback не разрешает отправку формы.
• В v3 сайт должен проверить ожидаемый action и определить, что возвращённая оценка означает для конкретной операции. Отсутствие головоломки не устраняет эту работу.
• Выберите взаимодействие, которое приложение способно объяснить пользователю и восстановить после ошибки, затем назначьте конкретных ответственных за серверные проверки и итог операции.
• Классические руководства Google теперь содержат уведомление об устаревании. Актуальная документация Cloud сопоставляет прежние названия и поддерживает существующие интеграции; проверяйте фактически используемые ключ и API, прежде чем применять это сравнение к любому современному продукту.

Содержание

• Матрица выбора для существующей веб-интеграции
• Браузерный сценарий меняет опыт пользователя
• Серверная проверка остаётся обязательной
• V3 добавляет политику для action и оценки
• Контрольный список обязанностей по реализации
• Три условных выбора и пути их отказов
• Практический вывод

Матрица выбора для существующей веб-интеграции

Сравнение версий Google отделяет варианты v2 с флажком и invisible от v3. Сравниваются документированные контракты их веб-интеграций, а не измеренная эффективность защиты. Сайт, уже использующий один из этих контрактов, может оценить изменение через обязанности, которые после него появятся у интерфейса и сервера. Посетитель, пытающийся объяснить отказ, решает другую задачу и обычно не имеет серверных записей, необходимых для такого решения.

У терминологии есть актуальная граница применения. Документация Google по ключам сопоставляет SCORE с прежней v3, CHECKBOX с прежней v2 Checkbox, а INVISIBLE с прежней v2 Invisible. Она также описывает другие типы интеграции. Поэтому старые названия полезны для определения существующих реализаций, но не описывают весь нынешний набор продуктов. Матрица ниже относится к названным классическим веб-сценариям и документированной модели их проверки; она не рекомендует по умолчанию начинать новое развёртывание Cloud со старого API.

Критерий решения	V2 checkbox	V2 invisible	V3
Первое действие пользователя	Нажать на показанный флажок	Запустить проверку кнопкой или JavaScript API; начального нажатия на флажок нет	Запустить проверку для действия сайта без прерывающего этот сценарий задания CAPTCHA
Возможное задание в документированном сценарии	Проверка может завершиться сразу или показать задание	Задание может появиться, несмотря на невидимую точку входа	Возвращается оценка; дальнейший ответ выбирает сайт
Обязанности браузерной интеграции	Отобразить нужный виджет и обработать завершение, истечение срока и ошибки	Связать запуск с нужной операцией и обработать завершение, истечение срока и ошибки	Выполнить проверку для нужного action и своевременно отправить токен серверу
Обязанности серверной проверки	Проверить ответный токен через документированный серверный endpoint	Проверить ответный токен через документированный серверный endpoint	Проверить ответный токен и ожидаемый action
Обязанности политики приложения	Решить, разрешена ли проверенная операция правилами приложения	Решить, разрешена ли проверенная операция правилами приложения	Интерпретировать оценку в контексте операции и применить политику сайта
Причина рассмотреть этот контракт	Явный шаг с флажком соответствует существующему пути пользователя	Существующая форма должна запускать проверку своей кнопкой, сохраняя возможность задания	Сайт способен отвечать за контекстную обработку оценки и последующий путь пользователя или модерации
Причина отложить изменение	Интерфейс не поддерживает нужное взаимодействие или восстановление после ошибки	Команда не спроектировала возможное задание и состояния callback	Никто не отвечает за проверку action, обработку оценки или ответ приложения

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

Для существующих ключей нужна также административная инвентаризация. Актуальные рекомендации Google по миграции Classic сообщают, что поддерживаемые существующие интеграции могут сохранить клиентский код и серверные вызовы, продолжая использовать siteverify после миграции. Это не делает перенос учётной записи той же операцией, что и переход с v2 на v3. Прежде чем решать, какие обязанности действительно меняются, отдельно зафиксируйте владельца ключа, используемую клиентскую интеграцию и серверный endpoint.

Браузерный сценарий меняет опыт пользователя

В v2 checkbox сайт отображает виджет, предлагающий посетителю нажать на флажок. Руководство Google по отображению v2 поддерживает автоматическое либо явное отображение после загрузки библиотеки. Выбор влияет на инициализацию элемента приложением, особенно если форма появляется динамически. Сам по себе видимый флажок не доказывает, что обработчик отправки приложения прикрепит правильный ответный токен к правильной операции.

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

V2 invisible меняет точку входа. Руководство Google по invisible допускает автоматическую привязку к кнопке, программную привязку к кнопке или программный вызов. Поэтому обычная кнопка отправки может начать проверку без предварительного флажка. Однако такая интеграция всё ещё может запросить задание. Название invisible не обещает, что весь путь в приложении останется без видимой проверки, и не предоставляет сайту документированный контракт ответа с оценкой, характерный для v3.

Callback является частью управления состояниями формы. При invisible приложение может сначала проверить обычные поля, затем вызвать проверку и отправить форму после callback завершения. Официальный пример invisible иллюстрирует эту последовательность. Реальному приложению всё равно нужно предотвращать ситуацию, когда посторонний callback, повторное нажатие кнопки или устаревшее состояние формы принимается за завершение текущей операции. Это требование к связям внутри приложения, а не утверждение, что клиентская библиотека Google предоставляет менеджер транзакций приложения.

V3 вместо этого связывает выполнение с action и возвращает токен для серверной оценки. Руководство по v3 описывает привязку к кнопке и программный вызов и рекомендует выполнять проверку при действии пользователя, а не при загрузке страницы, поскольку срок токенов ограничен. Долго открытая страница оформления заказа не может считать первоначальную загрузку постоянным событием проверки. Ответственный за клиент должен определить фактическую защищаемую операцию и момент получения её токена.

Доступность остаётся частью пользовательского пути независимо от выбранного контракта. Настройки отображения описывают язык и tabindex, а руководство invisible также описывает положение значка и обработку callback. Эти возможности не подтверждают доступность окружающей формы. Проверяйте порядок фокуса, сообщения о состоянии и поддерживаемый путь восстановления сайта с фактически настроенным виджетом. Отсутствие задания CAPTCHA в v3 также не доказывает удобство дополнительного шага, выбранного приложением; за добавленное поведение отвечает сам сайт.

Серверная проверка остаётся обязательной

Общая серверная обязанность конкретнее и уже, чем формулировка «браузер прошёл проверку». Руководство Google по проверке требует отправки сервером POST на https://www.google.com/recaptcha/api/siteverify с секретом и ответным токеном. Параметр remoteip указан как необязательный. Хранение секрета на сервере входит в обязанности этой интеграции; получение токена через callback означает только передачу от клиента приложению и не заменяет запрос к провайдеру.

То же руководство ограничивает каждый ответный токен двумя минутами и одной проверкой. Сервер, поставивший токен в очередь работ с неопределённой задержкой, не сохраняет действительную проверку только потому, что исходный callback завершился. Уже проверенный запрос не может использовать этот токен как многократное удостоверение сеанса для посторонних операций. Когда нужен новый ответ, приложению требуется новый документированный сценарий, тогда как его собственные средства управления сеансом и транзакциями сохраняют отдельное назначение.

Справочник серверных ошибок различает отсутствующие или недействительные секреты, отсутствующие или недействительные ответы, некорректный запрос и timeout-or-duplicate. Последняя ошибка объединяет две возможности: ответ слишком старый либо уже использован. Сама по себе она не указывает, какая из них произошла. Ответственный может сопоставить время со своими вызовами проверки для расследования, но не должен превращать эту документированную объединённую ошибку в конкретный отказ браузера без соответствующих доказательств.

У проверки есть и контракт ответа. Классический веб-ответ документирует success, challenge_ts, hostname и необязательные error-codes; ответ v3 дополнительно документирует score и action. Поле challenge_ts описывает время загрузки задания, а не момент завершённой бизнес-транзакции. Поле hostname предоставляет документированный контекст сайта, а не доказательство того, что правила учётной записи или оформления заказа разрешили операцию. Сохраняйте эти значения полей при проектировании серверных проверок и сообщений об инцидентах.

Ответственному за сервер нужен заранее определённый результат на случай, когда проверку невозможно завершить. Сетевой тайм-аут endpoint проверки, ответ с success: false и проверенный токен с последующим отказом приложения представляют собой три разных состояния. Протокол проверки определяет обмен с провайдером; сайт должен решить, как собственный endpoint сообщает и обрабатывает каждое состояние. Необработанное исключение или неоднозначное сообщение «попробуйте снова» не должно незаметно считаться подтверждённым доступом.

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

V3 добавляет политику для action и оценки

Поле v3 action представляет соглашение между клиентским вызовом и ожиданием сервера. Google требует при проверке ответа удостовериться, что имя action соответствует ожидаемому. Рекомендации по action также ограничивают имена буквами и цифрами, косыми чертами и подчёркиваниями и запрещают привязывать их к конкретному пользователю. Сайт должен определять имена операций, а не кодировать в этом поле адрес электронной почты, идентификатор учётной записи или другие сведения о личности пользователя.

Ожидаемое значение должно исходить из серверного понимания операции. Простое копирование имени action, переданного вызывающей стороной, в поле «ожидаемое» не устанавливает соответствия нужному endpoint. Для существующей операции входа ответственный за сервер должен до проверки возвращённого значения знать, какой документированный action относится к этой операции. Это следствие требования Google к ожидаемому action, а не новый API провайдера или утверждение, что какой-либо конкретный сторонний сайт правильно выполняет это требование.

Оценка является ещё одним возвращённым полем, а не вердиктом приложения. Документация v3 описывает диапазон от 0.0 до 1.0 и контекстные ответы, например дополнительную аутентификацию или модерацию. Поэтому выбор v3 создаёт обязанность по политике сайта: ответственный должен определить подходящий ответ для каждого защищаемого действия и того, кто рассматривает неожиданные результаты. Ни универсальный порог, ни рецепт настройки браузера не заменяет это решение для всех приложений.

Google также сообщает, что сервис обучается на реальном трафике, поэтому оценки в staging или вскоре после внедрения могут отличаться от production. Это уточнение о среде существенно при приёмке смены версии. Форма staging, дошедшая до страницы успеха, доказывает лишь заявленный результат интеграции staging; она не устанавливает распределение производственных оценок или пригодность политики приложения. Отделяйте корректность проверки от последующей оценки эксплуатационных решений сайта.

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

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

Контрольный список обязанностей по реализации

Контрольный список ниже превращает матрицу в передачу обязанностей между командами приложения. Ожидаемый результат состоит в наличии назначенного ответственного и документированного ответа для каждой обязанности выбранного контракта. Это проектный список проверок, а не записанный ответ провайдера или доказательство поведения развёрнутого сайта. Требования Google к проверке и контракт action в v3 задают обязательства перед провайдером; связи операций внутри приложения и выбор восстановления принадлежат сайту.

Назначаемая обязанность	Доказательства, которые должен предоставить ответственный	На какой выбор влияет
Инвентаризация ключей и интеграций	Настроенный продукт, владелец ключа и имена клиентского／серверного API без раскрытия секретов	Подтверждает, какой существующий контракт сопровождается
Инициализация браузера	Путь отображения виджета или запуска, нужная защищаемая операция и обработка завершения／истечения срока／ошибок	Различает флажок, запуск invisible и выполнение action v3
Проверка токена	Серверная обработка документированного запроса проверки и возвращённых состояний отказа	Требуется каждой сравниваемой интеграции
Ожидаемый action	Определённый сервером action каждого защищаемого endpoint и проверка возвращённого поля v3	Требуется контрактом v3
Ответ на оценку	Ответственный за политику приложения и поддерживаемый исход каждой соответствующей операции	Позволяет использовать оценку v3, не смешивая её с разрешением операции
Результат приложения	Обычные проверки аутентификации или транзакции и однозначный результат для пользователя	Остаётся обязанностью сайта после проверки провайдером
Восстановление и поддержка	Способ различать инициализацию клиента, истёкший ответ, серверную проверку и отказ приложения	Не даёт свести все отказы к одной необъяснённой ошибке CAPTCHA

Инициализация клиента заслуживает отдельного приёмочного случая. Руководство по отображению v2 требует, чтобы onload callback явного отображения существовал до загрузки API. Это создаёт реальное требование к порядку для приложений, асинхронно загружающих компоненты и скрипты. Ответственный за клиент должен проверить выбранный путь отображения, а не предполагать, что наличие api.js на вкладке сети доказывает готовность элемента к моменту отправки формы. Событие загрузки библиотеки и пригодное к работе состояние формы составляют разные условия приёмки.

Callback истечения срока и ошибки также требуют видимой обработки. Настройки invisible Google описывают эти callback и возлагают на приложение обязанность сообщить пользователю о повторной попытке, если приложение задаёт callback ошибки. Решение по сопровождению должно включать сообщение и разрешённое действие восстановления, а не только имя callback. Сервер обязан независимо обработать истёкший или недействительный ответ, даже если клиент показал информативное сообщение.

Справочник BotBrowser по согласованности автоматизации может поддержать повторяемую конфигурацию браузера, когда команда проверяет своё приложение с разрешением. Эта возможность помогает сравнивать поведение одной формы в заявленной среде. Она не реализует серверные обязанности списка, не выдаёт учётные данные сайта и не устанавливает оценку провайдера по локальным наблюдениям браузера. Проверка формы должна сообщать фактически проверенное условие приложения, отдельно фиксируя выбранную версию интеграции и выводы о доступе.

Три условных выбора и пути их отказов

Рассмотрим условную существующую форму поддержки с v2 checkbox. Её владелец хочет убрать начальный флажок, сохранив сценарий, способный показать задание. Сравнение документированных вариантов v2 делает v2 invisible подходящим для рассмотрения контрактом. Конкретная работа включает запуск кнопкой, связь callback с операцией и восстановление пользовательского пути; серверная проверка остаётся обязательной. Название «переход на v3» неверно определило бы и выбранный клиентский сценарий, и отсутствие новой обязанности по политике оценки v3.

Теперь рассмотрим условное приложение, которому нужна v3 для операции входа. Клиент может вызвать v3, но команда не назначила ответственных за проверку ожидаемого action и реакцию на оценку, требующую дополнительного шага. Рекомендации Google по action и интерпретации v3 указывают на недостающие обязанности. Матрица предлагает отложить развёртывание, пока не определены ответственные и исходы приложения, а не выводить готовность из появления токена в браузерном callback. Этот пример не представляет реального запуска провайдера или измеренной оценки.

Наконец, предположим, что условная сопровождаемая интеграция v3 получает ответ провайдера с success: true, но приложение отклоняет отправку. Сервер должен различать проверку токена, проверку возвращённого action и результат собственной политики. Определение ответа v3 разделяет эти поля и обязанности; success не обещает успешного входа. Без соответствующей серверной записи внешний наблюдатель не может решить, связан ли отказ с action, состоянием учётной записи или другим правилом приложения.

Эти сценарии приводят к разным ответственным, даже если пользователь видит одну общую ошибку. Сломанный путь инициализации относится к клиентской интеграции; недействительный запрос проверки относится к серверу; действительная оценка с последующим предусмотренным ограничением относится к ответственному за политику приложения. Если задание вместо этого прерывает разрешённый сбор данных на другом сайте, диагностика CAPTCHA во время сбора рассматривает переход запроса и согласованное восстановление. Матрица версий не разрешает исследовать скрытую политику сайта или продолжать извлечение вопреки его решению о доступе.

Вопросы и ответы

Всегда ли reCAPTCHA v3 лучше v2?

Документированные контракты поручают сайту разную работу. V3 убирает взаимодействие CAPTCHA из собственного сценария, но требует контекстной обработки оценки и проверки ожидаемого action. V2 checkbox и invisible сохраняют документированную возможность заданий. Описания версий не устанавливают универсальный рейтинг эффективности для каждого приложения, развёртывания и сценария злоупотребления.

Являются ли invisible reCAPTCHA v2 и v3 одной интеграцией?

Нет. Руководство invisible описывает сценарий запуска v2, который всё ещё может показать задание. У v3 собственный контракт action и оценки. Кнопка, запускающая проверку, не определяет, какую интеграцию настроил её владелец.

Разрешает ли успешный ответ Siteverify операцию?

Он устанавливает документированный результат проверки. За проверки action, применимую политику оценки и обычные правила разрешения операций по-прежнему отвечает приложение. Поля ответа Google v3 должны оставаться отделёнными от окончательного результата приложения.

Можно ли применять эти названия к существующим классическим интеграциям?

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

Источники

• Google: выбор типа reCAPTCHA
• Google: отображение и настройка reCAPTCHA v2
• Google: invisible reCAPTCHA
• Google: reCAPTCHA v3
• Google: проверка ответа пользователя
• Google Cloud: ключи reCAPTCHA и прежние названия интеграций
• Google Cloud: миграция с reCAPTCHA Classic
• BotBrowser: согласованность автоматизации

Практический вывод

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