Php где хранятся файлы сессии

Обновлено: 04.07.2024

Как уже известно, протокол HTTP позволяет веб-приложениям устанавливать "сессии" - диалог между клиентом и сервером, причём состояние этого диалога сохраняется от запроса к запросу.

  • Сервер должен сгенерировать уникальный номер сессии.
  • Номер сессии должен быть передан клиенту (обычно посредством Cookies).
  • Сервер должен уметь сохранять данные сессии в файлах или в базе данных, так чтобы их можно было восстановить, зная номер сессии, который клиент присылает серверу при последующих запросах (тоже посредством Cookies).

Собственно, единственное действие, которое необходимо предпринять в программе на PHP, чтобы шестерёнки механизма сессий закрутились - вызвать одну-единственную функцию: session_start(). Эта функция проделывает все необходимые действия:

  • Проверяет, не прислал ли клиент номер уже существующей сессии в Cookie или в параметрах запроса. Если клиент прислал номер сессии, то данные этой сессии загружаются из места постоянного хранения (например, файла) в память, и становятся доступны программе через массив $_SESSION. Если клиент не прислал номера сессии или такой сессии не существует на сервере - создаётся новая сессия с новым номером, а её данные также доступны через массив $_SESSION, который в случае новой сессии будет пустым. Номер вновь созданной сессии помещается в поле заголовка ответа сервера Set-Cookie.
  • Обеспечивает сохранение данных сессии. После того, как PHP-программа обработала запрос, текущее состояние массива $_SESSION сохраняется в месте постоянного хранения, чтобы вновь стать доступным при следующем запросе клиента.

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

При первом заходе на эту страничку, сервер пришлёт браузеру куки с номером сессии:

И этот же номер сессии браузер будет отправлять обратно серверу при каждом последующем запросе. Теперь, если в браузере очистить куки, на сервере будет создана новая сессия с другим номером, и счёт в нашем тестовом скрипте начнётся заново.

Более реальный пример: логин пользователя

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

Как только удалось зайти на этот "сайт", можно покликать по ссылкам (Ссылка1, Ссылка2), оставаясь при этом залогиненным пользователем.

Какие данные можно хранить в сессии?

По умолчанию PHP хранит данные сессии во временном файле в виде текста. В этом можно убедиться, заглянув в директорию с временными файлами PHP. Эта директория указана в phpinfo() в разделе Environment, TEMP. В этой директории вы найдёте файлы вида sess_4ftvca7jmmnm04q95r3sdsk6r6, где 4ftvca7jmmnm04q95r3sdsk6r6 - номер сессии, переданный в Cookie. Загляните в этот файл: если вы запустили самый первый пример выше, то в файле обнаружится примерно такое содержимое: "value|i:2;". Этот текст представляет собой сериализованное представление содержимого сессии, где хранится всего лишь одна переменная с числом.

Все значения, которые PHP-программа помещает в сессию через массив $_SESSION, при сохранении сессии превращаются в текстовый вид, а затем записываются в файл. Процесс преобразования значений переменных в текст называется "сериализацией". Таким образом, в сессию можно поместить любые данные, которые PHP способен сериализовать.

К счастью, в PHP сериализовать можно не только простые значения вроде чисел и строк, но так же и сложные структуры вроде массивов и объектов:

Этот пример запишет в файл сессии такие данные:

Хранение объектов в сессии

В сессии, как видно, можно хранить объекты. Но при этом следует помнить, что сохраняя в сессии объекты, ссылающиеся каким-либо образом на ваши "самодельные" классы, или объекты-экземпляры ваших классов, необходимо, чтобы объявление этих классов делалось до момента вызова session_start(). То есть, PHP должен знать класс до того, как встретит упоминание о нём при десериализации данных сессии.

При сохранении объектов бывают ситуации, когда стандартная сериализация объекта по каким-либо причинам неприемлема или вовсе невозможна. В таких случаях можно реализовать сериализацию вручную, объявив в классе "волшебные" методы __sleep() и __wakeup().

Кстати, сериализацию возможно осуществлять и "вручную", причём не обязательно для сохранения/загрузки данных сессии. Понадобиться это может, когда некоторые данные в приложении надо сохранить для использования позже, или передать по сети. Функции, которые могут пригодиться при сериализации/десериализации - serialize(), unserialize(), json_encode(), json_decode().

