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

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

Была та же проблема - со мной случилось то, что администратор нашего сервера изменил логическое значение session.cookie_secure на 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 и забыли их включить или по ошибке блокируете файлы cookie).

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

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

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

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

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

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

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

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

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

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

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

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

Добавляю свое решение:

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

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

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

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

session.gc_probability=0

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

Еще несколько вещей, которые мне нужно было сделать (у меня была та же проблема: отсутствие сохранения 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 для информации). В итоге я смог использовать оригинал sessions.php файлы (включает в себя/классы и включает в себя/функции) со слегка измененным application_top.php чтобы все снова пошло своим чередом. Настройки php.ini были основной проблемой, но это, конечно, зависит от того, что ваша серверная компания установила по умолчанию.