Корзина отбрасывает все предметы / корзина очищает сессию

27

Сайт, которым я управляю внезапно (возможно, 2 недели назад - из статистики GA, и только что сообщенный сейчас) начал сбрасывать элементы корзины при просмотре корзины или переходе к оформлению заказа.

В верхней «мини-корзине» отображаются элементы в раскрывающемся меню, пока вы не перейдете к корзине / оформлению заказа, а затем окажетесь в корзине с сообщением «В вашей корзине нет товаров».

Похоже на сессионный вопрос. Это не происходит при входе в систему.

Удалил все параметры проверки сеанса в «system-> web-> параметры проверки сеанса» и включил параметр «Использовать SID на веб-интерфейсе». Это действительно решило проблему, но, поскольку эти настройки не изменились за последние 3 месяца, я знаю, что есть некоторая основная проблема.

Это тогда указывает на проблему с проблемой sore-id? Каким-то образом сайт теряет идентификатор хранилища и отбрасывает данные сеанса / корзины? Может быть, какой-то наблюдатель / событие / переписать какой-то модуль.

Я не могу повторить проблему на локальном устройстве или на сервере UAT. БД по UAT - это 2 недели, начиная с прямой трансляции, так что это может указывать на проблему / настройку БД?

Вещи, которые я пробую: я занят перетаскиванием текущего живого даба в UAT, чтобы получить это актуальное, чтобы посмотреть, смогу ли я воспроизвести проблему там. будет обновлять, когда это будет сделано.

После того, как я смогу воспроизвести проблему в не-живой области, я буду систематически отключать модули, чтобы увидеть, не происходит ли что-нибудь с идентификаторами магазинов (начиная с MageMonkey и sweettooth, так как они были обновлены 2 недели назад).

Вопрос - что еще можно попробовать? Любые указатели, где я могу ударить некоторые точки останова и пошаговый код, чтобы увидеть, могу ли я отследить эту проблему?

нет никаких дополнительных систем кэширования, таких как лак или memcache. Сервер является стандартной установкой cpanel. Тестирование на UAT Я отключил весь кеш.

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

Я также использовал git для возврата кода, и проблема остается с каждым хэшем.

Обновление: прошло некоторое время, так как я успел потратить на это. Высокая рабочая нагрузка.

Я переместил сеансы в файл, и проблема исчезла. Так как клиент не намерен использовать несколько серверов в ближайшем будущем, и из-за моей рабочей нагрузки это было оставлено на этом. Скорее всего, вернется, чтобы укусить меня позже.

Служба поддержки magento предположила, что проблема связана с тем, что модуль сладкоежек продлевает занятия, но я отключил этот модуль, и проблема осталась.

обновлю, когда получу больше результатов.

ProxiBlue
источник
«Использовать SID на веб-интерфейсе» фактически не устранило проблему. Кажется, проблема случайная. Хорошо работает для одних сессий, капли для других.
ProxiBlue
Я могу надежно повторить это на UAT сейчас. Похоже, 8/10 попыток добавить в корзину имеет эту проблему. Затем сессия «залипает» и все работает как обычно. Устранены SweetTooth и MageMonkey в качестве причин (после их обновления). Подтверждено, что это проблема сеанса. Когда я добавляю в корзину, у меня есть сеанс с одним идентификатором, когда я иду в корзину, я получаю новый идентификатор сеанса.
ProxiBlue
Некоторые коллеги столкнулись с почти идентичной проблемой. Я не знаю точно, что вызвало проблему (я знаю, что это было связано с memcache и / или лаком), но решение было настроить балансировщик нагрузки для сервера (ов). Поэтому вам следует поговорить об этом с администратором вашего сервера.
Влад Преда
1
Что такое версия magento? И что вы используете в качестве хранилища сессий? Переключение на файлы или базу данных соответственно имеет значение?
Кристоф в Фуман
@Fooman Привет, EE 1.11.2.0, используя сеанс БД, не пытался обменяться файлами, сообщит, какой результат это дает.
ProxiBlue

Ответы:

8

На наших коробках cPanel отсутствующие ресурсы обслуживали всю страницу Magento.

по умолчанию Cpanel, чтобы , ErrorDocument 404 /404.shtmlно /404.shtmlне существует в корневом каталоге документов Magento, так .htaccess , получает снова и переадресовывает выполняется /404.shtmlв index.php( с помощью mod_rewrite).

По умолчанию Magento .htaccess должен явно указывать 404, 500 и другие обработчики ошибок.

Чтобы исправить это поведение, мы добавили в наш .htaccess следующее:

ErrorDocument 404 /errors/404.php

Мы, вероятно, также должны добавить 500:

ErrorDocument 500 /errors/500.php

jmlnik
источник
@ProxiBlue это решило вашу проблему, так как это принятый ответ? У меня почти идентичная проблема. Все еще не уверен, что вызывает это.
дчайка
9