Что нельзя хранить в сессии?

В сессии нельзя хранить то, что нельзя сериализовать. Примером такой сущности может служить любой ресурс PHP. Ресурсы - это сетевые подключения, дескрипторы открытых файлов, подключения к базе данных и некоторые другие объекты. Ресурс в PHP - это ссылка на внутренний объект в недрах PHP, который не доступен непосредственно из программы, но с которым можно работать, вызывая различные функции PHP. Этакий "чёрный ящик", содержимое которого не может и не должно сериализоваться.

Дополнительные возможности

PHP предоставляет разработчику возможность реализовать свой способ хранения данных сессии, например, в базе данных. Для этого необходимо реализовать функции, которые будут сохранять и загружать данные сессии из места постоянного хранения. Затем об этих функциях надо пообщить PHP, вызвав функцию session_set_save_handler.

Для ускорения процесса сохранения и загрузки данных сессии на высоко нагруженных сайтах может использоваться сервер Memcached, который хранит данные в памяти. Поддержка этого способа хранения сессий встроена в PHP и настраивается через файл конфигурации php.ini.

Можно задать имя параметра Сookie, через который передаётся номер сессии, указав его имя, время жизни, домен и другие параметры.

В Интернете можно найти тысячи туториалов о том, что такое сессии, для чего они нужны и как с ними работать. Но, к сожалению, прочитав их, всё равно остаётся множество вопросов. На мой взгляд, самый простой способ разобраться во всём — это посмотреть, как работают сессии изнутри. Т.е. изучить логи обмена браузера и веб-сервера, а также посмотреть, какие данные сохраняются на стороне клиента и на стороне сервера.

После этого многие моменты становятся куда более понятными, а сам механизм работы — более прозрачным.

Работу сессий будем изучать на следующем стандартном скрипте:

Он работает следующим образом:

Блок 1. Функция session_start() создаёт новую сессию или загружает старую, используя уникальный идентификатор сессии PHPSESSID.

Блок 2. Если удалось восстановить сессию, то значение $_SESSION['views'] увеличивается на единицу. Если нет — инициализируется единицей.

По идее, если в браузере включена поддержка кук, механизм должен работать и при каждом обновлении страницы значение счётчика будет увеличиваться на единицу.

Первая загрузка скрипта

Заголовки запроса

Заголовки ответа

Комментарий

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

Сторона сервера

В результате работы скрипта на стороне сервера создаётся файл sess_k33en6ccgcia7125mitj5te4u6 следующего содержания:

Сторона клиента

На стороне клиента создаётся кука PHPSESSID, в которой хранится значение уникального идентификатора сессии.

Примечание. При настройках PHP по умолчанию, время жизни куки PHPSESSID — до закрытия браузера. Т.е. как только браузер будет закрыт, кука будет удалена, а соответственно будет потеряна сессия. Время жизни куки PHPSESSID можно менять, варьируя значение session.cookie_lifetime.

Результат работы скрипта

Вторая загрузка скрипта

Заголовки запроса

Заголовки ответа

Комментарий

Браузер отправляет веб-серверу куку PHPSESSID, используя которую PHP инициализирует массив $_SESSION значениями из файла sess_k33en6ccgcia7125mitj5te4u6. Соответственно, в блоке 2 отрабатывает ветка IF (прямая).

Сторона сервера

В результате работы скрипта содержимое файла sess_k33en6ccgcia7125mitj5te4u6 меняется:

Сторона клиента

На стороне клиента ничего не меняется.

Результат работы скрипта

Что дальше?

Последующие загрузки страницы до закрытия браузера будут работать по аналогии с тем, как работала вторая загрузка скрипта.

Т.к. время жизни куки было ограничено текущей сессией браузера, то после его закрытия уникальный идентификатор сессии будет утерян и при перезапуске процесс пойдёт по новой.

Тем не менее можно вернуться к сохранённой сессии, если явно указать PHPSESSID в качестве параметра скрипта:

Возвращение к сессии довольно условное, т.к. в результате работы скрипта в данном случае кука не создаётся. Заголовки ответа сервера:

Т.е. для поддержания работы именно с этой сессией ко всем ссылкам придётся приписывать ?PHPSESSID=k33en6ccgcia7125mitj5te4u6.

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

