EnsureShopSessionCookieAction (5.1.0): сессионная кука WooCommerce каждому гостю на каталоге — ломает кэш страниц и опасна за кэширующим прокси #151

Версия: cdekdelivery 5.1.0 (WP-337 «Optimized adding products to the cart»), WooCommerce 11.

Что происходит. Loader.php вешает EnsureShopSessionCookieAction на wp, и на is_shop() / is_product() / is_product_category() / is_product_tag() каждый гость без сессии получает Set-Cookie: wp_woocommerce_session_* — ещё до того, как что-то положил в корзину.

Почему это проблема.

1. Каталог перестаёт кэшироваться. Любой корректный full-page кэш (nginx proxy_cache / fastcgi_cache, Varnish, CDN, WP-плагины кэша) не должен кэшировать ответ с персональной кукой — значит, страницы товаров и категорий у всех гостей уходят в PHP. Комментарий в классе как раз говорит «чтобы не сажать full-page кеш на Set-Cookie», но страницы магазина — обычно самые посещаемые.
2. Риск утечки данных за прокси, который игнорирует Set-Cookie. Распространённая настройка микрокэша — proxy_ignore_headers Set-Cookie с обходом кэша по входящей куке. При ней ответ с кукой сессии кладётся в кэш, и всем новым гостям в течение TTL раздаётся одна и та же сессия — общая корзина и данные чекаута одного покупателя видны другому. До 5.1.0 на каталоге куки не было, и такая конфигурация была безопасной; после обновления она молча стала опасной.

Предложение (любой из вариантов):

• не форсировать куку на просмотре, а решать гонку на клиенте — сериализовать первые запросы add-item до получения ответа (так сделали мы у себя, гонка закрыта);
• либо дать отключение: фильтр (например, cdek_ensure_shop_session_cookie → false) или опция в настройках;
• как минимум — упомянуть поведение в changelog/readme, чтобы владельцы с кэшем страниц знали о нём.

Временный обход у нас: снимаем действие с хука wp на wp_loaded по имени класса — хрупко, сломается при переименовании класса, поэтому просим штатный способ.