Безопасное кэширование страниц WooCommerce: как не показать чужую корзину

Почему кэширование опасно для WooCommerce

Обычная страница товара часто одинакова для всех посетителей, поэтому её удобно сохранять в page cache. Корзина и checkout работают иначе: их содержимое зависит от cookies, сессии, авторизации, способа доставки, введённых данных и текущего состояния заказа.

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

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

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

Какие страницы WooCommerce нужно исключить из page cache

Базовое исключение для большинства магазинов — страницы корзины, оформления заказа и личного кабинета. В типичной структуре WooCommerce это адреса вроде /cart/, /checkout/ и /my-account/, но фактические URL в конкретном магазине могут отличаться. Ориентируйтесь не только на название slug, а на страницы, назначенные для этих функций.

Исключение должно действовать на каждом уровне, где может сохраняться HTML: в плагине кэширования, на сервере, в reverse proxy и в CDN. Если только плагин WordPress знает, что /checkout/ нельзя кэшировать, а CDN продолжает отдавать старый объект, проблема сохранится.

Отдельно проверьте URL, которые тема или расширения магазина используют для мини-корзины, быстрого оформления заказа, сравнения товаров или персональных рекомендаций. У них не всегда стандартные названия, поэтому определяйте их по документации расширения и сетевым запросам браузера.

• Исключите страницы корзины, checkout и my-account из полного кэширования.
• Не кэшируйте страницы входа, регистрации и другие разделы с персональными данными.
• Не кэшируйте POST-запросы; для GET-запросов проверяйте, не являются ли они AJAX-операциями.
• После изменения slug или страниц WooCommerce обновите правила кэширования.

Cookies, по которым определяется персонализированный запрос

WooCommerce использует cookies для сохранения состояния корзины и сессии. Наличие таких cookies — важный сигнал для обхода общего page cache. Чаще всего нужно учитывать woocommerce_items_in_cart, woocommerce_cart_hash и wp_woocommerce_session_.

Если присутствует хотя бы одна из них, безопаснее не отдавать общий кэшированный HTML-ответ. Сервер может передать запрос в WordPress для динамической генерации или использовать отдельный, корректно изолированный вариант кэша. Для большинства магазинов проще и надёжнее применить bypass.

Названия cookies могут дополняться или изменяться под влиянием темы, платёжных модулей, плагинов membership и пользовательских интеграций. Поэтому список из трёх cookies нельзя считать универсальным: проверьте фактические заголовки Set-Cookie и документацию установленных расширений.

• woocommerce_items_in_cart — признак наличия товаров в корзине.
• woocommerce_cart_hash — идентификатор изменений состояния корзины.
• wp_woocommerce_session_ — cookie сессии WooCommerce.
• Для авторизованных пользователей дополнительным сигналом является cookie входа WordPress, в частности wordpress_logged_in_.

Пример логики обхода в Nginx

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

map $http_cookie $skip_woocommerce_cache {
    default 0;
    ~*"woocommerce_items_in_cart|woocommerce_cart_hash|wp_woocommerce_session_|wordpress_logged_in_" 1;
}

map $request_uri $skip_woocommerce_path {
    default 0;
    ~^/cart/ 1;
    ~^/checkout/ 1;
    ~^/my-account/ 1;
}

# У правилах кешу використовуйте обидва прапорці:
# не читати та не зберігати кеш, якщо будь-який із них дорівнює 1.

Запросы wc-ajax и динамические фрагменты

WooCommerce и его расширения могут обновлять корзину без полной перезагрузки страницы. Для этого используются AJAX-запросы, в том числе URL с параметром wc-ajax. Их ответ часто зависит от cookies текущего пользователя, поэтому его нельзя сохранять как общий ответ для всех.

На уровне сервера и CDN создайте правило, запрещающее кэшировать запросы с wc-ajax в строке query string. Также проверьте другие AJAX-эндпойнты, REST-запросы и маршруты, которые добавляют установленные плагины. Не каждый динамический запрос имеет одинаковое название.

Кэширование JavaScript-файлов само по себе не является проблемой: статические скрипты обычно можно кэшировать надолго. Опасность заключается в кэшировании их персонализированных ответов или HTML, который скрипты получают с сервера.

• Исключите из кэша URL с wc-ajax.
• Убедитесь, что CDN не кэширует ответы на AJAX-операции со статусом 200.
• Проверьте запросы после добавления товара, изменения количества, удаления товара и применения купона.
• Не отключайте весь JavaScript только из-за проблемы с кэшем — сначала исправьте правила хранения ответов.

Как настроить кэширование для авторизованных пользователей

Авторизованный пользователь почти всегда должен получать динамический ответ. Его страница может содержать имя, заказы, адрес, уровень доступа или другие данные, которых не должно быть в общем кэше. Поэтому запросы с cookie авторизации WordPress обычно полностью исключают из page cache.

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

Object cache, например Redis или Memcached, не является заменой page cache и не должен смешивать данные разных сессий. Ядро WordPress и WooCommerce обычно работает с ключами кэша, но ошибки пользовательского кода или неправильная конфигурация могут создать общий ключ для персональных данных.

• Исключите авторизованных пользователей из полного кэширования по cookie входа.
• Не кэшируйте страницы профиля, заказов, адресов и персональных цен.
• Проверьте собственный код и плагины, которые записывают данные в object cache.
• Не очищайте весь object cache без необходимости на рабочем сайте: это может временно увеличить нагрузку.

Что очистить после изменения правил

Изменение конфигурации не удаляет автоматически объекты, которые уже были сохранены. Если ранее /cart/ или /checkout/ попали в кэш, пользователи могут продолжать получать старый ответ до окончания срока его хранения.

После обновления правил очистите page cache на сервере или в плагине, кэш CDN и связанные кэши reverse proxy. Object cache очищайте только тогда, когда изменения относятся к объектам или результатам запросов, которые он хранит. После очистки убедитесь, что новые ответы снова не сохраняются с неправильными заголовками.

Проверьте заголовки ответа: X-Cache, Age, Cache-Control, Vary и служебные заголовки вашего CDN. Их названия различаются, но они помогают понять, пришёл ли ответ из кэша и на каком уровне.

• Очистите кэш плагина или reverse proxy.
• Выполните purge соответствующих объектов в CDN.
• При необходимости очистите object cache.
• Проверьте, что для персонализированных ответов задан корректный Cache-Control и они не сохраняются повторно.

Практический тест безопасности кэша

Тестируйте магазин в чистой гостевой сессии и в отдельной авторизованной сессии. Удобнее всего использовать разные браузеры или приватные окна, но убедитесь, что в приватном окне действительно нет старых cookies.

Сначала откройте страницу товара в первой сессии, добавьте товар в корзину и перейдите на /cart/. В другой сессии откройте тот же URL. На нём не должны отображаться товары первого пользователя. Повторите проверку для checkout и my-account.

После этого протестируйте изменения корзины: добавьте товар, измените количество, удалите его, примените купон и вернитесь к checkout. Также проверьте сценарии входа, выхода и повторного открытия страницы после очистки cookies.

Тест нужно выполнять через настоящий домен и CDN, а не только локально на сервере. Именно внешний уровень может возвращать устаревший ответ.

• Гость не видит корзину другого гостя.
• Авторизованный пользователь не получает HTML гостя.
• Изменение корзины отображается после каждой операции.
• Checkout не открывается со старыми данными другой сессии.
• В заголовках нет признаков общего кэша для персонализированного ответа.
• После purge первый запрос не создаёт небезопасный кэшированный вариант.