Данные сеанса PHP не сохраняются

Спасибо за всю полезную информацию. Оказывается, мой хост изменил серверы и начал использовать другой путь сохранения сеанса, отличный от / var / php_sessions, которого больше не было. Решением было бы объявить ini_set(' session.save_path','SOME WRITABLE PATH'); во всех моих файлах сценариев, но это было бы болью. Я поговорил с хостом, и они явно установили путь сеанса к реальному пути, который действительно существовал. Надеюсь, это поможет любому, кто имеет проблемы с сеансом.

Убедитесь, что вы не смешиваете https: // с http: //. Переменные сеанса не распространяются между безопасными и небезопасными сеансами.

С той же проблемой, что случилось со мной, наш администратор сервера изменил session.cookie_secure на boolean на On, что означает, что файлы cookie будут отправляться только через безопасное соединение. Поскольку cookie не был найден, php каждый раз создавал новый сеанс, поэтому переменные сеанса не видели.

Используйте phpinfo() и проверьте настройки session.* .

Возможно, информация хранится в файлах cookie, и ваш браузер не принимает файлы cookie, что-то в этом роде.

Сначала проверьте это и верните результаты.

Вы также можете сделать print_r($_SESSION); иметь свалку этой переменной и видеть содержимое ….

Что касается вашего phpinfo() , является ли session.save_path действительным? Имеет ли ваш веб-сервер права на запись в этот каталог?

Надеюсь это поможет.

У меня была следующая проблема

index.php

 <? session_start(); $_SESSION['a'] = 123; header('location:index2.php'); ?> 

index2.php

 <? session_start(); echo $_SESSION['a']; ?> 

Переменная $_SESSION['a'] установлена ​​неправильно. Затем я изменил index.php соответственно

 <? session_start(); $_SESSION['a'] = 123; session_write_close(); header('location:index2.php'); ?> 

Я не знаю, что это значит внутри, я просто объясняю себе, что изменение переменной сеанса не было достаточно быстрым 🙂

Проверьте, доступен ли путь сохранения сеанса веб-сервером.

Убедитесь, что вы включили файлы cookie. (Я забыл, когда я выключил их, чтобы проверить что-то)

Используйте firefox с расширением firebug, чтобы проверить, настроен ли файл cookie и передан ли он обратно.

И на несвязанной ноте, начните смотреть на php5, потому что php 4.4.9 является последней из серии php4.

Проверьте, кто является группой и владельцем папки, в которой работает скрипт. Если идентификатор группы или идентификатор пользователя ошибочны, например, установите для root, это приведет к тому, что сеансы не будут сохранены должным образом.

Проверьте значение «просмотров», прежде чем увеличивать его. Если по какой-то причудливой причине он получает строку, тогда, когда вы добавите 1 к ней, она всегда будет возвращать 1.

 if (isset($_SESSION['views'])) { if (!is_numeric($_SESSION['views'])) { echo "CRAP!"; } ++$_SESSION['views']; } else { $_SESSION['views'] = 1; } 

Ну, мы можем исключить ошибку кода, потому что я проверил код на своем собственном сервере (PHP 5).

Вот что нужно проверить:

1. Вы вызываете session_unset () или session_destroy () где угодно? Эти функции немедленно удаляют данные сеанса. Если я поместил их в конец моего скрипта, он начнет вести себя так же, как вы описываете.

2. Он действует одинаково во всех браузерах? Если он работает в одном браузере, а не в другом, у вас может возникнуть проблема с конфигурацией в не функционирующем браузере (т. Е. Вы отключили куки-файлы и забыли включить их или заблокировали файлы cookie по ошибке).

3. Доступна ли папка сеанса? Вы не можете проверить это с помощью is_writable (), поэтому вам нужно будет перейти в папку (из phpinfo () он выглядит как / var / php_sessions) и убедитесь, что сеансы фактически создаются.

Если вы установите сеанс в php5, попробуйте прочитать его на странице php4, он может не выглядеть в нужном месте! Сделайте страницы одной и той же версией php или установите session_path.

