Php где хранятся файлы сессии
Сессии являются простым способом хранения информации для отдельных пользователей с уникальным идентификатором сессии. Это может использоваться для сохранения состояния между запросами страниц. Идентификаторы сессий обычно отправляются браузеру через сессионный 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() .
НЕ ОЧИЩАЙТЕ $_SESSION целиком, используя unset($_SESSION) , так как это отключит возможность регистрации сессионных переменных через суперглобальную переменную $_SESSION .
Вы не можете использовать ссылки в сессионных переменных, так как не существует реального способа восстановления ссылки к другой переменной.
Первая загрузка скрипта
Заголовки запроса
Заголовки ответа
Комментарий
В исходном запросе браузер не идентифицировал себя никаким образом, поэтому механизм сессий PHP сгенерировал новый уникальный идентификатор сессии и скомандовал браузеру создать куку, в которой будет храниться этот самый идентификатор.
Сторона сервера
В результате работы скрипта на стороне сервера создаётся файл sess_fbbjvmj4ie6tm0sb81hp7jim05 следующего содержания:
Сторона клиента
На стороне клиента создаётся кука PHPSESSID=fbbjvmj4ie6tm0sb81hp7jim05, в которой хранится значение уникального идентификатора сессии.
Результат работы скрипта
Когда умирает сессия?
Интересный вопрос, можете задать его матёрым разработчикам – когда PHP удаляет файлы просроченных сессий? Ответ есть в официальном руководстве, но не в явном виде – так что запоминайте:
Сборщик мусора (garbage collection) может запускаться при вызове функции session_start() , вероятность запуска зависит от двух директив session.gc_probability и session.gc_divisor, первая выступает в качестве делимого, вторая – делителя, и по умолчанию эти значения 1 и 100, т.е. вероятность того, что сборщик будет запущен и файлы сессий будут удалены – примерно 1%.
Задание
Измените значение директивы session.gc_divisor так, чтобы сборщик мусора запускался каждый раз, проверьте что это так и происходит.
PHP сессии под скальпелем. Как работают PHP сессии изнутри
В Интернете можно найти тысячи туториалов о том, что такое сессии, для чего они нужны и как с ними работать. Но, к сожалению, прочитав их, всё равно остаётся множество вопросов. На мой взгляд, самый простой способ разобраться во всём — это посмотреть, как работают сессии изнутри. Т.е. изучить логи обмена браузера и веб-сервера, а также посмотреть, какие данные сохраняются на стороне клиента и на стороне сервера.
После этого многие моменты становятся куда более понятными, а сам механизм работы — более прозрачным.
Работу сессий будем изучать на следующем стандартном скрипте:
// блок 1
session_start();
// блок 2
if ( isset ($_SESSION[ ‘views’ ]))
$_SESSION[ ‘views’ ]+ +;
else
$_SESSION[ ‘views’ ] = 1;
Он работает следующим образом:
Блок 1. Функция session_start() создаёт новую сессию или загружает старую, используя уникальный идентификатор сессии PHPSESSID.
Блок 2. Если удалось восстановить сессию, то значение $_SESSION[‘views’] увеличивается на единицу. Если нет — инициализируется единицей.
По идее, если в браузере включена поддержка кук, механизм должен работать и при каждом обновлении страницы значение счётчика будет увеличиваться на единицу.
Вторая загрузка скрипта
Заголовки запроса
Заголовки ответа
Комментарий
Браузер отправляет серверу куку, тот восстанавливает сессию, видит, что установлен флаг $_SESSION[‘initiated’] и поэтому генерирует новый идентификатор. Браузеру отдаётся команда установить новую куку.
Сторона сервера
В результате работы скрипта на стороне сервера файл sess_fbbjvmj4ie6tm0sb81hp7jim05, содержащий данные сессии, удаляется. Вместо него создаётся новый файл sess_tj86ptptn95vla890b1ag70au7 следующего содержания:
Сторона клиента
На стороне клиента обновляется кука PHPSESSID. Новое значение PHPSESSID= tj86ptptn95vla890b1ag70au7.
Результат работы скрипта
Далее всё повторяется по сценарию второй загрузки скрипта. При попытке использовать один из старых идентификаторов, сервер не найдёт соответствующий файл и будет создана новая сессия.
Вторая загрузка скрипта
Заголовки запроса
Заголовки ответа
Комментарий
Браузер отправляет серверу куку, тот восстанавливает сессию, видит, что установлен флаг $_SESSION['initiated'] и поэтому генерирует новый идентификатор. Браузеру отдаётся команда установить новую куку.
Сторона сервера
В результате работы скрипта на стороне сервера файл sess_fbbjvmj4ie6tm0sb81hp7jim05, содержащий данные сессии, удаляется. Вместо него создаётся новый файл sess_tj86ptptn95vla890b1ag70au7 следующего содержания:
Сторона клиента
На стороне клиента обновляется кука PHPSESSID. Новое значение PHPSESSID= tj86ptptn95vla890b1ag70au7.
Результат работы скрипта
Далее всё повторяется по сценарию второй загрузки скрипта. При попытке использовать один из старых идентификаторов, сервер не найдёт соответствующий файл и будет создана новая сессия.
По шагам
А теперь поясню по шагам алгоритм, как работает сессия в PHP, на примере следующего кода (настройки по умолчанию):
- после вызова session_start() PHP ищет в cookie идентификатор сессии по имени прописанном в session.name – это PHPSESSID
- если нет идентификатора – то он создаётся (см. session_id()), и создаёт пустой файл сессии по пути session.save_path с именем sess_ , в ответ сервера будет добавлены заголовки, для установки cookie =
- если идентификатор присутствует, то ищем файл сессии в папке session.save_path :
- не находим – создаём пустой файл с именем sess_ (идентификатор может содержать лишь символы из диапазонов a-z , A-Z , 0-9 , запятую и знак минус)
- находим, читаем файл и распаковываем данные (см. session_decode()) в супер-глобальную переменную $_SESSION
- когда скрипт закончил свою работу, то все данные из $_SESSION запаковывают с использованием session_encode() в файл по пути session.save_path с именем sess_
Задание
Задайте в вашем браузере произвольное значение куки с именем PHPSESSID , пусть это будет 1234567890 , обновите страницу, проверьте, что у вас создался новый файл sess_1234567890
Самая тривиальная ошибка
Ошибка у которой более полумиллиона результатов в выдаче Google:
Cannot send session cookie – headers already sent by
Cannot send session cache limiter – headers already sent
Для получения таковой, создайте файл session.error.php со следующим содержимым:
Во второй строке странная “магия” – это фокус с буфером вывода, я ещё расскажу о нём в одной из следующих статей, пока считайте это лишь строкой длинной в 4096 символов, в данном случае – это всё пробелы
Запустите, предварительно удалив cookie, и получите приведенные ошибки, хоть текст ошибок и разный, но суть одна – поезд ушёл – сервер уже отправил браузеру содержимое страницы, и отправлять заголовки уже поздно, это не сработает, и в куках не появилось заветного идентификатора сессии. Если вы стокнулись с данной ошибкой – ищите место, где выводится текст
раньше времени, это может быть пробел до символов в одном из подключаемых файлов, и ладно если это пробел, может быть и какой-нить непечатный символ вроде BOM, так что будьте внимательны, и вас сия зараза не коснется (как-же, … гомерический смех).
Задание
Для проверки полученных знаний, я хочу, чтобы вы реализовали свой собственный механизм сессий и заставили приведенный код работать:
Небольшой вопросник (FAQ)
Где физически хранятся данные сессий?
Данные сессий хранятся на сервере. По умолчанию они записываются в файлы, но можно задать свой собственный механизм хранения данных сессий (например с использованием базы данных). Если хотите подробностей, смотрите функцию session_set_save_handler.
Кто генерирует уникальный идентификатор сессии?
Уникальный идентификатор сессии (PHPSESSID) генерирует сервер.
Можно ли написать собственный механизм сессий?
Да, это вполне возможно. Как видите, PHP не использует ничего сверхъестественного — идентификатор сохраняется между запросами с помощью кук, данные сессий хранятся в файлах на сервере.
Например, собственный механизм работы с сессиями есть в популярном фреймворке CodeIgniter.
Насколько безопасен механизм сессий?
Сессия идентифицируется только с помощью уникального идентификатора сессии, поэтому в общем случае злоумышленнику достаточно украсть его, чтобы запутать сервер. Возьмём тестовый скрипт, который мы использовали выше. Если обращение к нему будет с другого IP (по отношению к создавшему сессию), но PHPSESSID будет передаваться тот же самый, то сессия будет успешно восстановлена и счётчик будет увеличиваться с предыдущего сохранённого значения.
Обеспечивать дополнительную защиту придётся вам самим. Например:
-
Можно сохранять в данных сессии IP и User-Agent клиента (будет храниться на стороне сервера), а затем при каждом обращении проверять, что актуальные значения совпадают с сохранёнными. В данном случае приходится искать компромисс между безопасностью и удобством работы пользователя.
К примеру, если у пользователя динамический IP и вы используете сессии для поддержания авторизации, но при этом проверяете совпадение IP, то при каждой смене адреса пользователю придётся заново вводить логин и пароль.
А если надо сессию в базе данных хранить?
Для хранения сессии в БД потребуется изменить хранилище сессии и указать PHP как им пользоваться, для этой цели создан интерфейс SessionHandlerInterface и функция session_set_save_handler.
Отдельно замечу, что не надо писать собственные обработчики сессий для redis и memcache – когда вы устанавливаете данные расширения, то вместе с ними идут и соответствующие обработчики, так что RTFM наше всё. Ну и да, обработчик нужно указывать до вызова session_start() ;)
Задание
Реализуйте SessionHandlerInterface для хранения сессии в MySQL, проверьте, работает ли он.
Это задание со звёздочкой, для тех кто уже познакомился с базами данных.
Небольшой вопросник (FAQ)
Где физически хранятся данные сессий?
Данные сессий хранятся на сервере. По умолчанию они записываются в файлы, но можно задать свой собственный механизм хранения данных сессий (например с использованием базы данных). Если хотите подробностей, смотрите функцию session_set_save_handler.
Кто генерирует уникальный идентификатор сессии?
Уникальный идентификатор сессии (PHPSESSID) генерирует сервер.
Можно ли написать собственный механизм сессий?
Да, это вполне возможно. Как видите, PHP не использует ничего сверхъестественного — идентификатор сохраняется между запросами с помощью кук, данные сессий хранятся в файлах на сервере.
Например, собственный механизм работы с сессиями есть в популярном фреймворке CodeIgniter.
Насколько безопасен механизм сессий?
Сессия идентифицируется только с помощью уникального идентификатора сессии, поэтому в общем случае злоумышленнику достаточно украсть его, чтобы запутать сервер. Возьмём тестовый скрипт, который мы использовали выше. Если обращение к нему будет с другого IP (по отношению к создавшему сессию), но PHPSESSID будет передаваться тот же самый, то сессия будет успешно восстановлена и счётчик будет увеличиваться с предыдущего сохранённого значения.
Обеспечивать дополнительную защиту придётся вам самим. Например:
-
Можно сохранять в данных сессии IP и User-Agent клиента (будет храниться на стороне сервера), а затем при каждом обращении проверять, что актуальные значения совпадают с сохранёнными. В данном случае приходится искать компромисс между безопасностью и удобством работы пользователя.
К примеру, если у пользователя динамический IP и вы используете сессии для поддержания авторизации, но при этом проверяете совпадение IP, то при каждой смене адреса пользователю придётся заново вводить логин и пароль.
В работе использовались
Реклама
Комментарии
Спасибо! Очень полезная статья все, что называется наглядно и по полочкам. Смущает один момент. При повторной генерации все же есть возможности перехватить идентификатор сессии и использовать в своих коварных целях. Риск конечно снижен за счет постоянного обновления этого идентифекатора, а привязка к ip и юзерагентам будет доставлять неудобства пользователям, но может быть существуют еще более надежные способы засчиты от хака сессий?
Комментарии
Спасибо! Очень полезная статья все, что называется наглядно и по полочкам. Смущает один момент. При повторной генерации все же есть возможности перехватить идентификатор сессии и использовать в своих коварных целях. Риск конечно снижен за счет постоянного обновления этого идентифекатора, а привязка к ip и юзерагентам будет доставлять неудобства пользователям, но может быть существуют еще более надежные способы засчиты от хака сессий?
What is the default location of session files on an installation of Apache/PHP on Ubuntu 10.10?
В работе использовались
А есть ли жизнь без “печенек”?
PHP может работать с сессией даже если cookie в браузере отключены, но тогда все URL на сайте будут содержать параметр с идентификатором вашей сессии, и да – это ещё настроить надо, но оно вам надо? Мне не приходилось это использовать, но если очень хочется – я просто скажу где копать:
PHP и сессия
Я надеюсь, у вас уже установлен PHP на компьютере, т.к. дальше я буду приводить примеры, и их надо будет запускать
Вот вам статейка на тему PHP is meant to die, или вот она же на русском языке, но лучше отложите её в закладки “на потом”.
Перво-наперво необходимо “стартовать” сессию – для этого воспользуемся функцией session_start(), создайте файл session.start.php со следующим содержимым:
Запустите встроенный в PHP web-server в папке с вашим скриптом:
Там будет много чего, интересует нас только вот эта строчка в ответе сервера (почистите куки, если нет такой строчки, и обновите страницу):
Увидев сие, браузер сохранит у себя куку с именем `PHPSESSID`:
PHPSESSID – имя сессии по умолчанию, регулируется из конфига php.ini директивой session.name, при необходимости имя можно изменить в самом конфигурационном файле или с помощью функции session_name()
И теперь – обновляем страничку, и видим, что браузер отправляет эту куку на сервер, можете попробовать пару раз обновить страницу, результат будет идентичным:
Итого, что мы имеем – теория совпала с практикой, и это просто отлично.
Следующий шаг – сохраним в сессию произвольное значение, для этого в PHP используется супер-глобальная переменная $_SESSION , сохранять будем текущее время – для этого вызовем функцию date():
Обновляем страничку и видим время сервера, обновляем ещё раз – и время обновилось. Давайте теперь сделаем так, чтобы установленное время не изменялось при каждом обновлении страницы:
Обновляем – время не меняется, то что нужно. Но при этом мы помним, PHP умирает, значит данную сессию он где-то хранит, и мы найдём это место…
Что дальше?
Последующие загрузки страницы до закрытия браузера будут работать по аналогии с тем, как работала вторая загрузка скрипта.
Т.к. время жизни куки было ограничено текущей сессией браузера, то после его закрытия уникальный идентификатор сессии будет утерян и при перезапуске процесс пойдёт по новой.
Тем не менее можно вернуться к сохранённой сессии, если явно указать PHPSESSID в качестве параметра скрипта:
Возвращение к сессии довольно условное, т.к. в результате работы скрипта в данном случае кука не создаётся. Заголовки ответа сервера:
Т.е. для поддержания работы именно с этой сессией ко всем ссылкам придётся приписывать ?PHPSESSID=k33en6ccgcia7125mitj5te4u6.
Если куки в браузере отключены, то можно передавать идентификатор сессии через параметры, как мы делали выше. Причём в PHP есть механизм, который будет сам дописывать нужный параметр в ссылки и добавлять скрытые поля в формы. Принцип работы точно такой же, как и с куками, поэтому не будем разбирать этот случай отдельно.
Что дальше?
Последующие загрузки страницы до закрытия браузера будут работать по аналогии с тем, как работала вторая загрузка скрипта.
Т.к. время жизни куки было ограничено текущей сессией браузера, то после его закрытия уникальный идентификатор сессии будет утерян и при перезапуске процесс пойдёт по новой.
Тем не менее можно вернуться к сохранённой сессии, если явно указать PHPSESSID в качестве параметра скрипта:
Возвращение к сессии довольно условное, т.к. в результате работы скрипта в данном случае кука не создаётся. Заголовки ответа сервера:
Т.е. для поддержания работы именно с этой сессией ко всем ссылкам придётся приписывать ?PHPSESSID=k33en6ccgcia7125mitj5te4u6.
Если куки в браузере отключены, то можно передавать идентификатор сессии через параметры, как мы делали выше. Причём в PHP есть механизм, который будет сам дописывать нужный параметр в ссылки и добавлять скрытые поля в формы. Принцип работы точно такой же, как и с куками, поэтому не будем разбирать этот случай отдельно.
Вторая загрузка скрипта
Заголовки запроса
Заголовки ответа
Комментарий
Браузер отправляет веб-серверу куку PHPSESSID, используя которую PHP инициализирует массив $_SESSION значениями из файла sess_k33en6ccgcia7125mitj5te4u6. Соответственно, в блоке 2 отрабатывает ветка IF (прямая).
Сторона сервера
В результате работы скрипта содержимое файла sess_k33en6ccgcia7125mitj5te4u6 меняется:
Сторона клиента
На стороне клиента ничего не меняется.
Результат работы скрипта
Первая загрузка скрипта
Заголовки запроса
Заголовки ответа
Комментарий
В исходном запросе браузер не идентифицировал себя никаким образом, поэтому механизм сессий PHP сгенерировал новый уникальный идентификатор сессии и скомандовал браузеру создать куку, в которой будет храниться этот самый идентификатор.
Сторона сервера
В результате работы скрипта на стороне сервера создаётся файл sess_k33en6ccgcia7125mitj5te4u6 следующего содержания:
Сторона клиента
На стороне клиента создаётся кука PHPSESSID, в которой хранится значение уникального идентификатора сессии.
Примечание. При настройках PHP по умолчанию, время жизни куки PHPSESSID — до закрытия браузера. Т.е. как только браузер будет закрыт, кука будет удалена, а соответственно будет потеряна сессия. Время жизни куки PHPSESSID можно менять, варьируя значение session.cookie_lifetime.
Результат работы скрипта
Первая загрузка скрипта
Заголовки запроса
Заголовки ответа
Комментарий
В исходном запросе браузер не идентифицировал себя никаким образом, поэтому механизм сессий PHP сгенерировал новый уникальный идентификатор сессии и скомандовал браузеру создать куку, в которой будет храниться этот самый идентификатор.
Сторона сервера
В результате работы скрипта на стороне сервера создаётся файл sess_k33en6ccgcia7125mitj5te4u6 следующего содержания:
Сторона клиента
На стороне клиента создаётся кука PHPSESSID, в которой хранится значение уникального идентификатора сессии.
Примечание. При настройках PHP по умолчанию, время жизни куки PHPSESSID — до закрытия браузера. Т.е. как только браузер будет закрыт, кука будет удалена, а соответственно будет потеряна сессия. Время жизни куки PHPSESSID можно менять, варьируя значение session.cookie_lifetime.
Результат работы скрипта
В заключение
В этой статье вам дано шесть заданий, при этом они касаются не только работы с сессиями, но так же познакомят вас с MySQL и с функциями работы со строками. Для усвоения этого материала – отдельной статьи не нужно, хватит и мануала по приведенным ссылкам – никто за вас его читать не будет. Дерзайте!
P.S. Если узнали что-то новое из статьи – отблагодарите автора – зашарьте статью в социалках ;)
Работа сессий с повторной генерацией идентификатора в разрезе
Скрипт
// блок 1
session_start();
if ( isset ($_SESSION[ ‘initiated’ ]))
session_regenerate_id();
else
$_SESSION[ ‘initiated’ ] = true ;
// блок 2
if ( isset ($_SESSION[ ‘views’ ]))
$_SESSION[ ‘views’ ]++ ;
else
$_SESSION[ ‘views’ ] = 1;
Комментарий
В блоке 1 появляется вызов функции session_regenerate_id с аргументом true, который говорит серверу удалять старые данные сессии при повторной генерации идентификатора. Это вовсе не означает, что данные будут потеряны — они будут доступны с использованием нового идентификатора. При обращении со старым PHPSESSID, сессия восстановлена не будет, а вместо этого будет создана новая.
Примечание. Переменная $_SESSION[‘initiated’] позволяет отслеживать, была ли сессия только что инициирована или же восстановлена. Проверка if(isset($_SESSION[‘views’])) необходима для того, чтобы избежать лишней перегенерации идентификатора и отправки двух кук в случае, если сессия только что создана. Если проверки не делать, произойдёт следующее (заголовки ответа сервера):
Работа сессий с повторной генерацией идентификатора в разрезе
Скрипт
Комментарий
В блоке 1 появляется вызов функции session_regenerate_id с аргументом true, который говорит серверу удалять старые данные сессии при повторной генерации идентификатора. Это вовсе не означает, что данные будут потеряны — они будут доступны с использованием нового идентификатора. При обращении со старым PHPSESSID, сессия восстановлена не будет, а вместо этого будет создана новая.
Примечание. Переменная $_SESSION['initiated'] позволяет отслеживать, была ли сессия только что инициирована или же восстановлена. Проверка if(isset($_SESSION['views'])) необходима для того, чтобы избежать лишней перегенерации идентификатора и отправки двух кук в случае, если сессия только что создана. Если проверки не делать, произойдёт следующее (заголовки ответа сервера):
8 Answers 8
The new default for save_path in upcoming releaess (sic) will be the empty string, which causes the temporary directory to be probed.
To find the current session save path, you can use
Refer to this answer to find out what the temp path is when this function returns an empty string.
The location is set and not 'default' under Ubuntu 10.10. A clean build of PHP may give you this, but not under any Debian/Ubuntu builds I have used. The orig question pertains to Ubuntu 10.10. So, just look it up on command line per last comment (or my answer) as location can differ from 'default'/blank/tmp depending on Linux distribution used..
Warning!! I think running php -r 'echo session_save_path(), "\n";' as mentioned above will use a different php.ini file (perhaps /etc/php/7.0/cli/php.ini instead of /etc/php/7.0/apache2/php.ini), and therefore might have a different value of "session.save_path"
@Magmatic is correct, there are TWO php.ini files, php_info() will tell you which one is in use during the current eval, and locate php.ini will help you find them
Please note (as per last 2 comments): Using the CLI PHP version (command line) can produce different results depending on distro and compile. The main thing is it is NOT the Apache version. (Though the INI files may be identical as far as session paths). Better to look in/grep proper Apache PHP.INI.
First check the value of session.save_path using ini_get('session.save_path') or phpinfo() . If that is non-empty, then it will show where the session files are saved. In many scenarios it is empty by default, in which case read on:
On Ubuntu or Debian machines, if session.save_path is not set, then session files are saved in /var/lib/php5 .
On RHEL and CentOS systems, if session.save_path is not set, session files will be saved in /var/lib/php/session
I think that if you compile PHP from source, then when session.save_path is not set, session files will be saved in /tmp (I have not tested this myself though).
I'm using Ubuntu 12.04.5 LTS and, for some reason (I have not changed anything in php.ini ) my sessions are under /var/lib/php5/sessions
"Not set"? It is set - but commented out in php.ini. This does not mean it doesn't have a value or isn't 'set'.. From command line just do: php -i | grep session.save_path for CLI (and probably Apache) session save path. Also, a given php.ini will normally show the 'default' path - it's just commented out.
DEFAULT Ubuntu 16.04 : /etc/php/7.0/*/php.ini -> ;session.save_path = "/var/lib/php/sessions" -- A comment doesn't mean 'not set' is all I meant. It is set obviously to something other than 'blank' (/tmp).. and is NOT an empty/null string
If unsure of compiled default for session.save_path , look at the pertinent php.ini .
Normally, this will show the commented out default value.
Ubuntu/Debian old/new php.ini locations:
Older php5 with Apache: /etc/php5/apache2/php.ini
Older php5 with NGINX+FPM: /etc/php5/fpm/php.ini
Ubuntu 16+ with Apache: /etc/php/*/apache2/php.ini *
Ubuntu 16+ with NGINX+FPM - /etc/php/*/fpm/php.ini *
* /*/ = the current PHP version(s) installed on system.
To show the PHP version in use under Apache:
Since PHP 7.3 is the version running for this example, you would use that for the php.ini :
$ grep "session.save_path" /etc/php/7.3/apache2/php.ini
Or, combined one-liner:
$ APACHEPHPVER=$(a2query -m | grep "php" | grep -Eo "6+\.2+") \ && grep ";session.save_path" /etc/php/$/apache2/php.ini
Or, use PHP itself to grab the value using the "cli" environment (see NOTE below):
These will also work:
The 'cli' (command line) version of php.ini normally has the same default values as the Apache2/FPM versions (at least as far as the session.save_path ). You could also use a similar command to echo the web server's current PHP module settings to a webpage and use wget/curl to grab the info. There are many posts regarding phpinfo() use in this regard. But, it is quicker to just use the PHP interface or grep for it in the correct php.ini to show it's default value.
Сессии являются простым способом хранения информации для отдельных пользователей с уникальным идентификатором сессии. Это может использоваться для сохранения состояния между запросами страниц. Идентификаторы сессий обычно отправляются браузеру через сессионный 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() .
session_start ();
if (!isset( $_SESSION [ 'count' ])) $_SESSION [ 'count' ] = 0 ;
> else $_SESSION [ 'count' ]++;
>
?>?php
НЕ ОЧИЩАЙТЕ $_SESSION целиком, используя unset($_SESSION) , так как это отключит возможность регистрации сессионных переменных через суперглобальную переменную $_SESSION .
Вы не можете использовать ссылки в сессионных переменных, так как не существует реального способа восстановления ссылки к другой переменной.
Замечание:
Сессии, использующие файлы (по умолчанию в PHP), блокируют файл сессии сразу при открытии сессии функцией session_start() или косвенно при указании session.auto_start. После блокировки, ни один другой скрипт не может получить доступ к этому же файлу сессии, пока он не будет закрыт или при завершении скрипта или при вызове функции session_write_close() .
Скорее всего это станет проблемой для сайтов, которые активно используют AJAX и делают несколько одновременных запросов. Простейшим путём решить эту проблему будет вызов функции session_write_close() сразу же как только все требуемые изменения в сессии будут сделаны, предпочтительно ближе к началу работы скрипта. Также можно использовать другой механизм сессии, который поддерживает конкурентный доступ.
Всем хорошего дня. Перед вами первая статья из серии PHP для начинающих разработчиков. Это будет необычная серия статей, тут не будет echo "Hello World" , тут будет hardcore из жизни PHP программистов с небольшой примесью “домашней работы” для закрепления материала.
Начну с сессий – это один из самых важных компонентов, с которыми вам придется работать. Не понимая принципов его работы – наворотите делов. Так что во избежание проблем я постараюсь рассказать о всех возможных нюансах.
Изначально подразумевали, что по этому протоколу будет только HTML передаваться, отсель и название, а сейчас чего только не отправляют(•_ㅅ_•)=^.^=
А вот пример ответа:
Так, вроде с протоколом разобрались – он простой, ведёт свою историю аж с 1992-го года, так что идеальным его не назовешь, но какой есть – отправили запрос – получите ответ, и всё, сервер и клиент никоим образом более не связаны. Но подобный сценарий отнюдь не единственный возможный, у нас же может быть авторизация, сервер должен каким-то образом понимать, что вот этот запрос пришёл от определенного пользователя, т.е. клиент и сервер должны общаться в рамках некой сессии. И да, для этого придумали следующий механизм:
- при авторизации пользователя, сервер генерирует и запоминает уникальный ключ – идентификатор сессии, и сообщает его браузеру
- браузер сохраняет этот ключ, и при каждом последующем запросе, его отправляет
Для реализации этого механизма и были созданы cookie (куки, печеньки) – простые текстовые файлы на вашем компьютере, по файлу для каждого домена (хотя некоторые браузеры более продвинутые, и используют для хранения SQLite базу данных), при этом браузер накладывает ограничение на количество записей и размер хранимых данных (для большинства браузеров это 4096 байт, см. RFC 2109 от 1997-го года)
Т.е. если украсть cookie из вашего браузера, то можно будет зайти на вашу страничку в facebook от вашего имени? Не пугайтесь, так сделать нельзя, по крайней мере с facebook, и дальше я вас научу как можно защититься от данного вида атаки на ваших пользователей.
Давайте теперь посмотрим как изменятся наши запрос-ответ, будь там авторизация:
Метод у нас изменился на POST, и в теле запроса у нас передаются логин и пароль (если использовать метод GET, то строка запроса будет содержать логин и пароль, и может оказаться сохраненной на каких нибудь промежуточных прокси серверах, что очень плохо).
Ответ сервер будет содержать заголовок Set-Cookie: KEY=VerySecretUniqueKey , что заставит браузер сохранить эти данные в файлы cookie, и при следующем обращении к серверу – они будут отправлены и опознаны сервером:
Работа с сессиями в PHP
Как уже известно, протокол 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_fbbjvmj4ie6tm0sb81hp7jim05 следующего содержания:
Сторона клиента
На стороне клиента создаётся кука PHPSESSID=fbbjvmj4ie6tm0sb81hp7jim05, в которой хранится значение уникального идентификатора сессии.
Результат работы скрипта
Всё тайное становится явным
По умолчанию, PHP хранит сессию в файлах – за это отвечает директива session.save_handler, путь по которому сохраняются файлы ищите в директиве session.save_path, либо воспользуйтесь функцией session_save_path() для получения необходимого пути.
В вашей конфигурации путь к файлам может быть не указан, тогда файлы сессии будут хранится во временных файлах вашей системы – вызовите функцию sys_get_temp_dir() и узнайте где это потаённое место.
Так, идём по данному пути и находим ваш файл сессии (у меня это файл sess_dap83arr6r3b56e0q7t5i0qf91 ), откроем его в текстовом редакторе:
Как видим – вот оно наше время, вот в каком хитром формате хранится наша сессия, но мы можем внести правки, поменять время, или можем просто вписать любую строку, почему бы и нет:
Для преобразования этой строки в массив нужно воспользоваться функцией session_decode(), для обратного преобразования – session_encode() – это зовется сериализацией, вот только в PHP для сессий – она своя – особенная, хотя можно использовать и стандартную PHP сериализацию – пропишите в конфигурационной директиве session.serialize_handler значение php_serialize и будет вам счастье, и $_SESSION можно будет использовать без ограничений – в качестве индекса теперь вы сможете использовать цифры и специальные символы | и ! в имени (за все 10+ лет работы, ни разу не надо было :)
Задание
Напишите свою функцию, аналогичную по функционалу session_decode() , вот вам тестовый набор данных для сессии (для решения знаний регулярных выражений не требуется), текст для преобразования возьмите из файла вашей текущей сессии:
Так, что мы ещё не пробовали? Правильно – украсть “печеньки”, давайте запустим другой браузер и добавим в него теже самые cookie. Я вам для этого простенький javascript написал, скопируйте его в консоль браузера и запустите, только не забудьте идентификатор сессии поменять на свой:
Вот теперь у вас оба браузера смотрят на одну и туже сессию. Я выше упоминал, что расскажу о способах защиты, рассмотрим самый простой способ – привяжем сессию к браузеру, точнее к тому, как браузер представляется серверу – будем запоминать User-Agent и проверять его каждый раз:
Задание
Добавьте в код проверку на IP пользователя, если проверка не прошла – удалите скомпрометированную сессию.
Вторая загрузка скрипта
Заголовки запроса
Заголовки ответа
Комментарий
Браузер отправляет веб-серверу куку PHPSESSID, используя которую PHP инициализирует массив $_SESSION значениями из файла sess_k33en6ccgcia7125mitj5te4u6. Соответственно, в блоке 2 отрабатывает ветка IF (прямая).
Сторона сервера
В результате работы скрипта содержимое файла sess_k33en6ccgcia7125mitj5te4u6 меняется:
Сторона клиента
На стороне клиента ничего не меняется.
Результат работы скрипта
Реклама
Читайте также: