7. Безопасность и особые магазины

Может ли покупатель увидеть чужую корзину

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

Как это работает.

Личные страницы не кешируются никогда. Оформление заказа, личный кабинет, вход, регистрация, «забыли пароль», страницы заказов исключены из кеша жёстко. Это правило нельзя отключить ни настройкой, ни ошибкой в списке исключений. «Проверка кеша» для таких страниц их даже не запрашивает.
Кеш создаётся только по запросам анонимных посетителей. Страница попадает в кеш, только если её запросил посетитель без признаков личного состояния. Если у посетителя есть товары в корзине, если он вошёл в свой аккаунт или в админку, если у него cookie supercache=no_cache, страница строится заново и в кеш не записывается. Кеш также не отдаётся таким посетителям. Это работает и на стороне PHP, и в правилах веб-сервера (веб-сервер видит cookie auth_token, supercache_user_logged_in, supercache_cart и отправляет такой запрос в PHP).
Кеш привязан к адресу. Копия хранится для сочетания «домен + путь страницы» (плюс отдельная папка для устройства при стратегии «Раздельная»). Язык в адрес копии не входит. Адреса с параметрами ?… по умолчанию вообще не кешируются.
Только безопасные запросы. Запросы, меняющие данные (POST и подобные), никогда не кешируются; строгие правила сервера отдают напрямую только GET и HEAD.

Что проверялось. В проверке релиза 3.4.3 на изолированных стендах (Apache и nginx, оба движка, оба способа подключения): с cookie корзины, на страницах /checkout/, /my/, /login/, /cart/, с query-строкой, с другим языком, методом POST и с двумя витринами. Для заранее подложенных «приманок» (файлы кеша с чужим содержимым на этих адресах) результат везде BYPASS: приманка не была отдана. Витрина B (другая валюта) получила свою отдельную копию. ⚠️ Не проверялось: реальный вход покупателя через форму витрины на стенде (проверялась cookie плагина), HTTPS/CDN/прокси перед сайтом, нагрузка на реальном PHP-FPM.

Границы (это важно).

Плагин не знает содержимого сторонних тем и плагинов. Если сторонний плагин показывает личное содержимое прямо на обычной публичной странице (приветствие по имени, персональные скидки, «ваш менеджер»), а посетитель при этом считается анонимным, страница с этим содержимым может попасть в кеш. Для такого плагина: исключите страницы по адресу или тип страницы, либо вынесите изменяющийся фрагмент в динамический блок (⭐ Premium).
Если содержимое страницы зависит не от адреса, а от скрытого признака (регион по IP, валюта в сессии, тип цены покупателя), общий кеш этой страницы не подходит: исключите её.
Если есть CDN или кеширующий прокси перед сайтом, у них своё кеширование. SuperCache их не очищает и не контролирует.
Вошедший пользователь (в том числе администратор) всегда видит витрину без кеша: по коду это действует независимо от галочки «Не кешировать авторизованных пользователей».

Что сделать после включения:

Откройте в приватном окне главную, категорию, товар, поиск, сравнение и убедитесь, что ничего персонального там нет.
Войдите покупателем-«тестом», положите товар в корзину, откройте обычные страницы. Корзина и её значок должны быть вашими.
Всё, что показывает персональное, добавьте в «Исключения по URL» (см. главу 3).

Города, регионы, валюты

Плагин «Автоматическое определение и выбор города»: включите опцию «Автоматическое определение и выбор города» (вкладка «Расширенные», «Интеграция с плагинами»). Посетитель, выбравший город, получает cookie supercache=no_cache и общий кеш ему не отдаётся и из его страниц не создаётся. С версии 3.4.3 это соблюдается и в режиме «Через роутинг» (раньше при этом режиме страница могла попасть в кеш для следующего посетителя). ⚠️ Работа с реальным плагином выбора города в магазине не проверялась.
Если у вас несколько витрин на разных доменах, у каждой своя копия.
Цены/валюты, зависящие только от cookie или сессии посетителя: не различаются кешем (см. границы выше).
Плагин «SEO регионы» на поддоменах: опция «Переподключить JS-запросы к серверу для поддоменов».

Устройства

«Раздельная» стратегия: две независимые копии (компьютер, телефон). Планшеты Webasyst относит к компьютерам; в прежних правилах сервера (профиль «Прежний») iPad и планшеты считаются мобильными, в строгом профиле — как Webasyst. Если у вас много планшетов, лучше использовать способ «Через роутинг» либо строгий профиль.
Если перед сайтом стоит кеширующий прокси или CDN, он должен хранить отдельные копии для телефонов и компьютеров, иначе посетитель может получить копию не своего устройства.

Языки

Язык не входит в «адрес» копии: копия хранится для «домен + путь». Поэтому:

Если на сайте языки разведены по разным адресам (например, /en/… и /ru/…, или разные домены), у каждого адреса своя копия, и оставьте «Любая локализация» (по умолчанию).
Если язык переключается на том же адресе (cookie, сессия), общая копия может оказаться на «не том» языке. Тогда в поле «Локализация» выберите один язык: страницы запросов на другом языке плагин в кеш не кладёт и из кеша не отдаёт (причина BYPASS language; для них кеша не будет).

