php session не сохраняется
Семь причин почему не сохраняется сессия в PHP
Когда вебмастер начинает работать с сессиями, он часто сталкивается с тем, что сессия не сохраняется при переходе на другую страницу. Причин может быть множество, ниже представлен список наиболее распространённых, изучив которые, вы сможете решить проблему.
Почему не сохраняется сессия при переходе на другую страницу?
1. Вы забыли запустить сессию
Пожалуй, это самая распространённая причина почему не сохраняется сессия. Запуск сессии посредством функции session_start(); должен осуществляться на каждой странице, где используется сессия. Лучше всего session_start(); писать сразу после открывающего тега
2. Сессия уничтожается в коде
3. Хранилище сессии недоступно для записи
4. После отправки заголовка не используется exit();
5. Cookies не включены в браузере
Убедитесь, что использование cookies разрешено в браузере, в котором используется сайт.
6. Редирект с одного домена на другой
При редиректе с одного домена на другой сессия потеряется. Даже если это один домен и он отличается наличием «www», например при перенаправлении с «site.com» на «www.site.com» сессия пропадёт, убедитесь, что у вас этого не происходит.
7. У вас нет favicon.ico
Пожалуй, самая экзотическая из всех вышеперечисленных причин, почему сессия может не сохранятся. Я не знаю почему так происходит, но если у вас нет favicon’а на сайте, браузер Google Chrome может «потерять» вашу сессию. Это бывает не на всех серверах, подобный глюк я обнаружил на nginx’е.
Здравствуй дорогой читатель! Я рад приветствовать тебя на страницах моего блога. Уже несколько лет я занимаюсь веб-программированием и рад поделиться с тобой своими знаниями и советами. Если тебе понравились мои статьи, ты можешь подписаться на рассылку блога, из неё ты узнаешь много интересного!
полдня сегодня мучился над http://www.bestflora.ru/, оказывается UTF был с сигнатурой сохранен! :)) Так что тоже берите на заметку
Есть ещё одна. Если произошел вывод текста(пробельные символы после закрывающего тэга PHP), до session_start(). сессия также может слететь. Но не всегда. Кто-нибудь может объяснить, почему так происходит
При обновлении страницы (по нажатию определенной кнопки) сиссия каждый раз обновляется, то есть старое значение, сохраненное в ней, я не могу использовать (для того, чтобы, к примеру, накопить сумму чего-либо), хотя вчера этот же код отлично работал и все накапливал, а сегодня — не работает. И еще вылетает ошибка:
Почитал на форумах про похожие проблемы, но у меня на первый взгляд все в порядке (мне так кажется). Возможно, это из-за того, что я отправляю данные методом POST в form.
Как же решить эту проблему?
2 ответа 2
Ошибки с текстом headers already sent by появляются если перед попыткой отправить HTTP-заголовок веб-сервер уже начал отправлять тело ответа. По опыту это случается в следующих случаях:
Полный ответ на ваш вопрос есть в самом вопросе. Другого ответа здесь быть не может.
Интерпретатор PHP сообщает вам, что вывод данных начался до вызова функции session_start, т.о. сессии не могут обеспечить корректное сохранение указанных данных.
Для работы сессий используются Cookie. Сохранение Куки происходит только в области Заголовков ответа вашего сервера. Как только вы начинаете передавать любые данные (теги, пробел, абсолютно любой символ) заголовки вы уже не сможете отправить и именно об этом вам говорит ваша ошибка. Нужно найти эти данные до функции session_start и переместить, если они нужны, либо удалить.
На вашем примере невозможно определить эти дополнительные данные. В комментариях к вопросу вам предлагали переопределить кодировку файла Unicode без BOM (Notepad++ удобный быстрый редактор, смена кодировок в один клик).
Иногда (очень редко) в конфигурации PHP или htaccess указывается auto_prepend_file который автоматически включает в любой скрипт какой-то другой файл в самое начало и этот файл может передать данные о которых вы можете забыть или не знать. Проверьте конфигурацию PHP.
Данные сеанса PHP не сохраняются
вот пример скрипта, который не работает на сервере моих хостов на данный момент:
переменная «views» никогда не увеличивается после обновления страницы. Я думаю, что это проблема с их стороны, но сначала я хотел убедиться, что я не полный идиот.
вот phpinfo () для сервера моих хостов (PHP версии 4.4.7): 
22 ответов
Спасибо за полезную информацию. Оказывается, мой хост изменил серверы и начал использовать другой путь сохранения сеанса, отличный от /var/php_sessions, который больше не существовал. Решением было бы объявить ini_set(‘ session.save_path’,’SOME WRITABLE PATH’); во всех моих файлах сценариев, но это было бы больно. Я поговорил с хостом, и они явно установили путь сеанса на реальный путь, который существовал. Надеюсь,это поможет любому, у кого проблемы с сеансом.
проверьте, чтобы убедиться, что вы не смешиваете https:// с http://. Переменные сеанса не перетекают между безопасными и небезопасными сеансами.
использовать phpinfo() и проверяем session.* настройки.
возможно, информация хранится в cookies, и ваш браузер не принимает cookies, что-то в этом роде.
сначала проверьте это и вернитесь с результатами.
вы также можете сделать print_r($_SESSION); чтобы иметь дамп этой переменной и видеть содержимое.
Надежда эта помощь.
у меня была следующая проблема
Я не знаю, что это значит внутренне, я просто объясняю себе, что изменение переменной сеанса было недостаточно быстрым:)
Проверьте, доступен ли путь сохранения сеанса для записи веб-сервером.
убедитесь,что куки включены.. (Я забываю, когда я выключаю их, чтобы проверить что-то)
используйте firefox с расширением firebug, чтобы увидеть, если cookie устанавливается и передается обратно.
и на несвязанной ноте начните смотреть на php5, потому что php 4.4.9 является последним из серии php4.
проверьте, кто является группой и владельцем папки, в которой выполняется скрипт. Если идентификатор группы или пользователя неверен, например, установлен в root, это приведет к неправильному сохранению сеансов.
проверьте значение «views», когда перед его увеличением. Если по какой-то странной причине он устанавливается в строку, то при добавлении 1 к нему он всегда будет возвращать 1.
Ну, мы можем устранить ошибку кода, потому что я тестировал код на своем собственном сервере (PHP 5).
вот что нужно проверить:
вы вызываете session_unset() или session_destroy () в любом месте? Эти функции немедленно удалят данные сеанса. Если я помещу их в конец моего сценария, он начнет вести себя точно так, как вы описываете.
действует ли он одинаково во всех браузерах? Если он работает в одном браузере, а не в другом, вы может возникнуть проблема с конфигурацией в нефункционирующем браузере (т. е. вы отключили cookies и забыли их включить, или блокируете cookies по ошибке).
доступна ли папка сеанса для записи? Вы не можете проверить это с помощью is_writable (), поэтому вам нужно будет перейти в папку (из phpinfo () это выглядит как /var/php_sessions) и убедиться, что сеансы действительно создаются.
Если вы установите сеанс в php5, а затем попробуйте прочитать его на странице php4, он может выглядеть не в правильном месте! Сделайте страницы той же версии php или установите session_path.
Я знаю, что одно решение, которое я нашел (OSX с Apache 1 и просто переключился на PHP5), когда у меня была аналогичная проблема, состояло в том, что сбросил 1 конкретный ключ (т. е. unset ($_SESSION[‘key’]);) заставлял его не сохранять. Как только я больше не снимал этот ключ, он сохранялся. Я никогда не видел, кроме как на этом сервере на другом сайте, но тогда это был другой переменной. И ничего особенного.
Спасибо за это Дэррил. Это мне помогло. Я удалял переменная сеанса, и по какой-то причине она удерживала сеанс от фиксации. теперь я просто устанавливаю его на null (что хорошо для моего приложения), и он работает.
Я знаю одно решение, которое я нашел (OSX с Apache 1 и просто переключился на PHP5), когда у меня была аналогичная проблема: сбросить 1 конкретный ключ (т. е. unset ($_SESSION[‘key’]);) вызывал его не сохранять. Как только я больше не снимал этот ключ, он сохранялся. Я никогда не видел, кроме как на этом сервере на другом сайте, но тогда это был другой переменной. И ничего особенного.
вот одна распространенная проблема, которую я не видел в других комментариях:ваш хост работает с кешем? Если они автоматически кэшируют результаты каким-то образом, вы получите такое поведение.
просто хотел добавить небольшое примечание, что это также может произойти, если вы случайно пропустите оператор session_start() на своих страницах.
У меня был путь cookie сеанса установлен в «//» Вместо «/». Firebug рулит. Надеюсь, это кому-то поможет.
часто упускается из виду, что перед командой session_start() не должно быть другого кода или дополнительного интервала.
У меня была эта проблема раньше, когда у меня была пустая строка перед session_start (), которая заставила ее работать неправильно.
добавление моего решения:
проверьте, если вы получаете доступ к правильный домен. Я использовал www.mysite.com чтобы начать сеанс, и попытался получить его от mysite.com (без www ).
я решил это, добавив перезапись htaccess всех доменов в www, чтобы быть на безопасной стороне/сайте.
также проверьте, используете ли вы http или https.
отредактируйте свой php.ini.
Я думаю, что ценность сессии.gc_probability 1, поэтому установите его в 0.
Проверьте, используете ли вы session_write_close(); в любом месте я использовал это сразу после другого сеанса, а затем пытался снова написать в сеанс, и он не работал.. так что просто прокомментируйте, что sh * t out
проблемы с сессиями (сохранение значения переменной).
flashWomen
Guest
проблемы с сессиями (сохранение значения переменной).
Честным образом прочитала http://phpfaq.ru/sessions и похожие топики, но все равно у меня не получается сохранить переменные в сессии, как надо.
Взывaю к коллективному разуму 
если вкратце
1. в auth.php:
видно, что сессия действително стартовала, только почему-то никаких значений не сохранила.
output:
Tool: 8ca35e42d8d0034beac03100c80ef0b0
Новичок
Новичок
Новичок
flashWomen
Guest
session_name убрала, ничего не поменялось.
кстати, скрипт из примера
у меня тоже работает.
не работает только при перенаправлении
Новичок
flashWomen
Guest
output:
Header Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
Header Accept-Charset: KOI8-R,utf-8;q=0.7,*;q=0.7
Header Accept-Encoding: gzip, deflate, compress;q=0.9
Header Accept-Language: de-de,en;q=0.7,en-us;q=0.3
Header Connection: keep-alive
Header Cookie: PHPSESSID=5870c2c2a8e941eae630bab2ec8d67cf
Header Host: bla-bla-host
Header Keep-Alive: 300
Header User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20031007
Новичок
Нет, я имею ввиду то что написано по ссылке, которую тебе дали. Установи себе программу ieHTTPHeaders (в любом случае на будущее пригодится) и скопируй заголовки сюда. Как от сервера так и от клиента.
flashWomen
Guest
Новичок
Нет большой лог тут не нужен. Приведи здесь четыре заголовка.
flashWomen
Guest
HTTP/1.1 200 OK
Date: Tue, 12 Jul 2005 14:33:40 GMT
Server: Apache/1.3.28 (Linux/SuSE) mod_ssl/2.8.15 OpenSSL/0.9.7b PHP/4.3.3
X-Powered-By: PHP/4.3.3
Set-Cookie: PHPSESSID=2deecfceefbd760806b6321e909d11b7; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
PHP для начинающих. Сессия
Начну с сессий — это один из самых важных компонентов, с которыми вам придется работать. Не понимая принципов его работы — наворотите делов. Так что во избежание проблем я постараюсь рассказать о всех возможных нюансах.
Но для начала, чтобы понять зачем нам сессия, обратимся к истокам — к HTTP протоколу.
HTTP Protocol
Изначально подразумевали, что по этому протоколу будет только HTML передаваться, отсель и название, а сейчас чего только не отправляют и =^.^= и（•_ㅅ_•）
Чтобы не ходить вокруг да около, давайте я вам приведу пример общения по HTTP протоколу.
Вот пример запроса, каким его отправляет ваш браузер, когда вы запрашиваете страницу http://example.com :
А вот пример ответа:
Это очень упрощенные примеры, но и тут можно увидеть из чего состоят HTTP запрос и ответ:
Т.е. если украсть cookie из вашего браузера, то можно будет зайти на вашу страничку в facebook от вашего имени? Не пугайтесь, так сделать нельзя, по крайней мере с facebook, и дальше я вам покажу один из возможных способов защиты от данного вида атаки на ваших пользователей.
Давайте теперь посмотрим как изменятся наши запрос-ответ, будь там авторизация:
Метод у нас изменился на POST, и в теле запроса у нас передаются логин и пароль. Если использовать метод GET, то строка запроса будет содержать логин и пароль, что не очень правильно с идеологической точки зрения, и имеет ряд побочных явлений в виде логирования (например, в том же access.log ) и кеширования паролей в открытом виде.
Как можно заметить, заголовки отправляемые браузером (Request Headers) и сервером (Response Headers) отличаются, хотя есть и общие и для запросов и для ответов (General Headers)
Сервер узнал нашего пользователя по присланным cookie, и дальше предоставит ему доступ к личной информации. Так, ну вроде с сессиями и HTTP разобрались, теперь можно вернутся к PHP и его особенностям.
PHP и сессия
Я надеюсь, у вас уже установлен PHP на компьютере, т.к. дальше я буду приводить примеры, и их надо будет запускать
Вот вам статейка на тему PHP is meant to die, или вот она же на русском языке, но лучше отложите её в закладки «на потом».
Перво-наперво необходимо «стартовать» сессию — для этого воспользуемся функцией session_start(), создайте файл session.start.php со следующим содержимым:
Запустите встроенный в PHP web-server в папке с вашим скриптом:
Запустите браузер, и откройте в нём Developer Tools (или что там у вас), далее перейдите на страницу http://127.0.0.1:8080/session.start.php — вы должны увидеть лишь пустую страницу, но не спешите закрывать — посмотрите на заголовки которые нам прислал сервер:
Там будет много чего, интересует нас только вот эта строчка в ответе сервера (почистите куки, если нет такой строчки, и обновите страницу):
Увидев сие, браузер сохранит у себя куку с именем `PHPSESSID`:
PHPSESSID — имя сессии по умолчанию, регулируется из конфига php.ini директивой session.name, при необходимости имя можно изменить в самом конфигурационном файле или с помощью функции session_name()
И теперь — обновляем страничку, и видим, что браузер отправляет эту куку на сервер, можете попробовать пару раз обновить страницу, результат будет идентичным:
Итого, что мы имеем — теория совпала с практикой, и это просто отлично.
Обновляем страничку и видим время сервера, обновляем ещё раз — и время обновилось. Давайте теперь сделаем так, чтобы установленное время не изменялось при каждом обновлении страницы:
Обновляем — время не меняется, то что нужно. Но при этом мы помним, PHP умирает, значит данную сессию он где-то хранит, и мы найдём это место…
Всё тайное становится явным
В вашей конфигурации путь к файлам может быть не указан, тогда файлы сессии будут хранится во временных файлах вашей системы — вызовите функцию sys_get_temp_dir() и узнайте где это потаённое место.
Так, идём по данному пути и находим ваш файл сессии (у меня это файл sess_dap83arr6r3b56e0q7t5i0qf91 ), откроем его в текстовом редакторе:
Как видим — вот оно наше время, вот в каком хитром формате хранится наша сессия, но мы можем внести правки, поменять время, или можем просто вписать любую строку, почему бы и нет:
Так, что мы ещё не пробовали? Правильно — украсть «печеньки», давайте запустим другой браузер и добавим в него теже самые cookie. Я вам для этого простенький javascript написал, скопируйте его в консоль браузера и запустите, только не забудьте идентификатор сессии поменять на свой:
Вот теперь у вас оба браузера смотрят на одну и туже сессию. Я выше упоминал, что расскажу о способах защиты, рассмотрим самый простой способ — привяжем сессию к браузеру, точнее к тому, как браузер представляется серверу — будем запоминать User-Agent и проверять его каждый раз:
Ключевое слово в предыдущем абзаце похоже, в реальных проектах cookies уже давно «бегают» по HTTPS протоколу, таким образом никто их не сможет украсть без физического доступа к вашему компьютеру или смартфону
Стоит упомянуть директиву session.cookie-httponly, благодаря ей сессионная кука будет недоступна из JavaScript’a. Кроме этого — если заглянуть в мануал функции setcookie(), то можно заметить, что последний параметр так же отвечает за HttpOnly. Помните об этом — эта настройка позволяет достаточно эффективно бороться с XSS атаками в практически всех браузерах.
По шагам
А теперь поясню по шагам алгоритм, как работает сессия в PHP, на примере следующего кода (настройки по умолчанию):
А есть ли жизнь без «печенек»?
PHP может работать с сессией даже если cookie в браузере отключены, но тогда все URL на сайте будут содержать параметр с идентификатором вашей сессии, и да — это ещё настроить надо, но оно вам надо? Мне не приходилось это использовать, но если очень хочется — я просто скажу где копать:
А если надо сессию в базе данных хранить?
Отдельно замечу, что не надо писать собственные обработчики сессий для redis и memcache — когда вы устанавливаете данные расширения, то вместе с ними идут и соответствующие обработчики, так что RTFM наше всё. Ну и да, обработчик нужно указывать до вызова session_start() 😉
Когда умирает сессия?
За время жизни сессии отвечает директива session.gc_maxlifetime. По умолчанию, данная директива равна 1440 секундам (24 минуты), понимать её следует так, что если к сессии не было обращении в течении заданного времени, то сессия будет считаться «протухшей» и будет ждать своей очереди на удаление.
Интересен другой вопрос, можете задать его матёрым разработчикам — когда PHP удаляет файлы просроченных сессий? Ответ есть в официальном руководстве, но не в явном виде — так что запоминайте:
Самая тривиальная ошибка
Ошибка у которой более полумиллиона результатов в выдаче Google:
Cannot send session cookie — headers already sent by
Cannot send session cache limiter — headers already sent
Для получения таковой, создайте файл session.error.php со следующим содержимым:
Во второй строке странная «магия» — это фокус с буфером вывода, я ещё расскажу о нём в одной из следующих статей, пока считайте это лишь строкой длинной в 4096 символов, в данном случае — это всё пробелы
Для проверки полученных знаний, я хочу, чтобы вы реализовали свой собственный механизм сессий и заставили приведенный код работать:
Блокировка
Ещё одна распространённая ошибка у новичков — это попытка прочитать файл сессии пока он заблокирован другим скриптом. Собственно, это не совсем ошибка, это недопонимание принципа блокировки 🙂
Но давайте ещё раз по шагам:
«Воткнутся» в данную ошибку очень легко, создайте два файла:
Есть пару вариантов, как избежать подобного явления — «топорный» и «продуманный».
«Топорный»
Использовать самописный обработчик сессий, в котором «забыть» реализовать блокировку 🙂
Чуть лучше вариант, это взять готовый и отключить блокировку (например у memcached есть такая опция — memcached.sess_locking) O_o
Потратить часы на дебаг кода в поисках редко всплывающей ошибки…
«Продуманный»
Куда как лучше — самому следить за блокировкой сессии, и снимать её, когда она не требуется:
— Если вы уверенны, что вам не потребуется вносить изменения в сессионные данные используйте опцию read_and_close при старте сессии:
Таким образом, блокировка будет снята сразу по прочтению данных сессии.
— Если вам таки нужно вносить изменения в сессию, то после внесения оных закрывайте сессию от записи:
В заключение
В этой статье вам дано семь заданий, при этом они касаются не только работы с сессиями, но так же познакомят вас с MySQL и с функциями работы со строками. Для усвоения этого материала — отдельной статьи не нужно, хватит и мануала по приведенным ссылкам — никто за вас его читать не будет. Дерзайте!