Я потратил годы на поиск ответа на подобную проблему. Это не проблема с кодом или настройкой, так как очень похожий код отлично работал в другом .php на том же сервере. Оказалось, что проблема была вызвана очень большим количеством данных, которые сохраняются в сеансе на этой странице. В одном месте у нас была строка вроде: $_SESSION['full_list'] = $full_list где $full_list был массивом данных, загружаемых из базы данных; каждая строка представляла собой массив из примерно 150 элементов. Когда код был изначально написан пару лет назад, DB содержал только около 1000 строк, поэтому $full_list содержал около 100 элементов, каждый из которых представлял собой массив из примерно 20 элементов. Со временем 20 элементов превратились в 150 и 1000 рядов, превратившихся в 17000, поэтому код хранит около 64 мегабайт данных в сеансе. По-видимому, при хранении этого количества данных он отказался хранить что-либо еще. Как только мы изменили код для локального использования данных, не сохраняя его в сеансе, все сработало отлично.

Я знаю одно решение, которое я нашел (OSX с Apache 1 и только что переключился на PHP5), когда у меня была аналогичная проблема, заключалась в том, что отключение 1 конкретного ключа (т.е. unset ($ _ SESSION ['key]);) заставляло его не сохранять. Как только я не отменил этот ключ, он больше не спасен. Я никогда не видел этого снова, кроме этого сервера на другом сайте, но тогда это была другая переменная. Ничего особенного.

Спасибо за это Дэррил. Это помогло мне. Я удалял переменную сеанса, и по какой-то причине она не позволяла сеансу совершать транзакции. теперь я просто устанавливаю его вместо null (что отлично подходит для моего приложения), и он работает.

Я знаю одно решение, которое я нашел (OSX с Apache 1 и только что переключился на PHP5), когда у меня была аналогичная проблема, заключалась в том, что отключение 1 конкретного ключа (т.е. unset ($ _ SESSION ['key]);) заставляло его не сохранять. Как только я не отменил этот ключ, он больше не спасен. Я никогда не видел этого снова, кроме этого сервера на другом сайте, но тогда это была другая переменная. Ничего особенного.

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

Просто хотел добавить небольшую заметку о том, что это также может произойти, если вы случайно пропустили инструкцию session_start () на своих страницах.

У меня был путь cookie сеанса, установленный на «//» вместо «/». Firebug потрясающий. Надеюсь, это поможет кому-то.

У меня возникла эта проблема при использовании защищенных страниц, на которых я пришел с сайта http://www.domain.com/auth.php, перенаправленного на домен.com/destpage.php. Я удалил www из ссылки auth.php, и он сработал. Это бросило меня, потому что все работало иначе; сеанс не был установлен, когда я прибыл в пункт назначения.

Общим вопросом, который часто упускается из виду, также является то, что перед командой session_start () не должно быть никакого другого кода или дополнительного интервала.

У меня была эта проблема до того, где у меня была пустая строка перед session_start (), из-за которой она не работала должным образом.

отредактируйте свой php.ini, я думаю, значение session.gc_probability равно 1, поэтому установлено значение 0

session.gc_probability = 0

Добавление моего решения:

Проверьте доступ к правильному домену . Я использовал www.mysite.com для начала сеанса и пытался получить его с mysite.com (без www ).

Я решил это, добавив перехват htaccess всех доменов на www, чтобы быть на безопасной стороне / сайте.

Также проверьте, используете ли вы http или https.

Проверьте, используете ли вы session_write_close (); в любом месте, я использовал это право после другого сеанса, а затем пытался снова написать на сеанс, и он не работал .. так что просто комментируйте, что sh * t out

Еще несколько вещей, которые я должен был сделать (у меня была такая же проблема: отсутствие сохранения sesson после обновления PHP до 5.4). Вам это не нужно, в зависимости от того, что содержит php.ini вашего сервера (проверьте phpinfio ());

 session.use_trans_sid=0 ; Do not add session id to URI (osc does this) session.use_cookies=0; ; ensure cookies are not used session.use_only_cookies=0 ; ensure sessions are OK to use IMPORTANT session.save_path=~/tmp/osc; ; Set to same as admin setting session.auto_start = off; Tell PHP not to start sessions, osc code will do this 

В принципе, ваш php.ini должен быть настроен на отсутствие файлов cookie, а параметры сеанса должны соответствовать тому, что хочет osc.

Вам также может потребоваться изменить несколько фрагментов кода сеанса в application_top.php – создание объектов, где в вызовах tep_session_is_registered (…) (например, объект навигации) не существует ни одного, установить переменные $ HTTP_ для новых $ _SERVER и несколько других тестов isset для пустых объектов (google для информации). Я закончил тем, что смог использовать исходные файлы session.php (включая / классы и включает / функции) со слегка измененным application_top.php, чтобы снова начать работу. Настройки php.ini были основной проблемой, но это, конечно, зависит от того, что ваша серверная компания установила в качестве значений по умолчанию.