⚠️ Многоязычные магазины в проверках релиза отдельно не тестировались: настройте и проверьте «Проверкой кеша» на странице каждого языка.

Динамические блоки и условный рендеринг ⭐

Страница кешируется целиком, а отдельный участок (например, блок «вы смотрели» или состав корзины в шапке) загружается отдельным запросом и подставляется в готовую страницу. Для этого нужны Premium, JavaScript в браузере посетителя, правка шаблона темы (атрибут data-dynamic-block="id") и блок с тем же id в «Сайт → Блоки». Подробную инструкцию (в том числе атрибуты data-dynamic-wrap, data-dynamic-async, data-dynamic-params, data-supercache-show) показывает ссылка «Документация» в правой колонке настроек.

Честные условия: блок появляется после загрузки страницы (возможна задержка), каждый показ блока — дополнительный запрос к магазину. ⚠️ Работа динамических блоков в браузере с настоящей лицензией Premium не проверялась: серверная часть проверена по HTTP, JavaScript блока в браузере не запускался.

Сторонние темы и плагины

Темы «MegaShop 2.0» и «Ahead» при многократном обновлении страницы подключают другую версию сайта: включите «Отключать кеш при обновлении страницы».
Если у плагина или темы есть страницы с личными данными по нестандартному адресу, добавьте их в «Исключения по URL».
«Адаптивные изображения PRO»: включите опцию, переустановите правила и очистите кеш (глава 3). Без неё посетитель может получить страницу, собранную под экран другого человека. Блок «Проверка конфигурации» напомнит об этом.
«Критический CSS»: опция интеграции.
Приложение PWA: если оно активно на витрине, опция «Включить кеширование Server Worker» там не действует.

Metadata v2

Второй движок хранения: страницы хранятся файлами, а в базе данных есть реестр, где у каждой страницы стоят «теги» (например, «страница товара №5»). Благодаря этому очищаются только те страницы, где данные изменились; к тому же есть срок годности страницы (TTL) и точная очистка по событиям магазина.

Нужен ли он вам? Обычному магазину — нет. По умолчанию выключен, не рекомендуется включать «на всякий случай». Он имеет смысл для крупного каталога, где аккуратная очистка по тегам важнее простоты. Движок включается и выключается только командой администратора 🔧:

php cli.php shop SupercachePluginEngine status
php cli.php shop SupercachePluginEngine enable
php cli.php shop SupercachePluginEngine probes
php cli.php shop SupercachePluginEngine disable

Что показывает страница настроек при включённом Metadata v2 (снимки 3.4.3, Apache, строгий профиль, после проверки серверных правил probes, результат PROTECTED):

На русском интерфейсе 3.4.3 две строки блока обслуживания (например, «The sweeper works: pages expire by their TTL.») выводятся по-английски: это непереведённые строки плагина, на работу не влияют.

Первые две минуты после включения (окно перехода, 120 с) страницы ещё не публикуются: «Проверка кеша» в этот момент отвечает «Разрешено, но не сохраняется». Подождите две минуты и повторите.

Что нужно: строгий профиль правил сервера (вкладка «Правила сервера») при способе «Через сервер»; задание cron SupercachePluginSweep раз в 5 минут; проверка серверных правил командой probes (результат: PROTECTED означает «утечек не найдено»). «Проверка конфигурации» подсказывает, если включён v2, а профиль «Прежний»: в этом случае все страницы строит PHP, прямых попаданий нет. Выключение: SupercachePluginEngine disable (он не включается и не выключается сам).

В Metadata v2 не предлагается частичная очистка по типам страниц (очищается весь кеш). Действие лимита «Постепенно удалять самые старые страницы» работает только с ним.

⚠️ Измерения скорости выполнены на классическом кеше; для Metadata v2 они не делались.

Экспериментальное внешнее хранилище (S3)

Вкладка «Внешний кэш (S3), эксперимент». Позволяет выгружать «вытесненные» страницы во внешнее S3-хранилище (облако), чтобы не пересобирать их PHP.

Экспериментальная функция. Не рекомендуется обычному владельцу магазина и не входит в рекомендуемую настройку. Выключена по умолчанию.
Требует Premium, Metadata v2, строгих правил сервера, cron воркера раз в минуту, отдельного закрытого бакета только для SuperCache и отдельного ключа доступа.
Риски: скорость не подтверждена на реальных провайдерах и не обещается; бакет не должен быть публичным (иначе режим останавливается); не используйте бакет другого плагина; смена бакета или префикса при включённом режиме оставляет в облаке «осиротевшие» объекты; при недоступном хранилище страницы строятся и хранятся локально, ошибок у посетителей нет. Реальная лицензия Premium и большинство реальных провайдеров не проверялись.
Выключается в любой момент, лицензия для отката не нужна.