Безпечне кешування сторінок 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 перший запит не створює небезпечний кешований варіант.