Небольшой вопросник (FAQ)

Где физически хранятся данные сессий?

Данные сессий хранятся на сервере. По умолчанию они записываются в файлы, но можно задать свой собственный механизм хранения данных сессий (например с использованием базы данных). Если хотите подробностей, смотрите функцию session_set_save_handler.

Кто генерирует уникальный идентификатор сессии?

Уникальный идентификатор сессии (PHPSESSID) генерирует сервер.

Можно ли написать собственный механизм сессий?

Да, это вполне возможно. Как видите, PHP не использует ничего сверхъестественного — идентификатор сохраняется между запросами с помощью кук, данные сессий хранятся в файлах на сервере.

Например, собственный механизм работы с сессиями есть в популярном фреймворке CodeIgniter.

Насколько безопасен механизм сессий?

Сессия идентифицируется только с помощью уникального идентификатора сессии, поэтому в общем случае злоумышленнику достаточно украсть его, чтобы запутать сервер. Возьмём тестовый скрипт, который мы использовали выше. Если обращение к нему будет с другого IP (по отношению к создавшему сессию), но PHPSESSID будет передаваться тот же самый, то сессия будет успешно восстановлена и счётчик будет увеличиваться с предыдущего сохранённого значения.

Обеспечивать дополнительную защиту придётся вам самим. Например:

    Можно сохранять в данных сессии IP и User-Agent клиента (будет храниться на стороне сервера), а затем при каждом обращении проверять, что актуальные значения совпадают с сохранёнными. В данном случае приходится искать компромисс между безопасностью и удобством работы пользователя.

К примеру, если у пользователя динамический IP и вы используете сессии для поддержания авторизации, но при этом проверяете совпадение IP, то при каждой смене адреса пользователю придётся заново вводить логин и пароль.

Работа сессий с повторной генерацией идентификатора в разрезе

Скрипт

Комментарий

В блоке 1 появляется вызов функции session_regenerate_id с аргументом true, который говорит серверу удалять старые данные сессии при повторной генерации идентификатора. Это вовсе не означает, что данные будут потеряны — они будут доступны с использованием нового идентификатора. При обращении со старым PHPSESSID, сессия восстановлена не будет, а вместо этого будет создана новая.

Примечание. Переменная $_SESSION['initiated'] позволяет отслеживать, была ли сессия только что инициирована или же восстановлена. Проверка if(isset($_SESSION['views'])) необходима для того, чтобы избежать лишней перегенерации идентификатора и отправки двух кук в случае, если сессия только что создана. Если проверки не делать, произойдёт следующее (заголовки ответа сервера):

Первая загрузка скрипта

Заголовки запроса

Заголовки ответа

Комментарий

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

Сторона сервера

В результате работы скрипта на стороне сервера создаётся файл sess_fbbjvmj4ie6tm0sb81hp7jim05 следующего содержания:

Сторона клиента

На стороне клиента создаётся кука PHPSESSID=fbbjvmj4ie6tm0sb81hp7jim05, в которой хранится значение уникального идентификатора сессии.

Результат работы скрипта

Вторая загрузка скрипта

Заголовки запроса

Заголовки ответа

Комментарий

Браузер отправляет серверу куку, тот восстанавливает сессию, видит, что установлен флаг $_SESSION['initiated'] и поэтому генерирует новый идентификатор. Браузеру отдаётся команда установить новую куку.

Сторона сервера

В результате работы скрипта на стороне сервера файл sess_fbbjvmj4ie6tm0sb81hp7jim05, содержащий данные сессии, удаляется. Вместо него создаётся новый файл sess_tj86ptptn95vla890b1ag70au7 следующего содержания:

Сторона клиента

На стороне клиента обновляется кука PHPSESSID. Новое значение PHPSESSID= tj86ptptn95vla890b1ag70au7.

Результат работы скрипта

Далее всё повторяется по сценарию второй загрузки скрипта. При попытке использовать один из старых идентификаторов, сервер не найдёт соответствующий файл и будет создана новая сессия.

В работе использовались

Реклама

Комментарии

