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

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

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

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

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

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

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

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

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

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

<?
    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');
?>

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

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

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

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

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

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

проверьте значение "views", когда перед его увеличением. Если по какой-то странной причине он устанавливается в строку, то при добавлении 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. действует ли он одинаково во всех браузерах? Если он работает в одном браузере, а не в другом, вы может возникнуть проблема с конфигурацией в нефункционирующем браузере (т. е. вы отключили cookies и забыли их включить, или блокируете cookies по ошибке).

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

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

Я потратил века, ища ответ на аналогичную проблему. Это не было проблемой с кодом или настройкой, так как очень похожий код отлично работал в другом .php на том же сервере. Оказалось, что проблема была вызвана очень большим количеством данных, сохраняемых в сеансе на этой странице. В одном месте у нас была такая строка:$_SESSION['full_list'] = $full_list здесь $full_list был массивом данных, загруженных из базы данных; каждая строка была массивом около 150 элементов. Когда код был изначально написан пару лет назад БД содержала только около 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 рулит. Надеюсь, это кому-то поможет.

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

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

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

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

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

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

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

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

session.gc_probability=0

Проверьте, используете ли вы 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 должен быть установлен в No cookies, а параметры сеанса должны соответствовать тому, что хочет osc.

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