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

Question

У меня есть одна из таких ситуаций «Клянусь, что я не касался сервера». Я честно не касался ни одного скрипта php. Проблема, с которой я сталкиваюсь, заключается в том, что php-данные не сохраняются на разных страницах или обновлениях страниц. Я знаю, что новый сеанс создается правильно, потому что я могу установить переменную сеанса (например, $ _SESSION ['foo'] = "foo" и распечатать его обратно на одной странице очень хорошо. Но когда я пытаюсь использовать ту же переменную на другой странице он не установлен! Существуют ли какие-либо php-функции или информация, которые я могу использовать на моем хост-сервере, чтобы посмотреть, что происходит?

Вот пример скрипта, который не работает на сервере моих хостов Сейчас:

<?php 
session_start(); 
if(isset($_SESSION['views'])) 
    $_SESSION['views'] = $_SESSION['views']+ 1; 
else 
    $_SESSION['views'] = 1; 

echo "views = ". $_SESSION['views']; 
echo '<p><a href="page1.php">Refresh</a></p>'; 
?> 

переменная «Views» никогда не будет увеличиваться после выполнения обновления страницы Я думаю, это проблема на их стороне, но я хотел, чтобы убедиться, что я не полный идиот первым..

Вот phpinfo() для сервера моих хозяев (PHP Version 4.4.7):

Answer 1

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

Answer 2

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

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

Проверьте это и верните результаты.

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

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

Вот что проверить:

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

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

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

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

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

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

Answer 10

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

Answer 11

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

Answer 12

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

Answer 13

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

Answer 14

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

Answer 15

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

Answer 16

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

index.php

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

index2.php

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

Переменная $_SESSION['a'] не была установлена ​​правильно. Тогда я изменил index.php acordingly

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

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

Answer 17

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

Answer 18

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

Answer 19

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

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

Answer 20

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

session.gc_probability=0 

Answer 21

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

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

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

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

Answer 22

Еще несколько вещей, которые я должен был сделать (у меня была такая же проблема: отсутствие сохранения 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 должен быть установлен не печеньем и параметры сеанса должны быть согласованы с тем, что OSC хочет.

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