Спасибо! Очень полезная статья все, что называется наглядно и по полочкам. Смущает один момент. При повторной генерации все же есть возможности перехватить идентификатор сессии и использовать в своих коварных целях. Риск конечно снижен за счет постоянного обновления этого идентифекатора, а привязка к ip и юзерагентам будет доставлять неудобства пользователям, но может быть существуют еще более надежные способы засчиты от хака сессий?

Сессии являются простым способом хранения информации для отдельных пользователей с уникальным идентификатором сессии. Это может использоваться для сохранения состояния между запросами страниц. Идентификаторы сессий обычно отправляются браузеру через сессионный cookie и используются для получения имеющихся данных сессии. Отсутствие идентификатора сессии или сессионного cookie сообщает PHP о том, что необходимо создать новую сессию и сгенерировать новый идентификатор сессии.

Сессии используют простую технологию. Когда сессия создана, PHP будет либо получать существующую сессию, используя переданный идентификатор (обычно из сессионного cookie) или, если ничего не передавалось, будет создана новая сессия. PHP заполнит суперглобальную переменную $_SESSION сессионной информацией после того, как будет запущена сессия. Когда PHP завершает работу, он автоматически сериализует содержимое суперглобальной переменной $_SESSION и отправит для сохранения, используя сессионный обработчик для записи сессии.

По умолчанию PHP использует внутренний обработчик files для сохранения сессий, который установлен в INI-переменной session.save_handler. Этот обработчик сохраняет данные на сервере в директории, указанной в конфигурационной директиве session.save_path.

Сессии могут запускаться вручную с помощью функции session_start() . Если директива session.auto_start установлена в 1 , сессия автоматически запустится, в начале запроса.

Сессия обычно завершает свою работу, когда PHP заканчивает исполнять скрипт, но может быть завершена и вручную с помощью функции session_write_close() .

<?php
session_start ();
if (!isset( $_SESSION [ 'count' ])) $_SESSION [ 'count' ] = 0 ;
> else $_SESSION [ 'count' ]++;
>
?>

НЕ ОЧИЩАЙТЕ $_SESSION целиком, используя unset($_SESSION) , так как это отключит возможность регистрации сессионных переменных через суперглобальную переменную $_SESSION .

Вы не можете использовать ссылки в сессионных переменных, так как не существует реального способа восстановления ссылки к другой переменной.

Are $_SESSION переменные хранятся на клиенте или сервере?

Как уже упоминалось, содержимое хранится на сервере. Однако сеанс идентифицируется идентификатором сеанса, который хранится у клиента и отправляется с каждым запросом. Обычно идентификатор сеанса хранится в файле cookie, но он также может быть добавлен к URL-адресам. (Это PHPSESSID query-параметр вы несколько раз видите)

они обычно хранятся на сервере. Где они хранятся, зависит от вас как разработчика. Вы можете использовать session.save_handler переменной конфигурации и session_set_save_handler для управления сохранением сеансов на сервере. Метод сохранения по умолчанию-сохранение сеансов в файлы. Где они спасаются контролируется session.save_path переменной.

одно дополнение: следует отметить, что в случае, если "/tmp" - это каталог, в котором хранятся данные сеанса (который, по-видимому, является значением по умолчанию), сеансы не будут сохраняться после перезагрузки этого веб-сервера, поскольку "/tmp" часто очищается во время перезагрузки. Концепция клиентской персистентности стоит и падает с сохранением хранилища на сервере, что может привести к сбою, если каталог "/tmp" используется для данных сеанса.

на Debian (разве это не относится к большинству дистрибутивов Linux?), он сохранен в /var / lib/php5/. Как уже упоминалось выше, он настроен в PHP.Ини.

Я использую Ubuntu, и мои сеансы хранятся в /var/lib/php5.

Как отметил г-н Тейлор, это обычно устанавливается в php.Ини. Обычно они хранятся в виде файлов в определенном каталоге.

для ubuntu 16.10 сеансы сохраняются в /var/lib/php/session/.

Как это работает? Откуда он знает, что это я?

большинство сеансов устанавливают пользовательский ключ (называемый sessionid) на компьютере пользователя, который выглядит примерно так: 765487cf34ert8dede5a562e4f3a7e12. Затем, когда сеанс открывается на другой странице, он сканирует компьютер на наличие пользовательского ключа и запускается на сервер, чтобы получить ваши переменные.

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

Читайте также: