Как решить проблему потери сеанса после перенаправления в PHP?
Недавно я столкнулся с очень частой проблемой потери сеанса после перенаправления. И после поиска на этом веб-сайте я все еще не могу найти решения (хотя это было самым близким).
Обновить
Я нашел ответ и решил опубликовать его здесь, чтобы помочь любому, кто сталкивается с такой же проблемой.
php
session
redirect
session-cookies
shared-hosting
dayuloli
источник
источник
Ответы:
Сначала выполните эти обычные проверки:
session_start();
вызывается перед вызовом любых сеансов. Таким образом, беспроигрышный вариант - разместить его в начале вашей страницы сразу после открывающего<?php
объявления, прежде чем что-либо еще. Также убедитесь, что перед открывающим<?php
объявлением нет пробелов / табуляции .header
перенаправления завершите текущий сценарий, используяexit();
(другие также предлагали,session_write_close();
иsession_regenerate_id(true)
вы также можете попробовать их, но я бы использовалexit();
)register_globals
что выключено, вы можете проверить это вphp.ini
файле, а также с помощьюphpinfo()
. Обратитесь к этому, чтобы узнать, как его выключить.$_SESSION
суперглобальном массиве нигде не перезаписанwww.yourdomain.com
наyourdomain.com
не переносит сеанс вперед..php
(такое бывает!)Это наиболее распространенные ошибки, но если они не помогли, проблема, скорее всего, связана с вашей хостинговой компанией. Если все работает,
localhost
но не на вашем удаленном / тестовом сервере, то, скорее всего, виноват в этом. Так что проверьте базу знаний вашего хостинг-провайдера (также попробуйте их форумы и т. Д.). Для таких компаний, как FatCow и iPage, они требуют, чтобы вы указалиsession_save_path
. Ну вот так:(замените «путь к вашему домашнему каталогу» фактическим путем к домашнему каталогу. Обычно он находится в панели управления (или аналогичной), но вы также можете создать
test.php
файл в корневом каталоге и ввести:Бит перед test.php - это путь к вашему домашнему каталогу. И, конечно же, убедитесь, что папка действительно существует в вашем корневом каталоге. (Некоторые программы не выгружают пустые папки при синхронизации)
источник
вы должны использовать "exit" после вызова заголовка
источник
echo ' ';
) или какие-либо пробелы, он полностью игнорирует заголовок местоположения.Я перепробовал все возможные решения, но у меня ни одно не помогло! Конечно, я использую виртуальный хостинг.
В конце концов, я решил проблему, используя «относительный URL» внутри заголовка перенаправления!
аннулировал файлы cookie сеанса
работал как шарм!
источник
У меня такая же проблема. Я работал над этим несколько часов, и это сводило меня с ума.
В моем случае проблема заключалась в вызове 404 из- за отсутствия файла favicon.ico только в Chrome и Firefox. Остальные навигаторы работали нормально.
источник
Когда я использую относительный путь "dir / file.php" с функцией header (), у меня работает. Я думаю, что сеанс почему-то не сохраняется при перенаправлении с использованием полного url ...
источник
Это поставило меня в тупик на долгое время (и этот пост было здорово найти!), Но для всех, кто все еще не может получить сеансы между перенаправлениями страниц, чтобы работать ... мне пришлось зайти в файл php.ini и включить куки :
Я думал, что сеансы работают без файлов cookie ... на самом деле я знаю, что они ДОЛЖНЫ ... но это решило мою проблему, по крайней мере, до тех пор, пока я не смогу понять, что может происходить в более широкой картине.
источник
У меня была аналогичная проблема, хотя мой контекст был немного другим. У меня была локальная установка для разработки на машине с именем хоста
windows
и IP-адресом192.168.56.2
.Я мог получить доступ к системе, используя любое из:
После входа в систему мой PHP-код будет перенаправлять, используя:
Если предыдущее доменное имя, используемое для доступа к системе, не было
windows
, данные сеанса будут потеряны. Я решил это, изменив код на:Теперь он работает независимо от того, какое локальное доменное имя или IP-адрес вводит пользователь.
Надеюсь, это может быть кому-то полезно.
источник
Я столкнулся с этой проблемой на одной конкретной странице. Я устанавливал значения $ _SESSION на других страницах прямо перед перенаправлением, и все работало нормально. Но эта конкретная страница не работала.
Наконец я понял, что на этой конкретной странице я разрушал сеанс в начале страницы, но никогда не запускал его снова. Итак, моя функция уничтожения изменилась с:
чтобы:
И все заработало!
источник
У меня была такая же проблема. Внезапно НЕКОТОРЫЕ из моих переменных сеанса не сохраняются на следующей странице. Проблема оказалась (в php7.1) в вашем заголовке не должно быть WWW, например https: // mysite . в порядке, https: //www.mysite . потеряет переменные сеанса страниц. Не все, только эта страница.
источник
www.mysite.com
он рассматривается как совершенно другой домен, чемblog.mysite.com
или простоmysite.com
Я боролся с этим в течение нескольких дней, проверяя / пробуя все решения, но моя проблема заключалась в том, что я больше не звонил
session_start();
после перенаправления. Я просто предположил, что сеанс «все еще жив».Так что не забывайте об этом!
источник
У меня была такая же проблема, и я нашел самый простой способ. Я просто перенаправил на перенаправленный .html с одной строкой JS
вместо PHP
Надеюсь, это поможет.
Любовь грамм
источник
Если вы используете,
session_set_cookie_params()
вы можете проверить, передаете ли вы четвертый параметр$secure
какtrue
. Если да, то вам нужно получить доступ к URL-адресу с помощью https.Значение
$secure
true означает, что сеанс доступен только в рамках защищенного запроса. Это может повлиять на вас больше локально, чем на стадии или в производственной среде.Упоминаю об этом, потому что я потратил большую часть сегодняшнего дня, пытаясь найти эту проблему, и это то, что решило ее для меня. Меня только что добавили в этот проект, и никто не упомянул, что для этого нужен https.
Таким образом, вы можете использовать https локально или установить для
$secure
параметра значение,FALSE
а затем использовать http локально. Просто не забудьте вернуть его в значение true, когда будете вносить изменения.В зависимости от вашего локального сервера, вы , возможно , придется редактировать
DocumentRoot
вhttpd-ssl.conf
сервера , так что локальный URL обслуживается по протоколу HTTPS.источник
Другая возможная причина:
Это место для хранения на моем сервере. Место на моем сервере заполнено. Итак, я удалил несколько файлов и папок со своего сервера и попробовал.
Сработало !!!
Я сохраняю свой сеанс в AWS Dynamo DB, но он по-прежнему ожидает, что на моем сервере останется место для обработки сеанса. Не знаю почему !!!
источник
Если вы используете Laravel и столкнулись с этой проблемой, вам нужно сохранить данные сеанса перед перенаправлением.
источник
У меня также была такая же проблема с неработающим перенаправлением, и я попробовал все решения, которые смог найти, мое перенаправление заголовка использовалось в форме.
Я решил это, поместив перенаправление заголовка на другую страницу php 'signin_action.php' и передав параметры переменных, которые я хотел, в параметрах url, а затем переназначил их в форме 'signin_action.php'.
signin.php
signin_action.php
Это не красивый обходной путь, но он сработал.
источник
Для меня ошибка заключалась в том, что я пытался сохранить несериализуемый объект в сеансе, чтобы при попытке записать сеанс возникло исключение. Но поскольку весь мой код обработки ошибок уже прекратил выполнение каких-либо операций, я никогда не видел ошибки.
Однако я мог найти его в журналах ошибок Apache.
источник
Просто для записи ... У меня была эта проблема, и после нескольких часов попыток проблема заключалась в том, что диск был заполнен, и сеансы php не могли быть записаны в каталог tmp ... поэтому, если у вас есть эта проблема, проверьте, что слишком...
источник
www
), поэтому выполнениеchown -R www.www
с папкой сеансов устраняет проблему.Для меня Firefox сохранил идентификатор сеанса (PHPSESSID) в файле cookie, но Google Chrome использовал параметр GET или POST. Таким образом, вам нужно только убедиться, что возвращающий скрипт (для меня: PayPal checkout) фиксирует PHPSESSID в параметре url или POST.
источник
Попробовав множество решений здесь, в SO и других блогах ... у меня сработало добавление .htaccess в корень моего сайта.
источник
Если вы используете Wordpress, мне пришлось добавить этот хук и запустить сеанс при инициализации:
источник
У меня ничего не работало, но я нашел причину проблемы (и решил ее):
Проверьте файлы cookie своего браузера и убедитесь, что на разных поддоменах нет файлов cookie сеанса php (например, для « www.website.com » и для « website.com »).
Это было вызвано javascript, который неправильно использовал субдомен для установки файлов cookie и открытия страниц в окнах iframe.
источник
Прежде всего,
session_start()
перед использованием$_SESSION
переменной убедитесь, что вы вызываете .Если вы отключили отчеты об ошибках, попробуйте включить и посмотреть результат.
Наиболее распространенные причины, не упомянутые в ответе @dayuloli:
Проблема с дисковым пространством. Убедитесь, что ваше дисковое пространство не заполнено, вам нужно место для хранения файлов сеанса.
Каталог сеанса может быть недоступен для записи. Вы можете проверить это с помощью
is_writable(session_save_path())
источник
У меня была такая же проблема, и я сошел с ума, ища в своем коде ответ. Наконец, я обнаружил, что мой хостинг недавно обновил версию PHP на моем сервере и неправильно настроил
session_save_path
параметр вphp.ini
файле.Итак, если кто-то прочитает это, пожалуйста, проверьте
php.ini
конфигурацию прежде всего.источник
Убедитесь, что
session_write_close
он не вызывается междуsession_start()
и при настройке сеанса.источник
Теперь, когда GDPR стал нормой, люди, которые задают этот вопрос, вероятно, используют сценарий cookie. Что ж, этот сценарий вызвал у меня проблемы. Судя по всему, PHP использует cookie, вызываемый
PHPSESSID
для отслеживания сеанса. Если этот сценарий удалит его, вы потеряете свои данные.Я использовал этот сценарий cookie . У него есть возможность включить «важные» файлы cookie. Я добавил
PHPSESSID
в список, скрипт перестал удалять куки, и все снова заработало.Вы, вероятно, могли бы включить некоторые настройки PHP, чтобы избежать использования
PHPSESSID
, но если ваш сценарий cookie является причиной проблемы, почему бы не исправить это .источник
Я исправил эту проблему после многих дней отладки, и все это произошло потому, что в моем URL-адресе возврата, полученном от PayPal Express Checkout, не было www. Chrome понимал, что с доменами следует обращаться одинаково, но в других браузерах это не так. При использовании сеансов / файлов cookie и абсолютных путей не забывайте "www"!
источник
Я исправил это, предоставив группе разрешения на запись в путь, по которому PHP хранит файлы сеанса. Вы можете найти путь к сеансу с помощью функции session_save_path ().
источник
Сегодня у меня была эта проблема в проекте, и мне пришлось изменить этот параметр на false (или удалить строки, по умолчанию отключены):
Это произошло потому, что реальный проект работает через http, а не только через https. Нашел дополнительную информацию в документации http://php.net/manual/en/session.security.ini.php
источник
Слишком поздно отвечать, но это сработало для меня
источник
Для меня это была ошибка разрешения, и это разрешило ее:
Я несколько часов тестировал PHP, и последний тест, который я сделал, заключался в том, что я создал два файла session1.php и session2.php.
session1.php:
session2.php:
и он печатал пустой массив.
На этом этапе я подумал, что это может быть проблема с сервером, и на самом деле это было так.
Надеюсь, это кому-то поможет.
источник