Личный кабинет WordPress: чек-лист перед продакшеном

Личный кабинет на WordPress нельзя считать готовым после проверки формы входа и страницы профиля. Перед продакшеном нужно убедиться, что пользователь не видит чужие заказы, кеш не отдаёт приватную страницу следующему посетителю, а восстановление пароля и выход из аккаунта работают в реальном браузере. Этот чек-лист рассчитан на WordPress 6.x и занимает несколько часов на тестовом домене, если кабинет уже собран.

Что проверить до начала

Сначала зафиксируйте окружение. Один и тот же кабинет ведёт себя по-разному на чистом WordPress, в связке с WooCommerce и при наличии плагина кеширования.

• версию WordPress, PHP и базы данных;
• тему и плагины, которые участвуют в авторизации, профиле, заказах и отправке писем;
• адреса страниц входа, регистрации, профиля, заказов, восстановления пароля и выхода;
• тестовые учётные записи: обычного пользователя, пользователя без заказов и администратора;
• копию базы данных и файлов перед изменениями;
• тестовый домен или staging, который не индексируется поисковиками и не отправляет реальные письма клиентам.

Если кабинет построен на WooCommerce или стороннем плагине, его требования к версиям важнее универсального совета. Сверьте совместимость каждой части стека с документацией разработчика.

Чек-лист перед запуском

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

1. Вход. Проверьте правильный и неправильный пароль, пустые поля, отключённую учётную запись и повторный вход после закрытия браузера. Пользователь должен получить понятное сообщение, а не PHP-ошибку или бесконечный редирект. Убедитесь, что после входа он попадает в кабинет, а не в панель администратора.
2. Выход и сессия. Нажмите «Выйти», затем вернитесь на страницу кабинета кнопкой браузера. Приватные данные не должны открываться без новой авторизации. Отдельно проверьте истечение сессии: после повторного запроса сайт должен отправить пользователя на вход, а не показать старый профиль.
3. Разделение пользователей. Создайте два обычных аккаунта и наполните их разными тестовыми данными. Войдите под первым, скопируйте URL заказа или профиля, затем откройте его под вторым. Второй пользователь не должен получить чужие данные даже при ручной замене идентификатора в адресе.
4. Изменение профиля. Проверьте сохранение имени, телефона и других полей с допустимыми и заведомо неверными значениями. После обновления страницы должны отображаться сохранённые данные, а HTML и уведомления не должны превращать введённый текст в исполняемый код.
5. Смена и восстановление пароля. Запросите письмо для существующего пользователя, проверьте одноразовую ссылку, просроченную ссылку и повторное использование уже применённой ссылки. Письмо должно приходить с адреса вашего домена, а новый пароль не должен появляться в URL, логах или уведомлении администратора.
6. Права доступа. Откройте страницы кабинета под обычным пользователем, автором и администратором. Уберите из интерфейса не только кнопки, но и саму возможность выполнить административное действие через прямой HTTP-запрос. Скрытая кнопка не является контролем доступа.
7. Формы и запросы. Для каждой операции проверьте защиту от повторной отправки и подделки запроса. Если после обновления страницы заказ или адрес создаётся второй раз, добавьте защиту от повторной отправки и проверьте логику обработки на сервере.
8. REST API и AJAX. Просмотрите запросы в инструментах разработчика браузера и ответы неавторизованного клиента. Закрытые данные не должны возвращаться в JSON только потому, что URL API известен. Для каждого изменяющего запроса проверьте авторизацию, права пользователя и защитный токен.
9. Кеширование. Войдите под первым пользователем, откройте кабинет, выйдите и зайдите под вторым. Второй аккаунт не должен увидеть имя, заказы или адрес первого. Исключите приватные URL из кеша страницы, CDN и серверного кеша; убедитесь, что после выхода браузер не показывает рабочую копию страницы.
10. Мобильный сценарий. Пройдите регистрацию, вход, изменение профиля и восстановление пароля на узком экране. Проверьте клавиатуру, автозаполнение, сообщения об ошибках и кнопки в Safari и Chrome на актуальных мобильных версиях.
11. Письма. Проверьте доставку уведомлений о регистрации, смене пароля и заказе. Посмотрите тему, имя отправителя, ссылки, мобильную верстку и домен перехода. На staging замените адреса получателей, чтобы тест не отправил реальные данные клиентам.
12. Ошибки и логи. Включите журналирование на staging и намеренно вызовите отказ: неверный ID, просроченный токен, недоступную зависимость. Пользователь должен получить безопасное сообщение, а детали — попасть в защищённый лог без паролей, токенов и персональных данных.

Результат каждого пункта фиксируйте в таблице тестов: аккаунт, URL, действие, ожидаемый результат, фактический результат и статус. Это быстрее, чем повторно проверять кабинет после исправления одного бага.

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

Что именно должно быть закрыто

Токен запроса¹ — одноразовое или ограниченное по времени значение, которым сайт проверяет, что действие отправлено из ожидаемой формы, а не подставлено сторонним сайтом.

Что чаще всего ломается

Кеш видит пользователя, но сервер — нет

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

Проверяется наличие кнопки, а не право

Удалить ссылку «Удалить заказ» для обычного пользователя недостаточно. Запрос к обработчику можно отправить напрямую. Серверная часть должна повторно проверить, кто отправил запрос, имеет ли он нужное право и относится ли объект к этому пользователю.

Сторонний плагин меняет маршрут

После обновления плагина страница входа может получить новый URL, а старый адрес — редирект на главную. Проверьте все ссылки из писем, меню, карты сайта и настроек SEO. Если плагин работает через шорткод, убедитесь, что он не выводится как обычный текст при смене темы.

Форма работает только при включённом JavaScript

Это не всегда ошибка: некоторые интерфейсы специально используют клиентский JavaScript. Но сервер всё равно должен корректно отклонять повреждённые или неполные запросы. Проверьте ответы во вкладке Network, статус HTTP и текст ошибки, а не только внешний вид формы.

Когда кабинет можно выпускать

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

Для каждого найденного дефекта назначьте владельца и повторную проверку. Обновления WordPress, темы, WooCommerce и плагинов проводите сначала на staging. Перед обновлением делайте резервную копию и проверяйте вход, заказы, формы и письма — именно эти цепочки чаще всего завязаны сразу на несколько компонентов.

После запуска поставьте мониторинг не только доступности сайта, но и бизнес-сценариев: успешного входа, отправки формы восстановления пароля, ответа API и доставки ключевых писем. Следующий полезный шаг — провести повторный тест после первого обновления плагина авторизации и сохранить результаты как регрессионный чек-лист.