Данные сеанса теряются только в Chrome

Question

У меня проблема похожая, если не идентична проблеме в этой теме: Случайно теряемые переменные сеанса только в Google Chrome и перезаписи URL

Но все решения в этой теме неработать на меня.Я получаю странное поведение только от Google Chrome в моем приложении PHP / MySQL.Если я попытаюсь сделать это с Firefox, это сработает, а Chrome - нет.

Я перехожу в какое-то место в моей корзине и в нескольких местах кода буду хранить данные сеанса.Не беспокойтесь о том, что я начну сеанс или что-то подобное, у меня есть 11 лет работы в webapp dev, все сделано отлично.

Во всех браузерах я могу var_dump($_SESSION) и вернуть свои данные, но в Chrome он не хранит данные.Также обратите внимание, что сеанс действительно передается, я могу посмотреть в сетевом мониторе, и я вижу отправку куки и многое другое, связанное с работой сеанса, но этот $_SESSION['last_viewed_element'] не сохраняется.Я также не могу установить что-либо еще, все теряется.

РЕДАКТИРОВАТЬ:

Проблема решена путем переключения с СЕССИЙ НА КУКИ ...

Answer 1

У меня была очень похожая проблема, в моем случае проблема была 404 , вызванная из-за отсутствия favicon.ico только в Chrome . 404.php вызвал нижний колонтитул, который изменил переменные Session . Надеюсь, это кому-нибудь поможет.

Answer 2

Возможно, проблема в том, что ваш сервер ищет значки, если он не найден, сервер выбрасывает редирект 302, который убивает переменные сеанса.

Answer 3

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

Answer 4

Я сталкивался с такой же проблемой, но на IIS с ASP.Net MVC.IE и Firefox работали нормально, но в Chrome я терял данные сессий.В конце концов обнаружил, что ошибка 404 очищала cookie в Chrome.Ниже приведены шаги, которые я выполнил, чтобы найти проблему и решить.Я предлагаю другим попробовать:

1. В Chrome используйте Инструменты -> Инструменты разработчика.Обновите страницу, чтобы «Инструменты разработчика» начали показывать данные.

2. В инструментах разработчика выберите Ресурсы -> Файлы cookie.Сразу после успешного входа у меня было 2 куки для домена, который я тестировал.При переходе на страницу, где я потерял сеанс, один из файлов cookie больше не появлялся.Снимок экрана был сделан после исправления, показывая оба куки:

3. Теперь проверьте вкладку Сеть.Ищите внимательно любой ресурс (html / image / css / js / ...), в котором есть ошибки.У меня была ошибка 404 для файла шрифта.Ошибка 404 была вызвана отсутствующим типом пантомимы в IIS.Исправление ошибки 404 очистило проблему в Chrome.На скриншоте, снова снятом после исправления, были все ресурсы со статусом ОК:

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

Answer 5

Была такая же проблема и, наконец, решена. Вход в систему установил сессию с domain.com, но в редиректе это был www.domain.com. IE и FF, похоже, предполагают, что www и www не совпадают, но Chrome - нет. Найдено путем проверки хоста в сетевом журнале для каждой загрузки страницы.

Answer 6

Просто попробуйте это, прежде чем тратить время

Если вы уже вошли в свое веб-пространство (панель управления / Cpanel / Plesk Panel ) в том же браузере.Затем выйдите из этой панели управления и очистите куки и попробуйте снова

В случае

данные сеанса теряются только в Chrome

В моем случае я просто сбрасываю браузер Chrome

Переходим в chrome: // настройки / затем нажимаем "Дополнительно", затем сбрасываем

Answer 7

ХА!я наконец решил это!

При выполнении перенаправления header() в PHP, вы должны сделать die() сразу после него.Это решает только для всех браузеров, кроме Chrome.

Для Chrome вы также должны сделать session_write_close() прямо перед header()

Sweeeeeeeeet Успех

Answer 8

Глядя по следующей ссылке: http://code.google.com/p/chromium/issues/detail?id=45582

Я считаю, что проблема в том, что PHP получает запрос, который не соответствует файлу, а затем неправильно обрабатывает 404. Я должен был сказать Nginx, что нужно сопоставить любой URL с favicon.ico, а затем вернуть 404.

Вот моя строка для Nginx:

 if ($request_uri ~ 'favicon') {
            return 404;
 }

Answer 9

Код, с которым я работал, имел ту же проблему. Решено путем удаления следующего:

session_id($_GET['sid']);
session_write_close();

Answer 10

Я решил проблему, убрав строку:

base href="http://mysite/"

из тега head в HTML-коде.