2 октября 2026 вышел Dr.Slon Toolkit 0.12.2. В 0.11.0 на форме входа появилась Yandex SmartCaptcha, в 0.12.0 и 0.12.1 виджет наконец сел в белый блок wp-login. Серверная проверка при этом не удерживала отказ: если пароль был верный, WordPress затирал ошибку капчи и открывал сессию. Галочка «Я не робот» выглядела обязательной, а вход проходил и без неё.
Тег v0.12.2, коммит b13b6ef. Ставить нужно asset dr-slon-toolkit-0.12.2.zip со страницы релиза, не архив Source code и не кнопку Code → Download ZIP. Карточка проекта: Dr.Slon Toolkit.
Галочка была, отказа не было
Модуль вешает фильтр authenticate. В 0.12.1 капча стояла на приоритете 5, блокировка IP на приоритете 4. Оба возвращали WP_Error раньше, чем ядро смотрит пароль.
Дальше отрабатывает wp_authenticate_username_password (и парный callback для входа по email) на приоритете 20. Если предыдущий результат уже WP_User, функция его не трогает. Если логин или пароль пустые, она сохраняет уже готовую ошибку. А если оба поля заполнены, ранний WP_Error просто выбрасывается: ядро ищет пользователя и при верном пароле возвращает WP_User. Фильтр authenticate не останавливается на первой ошибке. Побеждает последнее значение.
$user приходит результат предыдущего колбэка. Снимок 2 октября 2026. Источник: developer.wordpress.org, функция wp_authenticate_username_password.На обычной попытке входа сообщение «Подтвердите, что вы не робот» до экрана не доходило. Неверная пара логин/пароль затирала капчу своей ошибкой. Верная пара затирала её успешным входом. Виджет при этом рисовался, скрытый slug входа тоже получал чекбокс. Со стороны казалось, что защита работает.
То же самое с лимитом попыток. Заблокированный IP получал ошибку на приоритете 4, а верный пароль на приоритете 20 эту ошибку снимал. Счётчик неудач копил только те входы, которые ядро само помечало провалом. Обход блокировки правильным паролем в схему не входил, но на практике он был.
Почему приоритет 100, а не «ещё одна проверка спереди»
Ранний отказ имеет смысл только если более поздний callback его не перезапишет. В ядре WordPress 6.8 проверка пароля по логину и по email сидит на 20, cookie-аутентификация в wp_signon добавляется на 30 и при заполненных полях чужую ошибку не подменяет, проверка спама на мультисайте стоит на 99. Капча в 0.12.2 висит на 100, блокировка IP на 110. Оба смотрят уже готовый результат и при своём отказе возвращают WP_Error, который дальше по цепочке ядра некому затереть.
add_filter('authenticate', [$this, 'block_without_captcha'], 100, 3);
add_filter('authenticate', [$this, 'block_if_locked'], 110, 3);
Порядок такой. Сначала ядро решает, совпал ли пароль. Потом капча. Если токена нет или Яндекс ответил status: failed, вместо пользователя уходит ошибка капчи, даже когда пароль верный. Если токен прошёл, блокировка IP всё ещё может остановить вход: верный пароль её больше не снимает.
Пустой токен до Яндекса не ходит. Плагин сам возвращает отказ. Поле токена, как в документации SmartCaptcha, называется smart-token. Токен одноразовый и живёт около пяти минут. Повторная проверка того же значения даёт Invalid or expired Token.
Одна галочка без картинки сама по себе не баг плагина. Обычная SmartCaptcha показывает задание только запросам, которые сервис счёл подозрительными. Если Яндекс ответил ok, вход должен открыться. 0.12.2 закрывает другой случай: верный пароль без годного токена.
Когда Яндекс молчит, вход по-прежнему открыт
Если запрос на https://smartcaptcha.cloud.yandex.ru/validate не получился, плагин не запирает сайт. Таймаут три секунды и ответ не 200 считаются fail-open: при уже отправленном токене вход не блокируется. Для кодов не 200 это прямо следует из рекомендации Яндекса обрабатывать сбой HTTP как status: ok, чтобы форма не зависала. Сетевой обрыв обработан так же.
Без токена fail-open не включается. Пустая галочка после 0.12.2 останавливает вход, даже если до облака Яндекса с сервера не достучаться. Имеет смысл отдельно проверить, что хостинг вообще выпускает HTTPS на smartcaptcha.cloud.yandex.ru. Иначе человек с галочкой будет проходить из-за недоступности сервиса, а не из-за ответа ok.
Сброс пароля и XML-RPC капча по-прежнему не закрывает. Это не регрессия 0.12.2, так модуль был устроен с 0.11.0.
Как обновить и что посмотреть на форме
На сайте с Toolkit от 0.9.0 обновление должно прийти в обычный список обновлений WordPress. Плагин берёт только проверенный ZIP, с контролем SHA-256, размера, версии и структуры архива. Если пункт не появился, тот же файл можно поставить вручную: Плагины → Добавить новый → Загрузить плагин.
После обновления страницу входа лучше открыть заново, без старого кэша браузера. Проверка короткая, на тестовом пользователе или в приватном окне:
- Верный пароль без галочки. Ожидается «Подтвердите, что вы не робот», сессия не открывается.
- Верный пароль и пройденная капча. Вход открывается.
- Если включён лимит попыток и IP уже в блоке, верный пароль блок не снимает. Сброс по-прежнему кнопкой в настройках плагина.
- Скрытый slug входа, если модуль включён, ведёт себя так же. Восстановление пароля остаётся без капчи.
Ключи те же, из Yandex Cloud: клиентский на виджете, серверный только на проверке токена. Пустой серверный ключ по-прежнему выключает модуль на входе и показывает предупреждение в админке. Менять ключи из-за 0.12.2 не нужно.
0.12.2 не добавляет модулей и не трогает вёрстку формы из 0.12.1. Он переставляет две проверки так, чтобы ядро WordPress больше не отменяло их верным паролем. Репозиторий: A-Krivoshen/dr-slon-toolkit. Задачи по WordPress и сопровождению сайтов на wordpress.krivoshein.site.
