Кеш сайта показывает чужие цены и корзину: что проверить

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

Первые действия владельца проекта:

1. Запишите время, маршрут без секретных параметров и последовательность действий. Вместо чужих данных используйте описание расхождения: «показана цена другой группы».
2. Уточните, возникает ли ошибка у гостя, после входа или при смене организации. Не просите покупателей пересылать cookie, токены и полные сетевые журналы.
3. Согласуйте с разработчиком воспроизведение на тестовых учётных записях и синтетических товарах. При продолжающемся раскрытии данных сначала ограничивают затронутый сценарий.

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

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

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

Если всем показывается одинаковая устаревшая информация после публикации, полезен отдельный разбор слоёв кеша в Next.js. Здесь проверяется другая граница: может ли результат одного посетителя попасть к другому.

При обнаружении чужих данных не перебирайте идентификаторы заказов и не расширяйте проверку на реальные аккаунты. Передайте наблюдение ответственному за проект и используйте только разрешённый тестовый контур.

Матрица: гость, два покупателя и смена организации

Учебный пример: на тестовой копии есть покупатели А и Б с различимыми условными ценами и корзинами. Для проверки смены организации у А предусмотрены две тестовые компании. Это схема испытания, а не история клиентского проекта.

Разделите сеансы по независимым профилям браузера. Два приватных окна одного браузера не всегда означают два независимых сеанса; разработчик должен подтвердить изоляцию. Проверьте следующие строки матрицы:

• Гость после покупателя А. Гость открывает тот же адрес каталога и корзины. Ему доступны только публичная цена и собственная гостевая корзина.
• Б после А. Сначала страницу запрашивает А, затем Б. Б получает свою цену и свои товары. Повторите в обратном порядке.
• А меняет компанию. После переключения интерфейс и серверный ответ соответствуют выбранной разрешённой организации, а прежние договорные данные не остаются в карточке.
• Выход и новый вход. После выхода А данные его кабинета не появляются у гостя и следующего вошедшего покупателя.
• Повторное открытие. Сценарии проходят и при первом запросе, и после заполнения кеша, и при обычном переходе внутри сайта.

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

Четыре места, где искать смешение данных

Общий кеш страницы или ответа API. API — программный интерфейс, через который страница получает данные. Если CDN, сеть доставки контента, или обратный прокси хранит персональный ответ как общий, следующий посетитель может получить готовую копию. Разработчик сопоставляет ответы приложения и внешнего слоя, правила хранения и признаки попадания в кеш.

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

Неверный контекст или права. Сервер мог выбрать не ту организацию ещё до обращения к кешу. На тестовом контуре сравнивают результат с контролируемым обходом кеширования. Если смешение сохраняется, проверяют выбор контекста и права доступа; идентификатор компании из запроса нельзя считать доказательством полномочий.

Состояние браузера. Если сервер вернул правильную тестовую метку, а экран показывает прежнюю, проверяют сохранённое состояние интерфейса после выхода, входа и смены компании. Отдельно выясняют, участвует ли service worker — фоновый компонент браузера, который может самостоятельно сохранять ответы.

Совпадение ошибки с попаданием в кеш помогает сузить поиск, но не доказывает причину. Значение Age или служебная отметка HIT относится к конкретному слою; отсутствие такой отметки не исключает кеширование внутри приложения.

Какие правила согласовать с разработчиком

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

В RFC 9111 различаются следующие директивы заголовка Cache-Control:

• private без параметров запрещает хранение в общем кеше, но допускает личный кеш браузера;
• no-store запрещает кешу сохранять ответ;
• no-cache требует проверки у исходного сервера перед повторным использованием и не означает запрета хранения.

Эти директивы управляют хранением, но не заменяют авторизацию и проверку фактического ответа на каждом слое.

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

Для персонального маршрута важны оба направления: не взять готовую общую копию и не записать новый персональный ответ в общий кеш. В NGINX это разные механизмы — proxy_cache_bypass и proxy_no_cache. Их условия зависят от приложения; копировать универсальную настройку без разбора сеансов опасно.

Заголовок Vary позволяет учитывать указанные заголовки запроса при выборе сохранённого ответа. Он не заменяет проверку прав. Добавление всех cookie в ключ также не доказывает корректность: сначала нужно определить, какие признаки действительно меняют ответ и как проверяется право пользователя на эти данные.

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

Как подтвердить, что исправление работает

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

Согласуйте проверяемые условия:

• цена, корзина и организация совпадают с ожидаемыми у гостя, А и Б;
• порядок обращений А → Б и Б → А не меняет принадлежность данных;
• персональные метки не появляются ни в видимой странице другого пользователя, ни в полученных им HTML и ответах API;
• вход, выход и переключение компании обновляют интерфейс и сохраняют проверку прав на сервере;
• после повторных запросов и заполнения кеша результат остаётся правильным;
• уже сохранённые ошибочные копии удалены или выведены из использования предусмотренным для этого слоя способом;
• обычный публичный каталог работает, а сервер выдерживает согласованный режим после изменения кеширования.

Если сбой зависел от одновременных обращений, разработчик добавляет контролируемую проверку параллельных запросов на тестовом контуре. Массовое обновление рабочего магазина не заменяет испытание.

Результат приёмки ограничен проверенными маршрутами, ролями и конфигурацией. Исчезновение симптома не показывает, кто раньше получил чужую информацию; оценка возможного раскрытия данных — отдельная задача.

Когда достаточно своей команды

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

Если ответственность разделена между хостингом, разработчиком и поддержкой CMS, сначала нужен общий план диагностики: где формируется персональное поле, кто хранит ответ и кто проверяет результат после выпуска. OpenStart принимает задачи по доработке существующего сайта, включая каталог, корзину и серверную логику. Состав диагностики, стоимость и критерии приёмки согласуются до работ.

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

Техническая основа: RFC 9111 «HTTP Caching», разделы 4.1, 5.2.2 и 7.3; документация NGINX по proxy_cache_bypass, proxy_no_cache и обработке заголовков ответа.