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

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

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

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

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

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

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

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

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

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

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

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

В случае

данные сеанса, потерянные только в хромированном состоянии

В моем случае я просто сбросил хром-браузер

Перейдите в chrome: // settings / затем щелкните advanced, затем выполните сброс

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

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

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

 base href="http://mysite/" 

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

Посмотрев следующую ссылку: http://code.google.com/p/chromium/issues/detail?id=45582

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

Вот моя линия для Nginx:

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

В файле php ini попробуйте установить

session.save_path = /path/to/your/tmp

На некоторых серверах иногда сеансу требуется явно прямой файл сеанса для сохранения в локальном каталоге или в противном случае происходит какая-то странность.

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

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

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

Успех Sweeeeeeeeet

Это мгновенно решило мою проблему: перейдите в chrome://settings/cookies затем найдите локальный хост и удалите его файлы cookie. Решение настолько простое, что стоит попробовать

Вчера у нас была такая же проблема.

Что (по-видимому) решило это (для нас), было обновление хром.

У нас была версия 45.0.2454.93 и с момента обновления до версии 45.0.2454.99 проблема не возникала снова …

У меня была аналогичная проблема, я обнаружил причину, которая была очень странной. В моем случае один URL-адрес изображения внутри класса css был неправильным !! Браузер не загрузил изображение, и поскольку страница была зарегистрированной формой с полем пароля, браузер сбросит сеанс по соображениям безопасности.

Я не уверен, что ваше дело похоже на мое. Но для меня причиной было формирование URL.

С хром, набрав URL-адрес как « http://www.domainname.com » и установив там переменные сеанса.

и перенаправление с помощью « http://domainname.com » без WWW. sessionid не используется повторно.

Это решило мою проблему, надеюсь, это поможет

Вероятно, вы теряете сеансы только в своей среде разработки, и это может быть, скорее всего, из-за «той же политики происхождения» Chrome. Если это так, то это ваше решение. Отключите такую же политику происхождения в Chrome.

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

Google Chrome (v.59, stable) Inspector не говорит вам, что favicon.ico недоступен и не сообщает, что перенаправлена ​​страница 302.

В конце концов, ответа нет, проблема все еще существует, я просто сделал переход на использование файлов cookie вместо этого, если кто-нибудь когда-нибудь получит эту проблему с помощью chrome + wordpress в то же время, не теряйте больше времени, переключитесь на файлы cookie …

Я нашел «решение» (это не проблема, а только эффекты !!) … если на вашей странице используется ajax, ajax is asyncronus … Если я вызываю функцию, которая работает на SESSION, чем я вызываю другую страницу, которая работает на сеанс, несколько раз первый вызов не заканчивается до второго запуска и эффект первого перезаписываемого ответа второго. Я разрешаю проблему с async: false в каждом вызове ajax.

 Ext.Ajax.request({ url: '/io/resetsession.php', **async: false** }); Ext.Ajax.request({ url: '/io/loaddata.php', **async: false**, ..... });