Вы используете Varnish на сервере?

Мы видели несколько реализаций, в которых люди удаляют куки-файлы ДО выборки статического контента (images / css / js) - поэтому, если изображение / js / css не существует; он загружает загрузчик Magento и 404-е - это полностью удаляет файлы cookie и сеанс сайта.

Бен Лессани - Сонасси
источник
Нет лака, хотелось бы, чтобы все было так просто: '(
ProxiBlue
Привет есть такая же проблема, я могу знать, каково решение?
Kandarp B Patel
@ Бен Пожалуйста, не могли бы вы уточнить это?
ожог
6

Одной из проблем может быть то, что Magento не сохраняет данные сеанса при переключении с HTTP на HTTPS . Убедитесь, что необходимые настройки для SSL и т. Д. Установлены правильно.

Другая проблема может заключаться в том, что интернет-провайдер клиента меняет свой IP-адрес, как описано здесь .

Чтобы исправить эту проблему:

Измените параметры проверки сеанса в Magento Admin, находящиеся в разделе « Система»> «Конфигурации»> «Интернет» , на «нет» во всем, кроме « Проверка HTTP_USER_AGENT» . После этого перейдите в « Система»> «Управление кэшем» и обновите кэш конфигурации, чтобы применить изменения.

pzirkind
источник
Корзина по-прежнему в http, поэтому не http-> https проблема.
ProxiBlue
1
Это происходит с нами, в нашей среде UAT, и у нас есть фиксированный IP-адрес. Ценю предложения.
ProxiBlue
5

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

Джонатан Дэй
источник
Я рад, что этого не происходит с некоторыми из наших клиентов. Больше 404, чем я хочу признаться.
Philwinkle
2
@jonathanday Magento не сделает этого, но плохо настроенный Varnish будет.
Бен Лессани - Сонасси
@sonassi, можешь рассказать о плохо настроенном лаке? У нас была та же проблема. Исправление страницы 404 устранило проблему, но хотелось бы знать, можем ли мы лучше настроить Varnish!
JMLN
Это было на самом деле то, что происходило. Я как-то пропустил этот ответ! Дело в том, что magento должен выдвигать не версию контроллера страницы 404, а статическую страницу 404.
ProxiBlue
1
Я отправил ответ, который объясняет это.
Бен Лессани - Сонасси
1

Это может быть проблема с датой cookie / сервера. Первым делом проверьте заголовки файлов cookie. Осмотрите заголовки (используя что-то вроде Firebug, Charles или Fiddler).

Вы должны увидеть что-то вроде следующего:

Set-Cookie  frontend=9dhtlgf1qmo6loqksvvmqjd625; expires=Thu, 31-Jan-2013 05:01:13 GMT; path=/; domain=.foo.com; HttpOnly

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

beeplogic
источник
Проверено, дата / время сервера в порядке, дата / время файла cookie в порядке :(
ProxiBlue
1

Сборка мусора в PHP очищает сессии преждевременно. Я сам видел это на сайтах с большим трафиком .

Некоторые советы по устранению неполадок:

  • Сколько лет вашей самой старой сессии? Чтобы выяснить: ls -laht [mageroot]/var/session/ | tail- если у вас нет сеансов дольше, чем пару недель или около того, скорее всего виновата сборка мусора
  • Временно перемещайте сессии в другое хранилище данных - например, MySQL или Memcached. Проблема решена?
  • Это происходит на сервере разработки? Если нет, и все вещи равны, возможно, уровни трафика вызывают преждевременное истечение срока сеанса или сборку мусора.

Я исправил это одним из двух способов:

  1. В вашем .htaccess добавьте php_value session.gc_maxlifetime 2592000
  2. В вашем php.ini установите session.gc_maxlifetime

Больше чтения: http://www.php.net/manual/en/session.configuration.php#ini.session.gc-maxlifetime

philwinkle
источник
1
Хорошие предложения. Попробую через несколько дней
ProxiBlue
1

У нас была похожая проблема. В нашем случае это была конфигурация Varnish (как предложил Бен Лессани). Мы настроили наш Varnish для кэширования 404 с на 120 с, чтобы наши серверы не пострадали, когда на странице возникает ошибка 404.

Таким образом, проблема заключается в том, что 404s Magento отвечал с помощью Set-Cookie в заголовке для файлов cookie frontend и frontend_cid, которые сбрасывают сеанс клиента.

Наше решение для этого состоит в том, чтобы лишить любые Set-Cookies для 404 ответов,

unset beresp.http.set-cookie;
Тан
источник
0

Тупые вещи, которые в прошлом мешали мне сеансами PHP и, возможно, стоит проверить:

  • полный диск
  • неточное время сервера
xyphoid
источник
:) первым делом проверил диск, все ок.
ProxiBlue
дата хорошая :( не все так просто, тьфу [~ / public_html / var / log] # дата чт 31 января 11:55:49 WST 2013
ProxiBlue