Сессия
Сессия (от лат. – sessio — заседание, англ. – session) – это промежуток времени, охватывающий работу пользователя в интернете с момента открытия первой и до последней ссылок. Рассчитывается как разница во времени между начальным и финальным запросами. Однако последняя страница может просматриваться пользователем различное время, из чего, следовательно, измерение времени между двумя запросами становится более затруднительным.
Как связана сессия с протоколом HTTP и COOKIES
Что такое сессия можно объяснить, отталкиваясь от протокола HTTP. Сам по себе, этот протокол не располагает способом сохранения состояния между двумя операциями. Т.е., проще говоря, открывая одну страничку, а затем, перейдя с неё на другую, HTTP не сможет установить, что оба запроса принадлежат одному пользователю. И тут на помощь приходит особый метод отслеживания – управление сеансами (нашими сессиями).
Отсюда, отвечая на вопрос, что такое сессия, можно сказать, что это – вспомогательный логический объект, способствующий передачи данных между последовательными HTTP – запросами от одного юзера.
Cookies, как и сессия, хранят сведения о пользователе во время его перемещения по разным страницам и улучшают работу протокола. Но в отличие от второй, где данные хранятся во временных файлах на сервере, они сохраняют их на компьютере пользователя в виде небольших фрагментов.
Для чего нужны сессии
Использование сессий становится незаменимым при работе с такими сайтами, как форумы, доски объявлений и Интернет – магазины, ведь в этом случае нужно сохранять данные о юзере на протяжении нескольких страниц.
Этапы сессии
Всю сессию можно разделить на три этапа:
Советы при использовании сесии
Из-за того, что данные сессии сохраняются на стороннем сервере, то лучше всего не держать большие объемы информации в них, а использовать cookies.
Все, что нужно знать о сессии на сайте
Под сессией принято понимать строго обозначенный промежуток времени, на протяжении которого пользователь пребывает на сайте. Все пользователи для входа в интернет используют специальные программы – браузеры. Идентификация пользователя в интернете осуществляется с учетом его персональных данных, речь идет о cookies-файлах и IP-адресе.
Протяженность сеанса пользователя на сайте определяется исходя из промежутка между первым и последним действием, совершенным им на сайте. Практика показывает, что в ходе измерения протяженности сеанса возникают трудности. В первую очередь это обусловлено отсутствием возможности постоянного контроля над временем просмотра страницы, на которую перешел пользователь по ссылке. На данный момент не существует программного обеспечения, способного выполнять такие задачи.Чтобы разобраться в том, что такое сессия на сайте, рассмотрим следующий пример:
Сессия как событие в сервисах аналитики применяется с целью наблюдения за поведением пользователей, посещающих сайт. Сессия напрямую взаимосвязана со следующими метриками:
На данный момент сессия как событие характеризуется широкой областью применения, одним из вариантов ее использования могут быть следующие сценарии:
В рамках данной статьи мы будем рассматривать сессию применительно к сайту и веб-аналитике. В данном случае сессия выступает в качестве инструмента для определения последовательности запросов, выполняемых пользователем.
Если рассматривать сессию с точки зрения отдельного события, то речь идет о совокупности запросов, отправляемых от лица клиента в момент его взаимодействия с хостом/сервером. Клиент может быть представлен не только в виде браузера, но и в виде поискового робота или веб-приложения. Хост в большинстве случаев – это сайт.
Сессия может включать в себя все запросы, совершенные клиентом на протяжении строго обозначенного промежутка времени.
Сервер самостоятельно классифицирует запросы, поступающие от клиента. Сейчас широко применяется идентификация запроса – cookies-файл, важно отметить, что помимо него существуют и другие варианты. В качестве примера можно рассмотреть идентификацию запросов клиента посредством обращения к параметрам запроса, MAC-адресу, что стало возможным благодаря расширенным HTTP-заголовкам.
Для удаления сессии задействуется функция session_destroy(). Посредством одного вызова можно осуществить удаление всех переменных сеанса. Для удаления одной переменной сессии рекомендуется обратиться к функции unset(), которая дает возможность произвести отключение необходимой переменной.
Каждый сайт содержит в себе не только вход, но и выход, который представлен в виде специального сценария, его основной целевой задачей является комплексная очистка сессии, после этого пользователь попадает на главную страницу.
Если рассматривать сессию в ее взаимосвязи с сайтом, то речь идет о многоаспектном понятии. При этом на практике чаще оно используется в тех случаях, когда возникает необходимость в составлении отчетов веб-аналитики. Комплексное изучение сессии как события позволит увеличить эффективность анализа отчетов веб-аналитики.
Что такое сессия на сайте: описание термина, использование, различия у «Яндекса» и Google
Сессия на сайте — это временной интервал, в течение которого происходит взаимодействие пользователя с сайтом. Отсчет сессии стартует сразу после перехода на сайт.
Понять смысл сессии на сайте очень просто на следующем примере:
Сценарии сессии на сайте
Сессия как событие в «Яндекс.Метрике» и Google Analytics используется для определения поведения посетителей сайта. С сессией непосредственно связаны следующие метрики:
Кроме веб-аналитики, сессия как событие применима в следующих сценариях:
Мы будем рассматривать сессию применительно к сайту и веб-аналитике. В этом контексте сессия используется для обозначения последовательности запросов, которые совершает пользователь.
Клиент и сервер. Как происходит идентификация запроса
Сессия как отдельное событие обозначает серию запросов, которые отправляются от клиента, когда он взаимодействует с каким-либо хостом / сервером. В качестве клиента может быть не только браузер, но и поисковый робот, веб-приложение и т. д. В роли хоста (или сервера) чаще всего выступает определенный сайт.
Под определение сессии могут попадать вообще все запросы, которые сделал клиент на протяжении заданного периода: час, день, неделя и более длительные.
Сервер может различать каждый запрос, который поступает от клиента. Самый популярный вариант идентификации запроса — cookies-файл, но он не единственный. Распространена идентификация запросов клиента через параметры запроса, MAC-адрес, при помощи расширенных HTTP-заголовков.
Как создается сессия на сайте и как заканчивается
Скриптовый язык PHP позволяет управлять сессией при помощи функции session_start() — это начало сессии — и завершать ее функцией session_destroy().
Механизм сессии строится следующим образом:
В качестве события завершения сессии могут выступать:
Клиент и сервер могут сохранять уникальный идентификатор сессии в течение очень длительного времени: неделями, месяцами и даже целый год.
Сессия в системах аналитики «Яндекс» и Google
В «Яндекс.Метрике» термины «сессия» и «визит» можно считать взаимозаменяемыми.
Под последовательностью действий понимается любая пользовательская активность: регистрация события (например, hit или notBounce), переход по URL, просмотр страницы. Для изучения поведения пользователя в рамках визита можно использовать «Вебвизор» «Яндекс.Метрики»:
Визит в «Яндекс.Метрике» считается оконченным в следующих сценариях:
Google Analytics для определения сессии применяет термин веб-сеанс. Google Analytics трактует сеанс как время, которое пользователь уделил сайту или приложению.
Сеанс в Google Analytics можно схематично представить в виде последовательности действий посетителя:
Сеанс по умолчанию завершается только в трех случаях:
Есть ли разница между сессией и сеансом
То, о чем сейчас пойдет речь, актуально для любой системы веб-аналитики. Сеанс и сессия не являются тождественными понятиями.
Сеанс относится к взаимодействию посетителя с сайтом. Пользовательский сеанс условно состоит из четырех частей:
Сессией же корректнее считать последовательность запросов, которые поступают от единого клиента и которые может идентифицировать сервер.
Браузерное уведомление «Время сессии истекло»: почему оно появляется
Часто в браузере появляется сообщение «Время сессии истекло». Оно может появляться при разных сценариях, но все они сводятся к одному: продолжительное бездействие на странице.
Стандартное время окончания сессии в языке PHР по умолчанию составляет ровно 24 минуты.
Если страница загружается дольше, появляется эта ошибка.
Заключение
Сегодня мы узнали, что сессия — это не только временной интервал. Это также последовательность запросов или вообще все запросы, которые совершил пользователь после перехода по ссылке. Кроме этого, важно понимать разницу между сессией и сеансом.
Вообще сессия применительно к сайту — больше многозначный термин, чем четко определенный. Но чаще всего его используют, именно когда речь заходит об отчетах веб-аналитики. Правильно понимая сессию как событие, вы можете изучать отчеты веб-аналитики с большей эффективностью.
Подводные камни использования сессий в PHP
Приветствую, уважаемое сообщество.
Прежде всего, хочу поблагодарить за очень полезный ресурс. Не раз находил здесь множество интересных идей и практических советов.
Цель этой статьи — осветить подводные камни использования сессий в PHP. Конечно, есть документация по PHP и масса примеров, и данная статья не претендует на полное руководство. Она призвана раскрыть некоторые ньюансы работы с сессиями и оградить разработчиков от ненужной траты времени.
Самым распространенным примером использования сессий является, конечно, авторизация пользователей. Начнем с самой базовой реализации, чтобы последовательно развивать ее по мере появления новых задач.
(В целях экономии места и времени ограничимся в примерах только самими функциями работы с сессиями, вместо того, чтобы строить здесь полноценное тестовое приложение с красивой иерархией классов, исчерпывающей обработкой ошибок и прочими правильными штуками).
Примечание: Подразумевается, что базовые знания о сессиях PHP у читателя имеются, поэтому принцип работы функций session_start() и session_destroy() освещать здесь не будем. Задачи верстки формы входа и аутентификации пользователя не относятся к теме статьи, поэтому их мы также опустим. Напомню только, что для идентификации пользователя в каждом последующем запросе, нам необходимо в момент успешного входа сохранить в сессионной переменной (с именем userid, например) идентификатор пользователя, который будет доступен во всех последующих запросах в пределах жизни сессии. Также необходимо реализовать обработку результата нашей функции startSession(). Если функция вернула FALSE — отобразить в браузере форму входа. Если функция вернула TRUE, и сессионная переменная, содержащая идентификатор авторизованного пользователя (в нашем случае — userid), существует — отобразить страницу авторизованного пользователя (подробнее об обработке ошибок см. дополнение от 2013-06-07 в разделе о сессионных переменных).
Пока все понятно. Вопросы начинаются, когда требуется реализовать контроль отсутствия активности пользователя (session timeout), дать возможность одновременной работы в одном браузере нескольких пользователей, а также защитить сессии от несанкционированного использования. Об этом и пойдет речь ниже.
Контроль отсутствия активности пользователя встроенными средствами PHP
Первый вопрос, который часто возникает у разработчиков всевозможных консолей для пользователей — автоматическое завершение сеанса в случае отсутствия активности со стороны пользователя. Нет ничего проще, чем сделать это с помощью встроенных возможностей PHP. (Этот вариант не отличается особой надежностью и гибкостью, но рассмотрим его для полноты картины).
Немного пояснений. Как известно, PHP определяет, какую именно сессию нужно запустить, по имени куки, передаваемом браузером в заголовке запроса. Браузер же, в свою очередь, получает этот куки от сервера, куда помещает его функция session_start(). Если время жизни куки в браузере истекло, он не будет передан в запросе, а значит PHP не сможет определить, какую сессию нужно запустить, и расценит это как создание новой сессии. Параметр настроек PHP session.gc_maxlifetime, который устанавливается равным нашему таймауту отсутствия активности пользователя, задает время жизни PHP-сессии и контролируется сервером. Работает контроль времени жизни сессии следующим образом (здесь рассматривается пример хранилища сессий во временных файлах как самый распространенный и установленный по умолчанию в PHP вариант).
Примечание: Здесь следует отметить, что параметр session.gc_maxlifetime действует на все сессии в пределах одного сервера (точнее, в пределах одного главного процесса PHP). На практике это значит, что если на сервере работает несколько сайтов, и каждый из них имеет собственный таймаут отсутствия активности пользователей, то установка этого параметра на одном из сайтов приведет к его установке и для других сайтов. То же касается и shared-хостинга. Для избежания подобной ситуации используются отдельные каталоги сессий для каждого сайта в пределах одного сервера. Установка пути к каталогу сессий производится с помощью параметра session.save_path в файле настроек php.ini, или путем вызова функции ini_set(). После этого сессии каждого сайта будут храниться в отдельных каталогах, и параметр session.gc_maxlifetime, установленный на одном из сайтов, будет действовать только на его сессии. Мы не станем рассматривать этот случай подробно, тем более, что у нас в запасе есть более гибкий вариант контроля отсутствия активности пользователя.
Контроль отсутствия активности пользователя с помощью сессионных переменных
Казалось бы, предыдущий вариант при всей своей простоте (всего пару дополнительных строк кода) дает все, что нам нужно. Но что, если не каждый запрос можно расценивать как результат активности пользователя? Например, на странице установлен таймер, который периодически выполняет AJAX-запрос на получение обновлений от сервера. Такой запрос нельзя расценивать как активность пользователя, а значит автоматическое продление времени жизни сессии является не корректным в данном случае. Но мы знаем, что PHP обновляет время модификации файла сессии автоматически при каждом вызове функции session_start(), а значит любой запрос приведет к продлению времени жизни сессии, и таймаут отсутствия активности пользователя не наступит никогда. К тому же, последнее примечание из предыдущего раздела о тонкостях работы параметра session.gc_maxlifetime может показаться кому-то слишком запутанным и сложным в реализации.
Для решения этой проблемы откажемся от использования встроенных механизмов PHP и введем несколько новых сессионных переменных, которые позволят нам контролировать время отсутствия активности пользователей самостоятельно.
Обработка результата функции sessionStart()
В комментариях обратили внимание на то, что возврат FALSE не дает полного понимания причины ошибки, и это абсолютно справедливо. Я не стал публиковать здесь подробную обработку ошибок (объем статьи и так не маленький), поскольку это не относится напрямую к теме статьи. Но учитывая комментарии, внесу ясность.
Как видно, функция sessionStart может вернуть FALSE в двух случаях. Либо сессию не удалось запустить из-за каких-то внутренних ошибок сервера (например, неправильные настройки сессий в php.ini), либо время жизни сессии истекло. В первом случае мы должны перебросить пользователя на страницу с ошибкой о том, что есть проблемы на сервере, и формой обращения в службу поддержки. Во втором случае мы должны перевести пользователя на форму входа и вывести в ней соответствующее сообщение о том, что время сессии истекло. Для этого нам необходимо ввести коды ошибок и возвращать вместо FALSE соответствующий код, а в вызывающем методе проверять его и действовать соответствующим образом.
Теперь, даже если сессия на сервере по-прежнему существует, она будет уничтожена при первом же обращении к ней, если таймаут отсутствия активности пользователя истек. И это произойдет независимо от того, какое время жизни сессий установлено в глобальных настройках PHP.
Примечание: А что произойдет, если браузер был закрыт, и куки с именем сессии был автоматически уничтожен? Запрос к серверу при следующем открытии браузера не будет содержать куки сессии, и сервер не сможет открыть сессию и проверить таймаут отсутствия активности пользователя. Для нас это равносильно созданию новой сессии и никак не влияет на функционал и безопасность. Но возникает справедливый вопрос — а кто же тогда уничтожит старую сессию, если до сих пор ее уничтожали мы по истечении таймаута? Или она теперь будет висеть в каталоге сессий вечно? Для очистки старых сессий в PHP существует механизм под названием garbage collection. Он запускается в момент очередного запроса к серверу и чистит все старые сессии на основании даты последнего изменения файлов сессий. Но запуск механизма garbage collection происходит не при каждом запросе к серверу. Частота (а точнее, вероятность) запуска определяется двумя параметрами настроек session.gc_probability и session.gc_divisor. Результат от деления первого параметра на второй и есть вероятностью запуска механизма garbage collection. Таким образом, для того, чтобы механизм очистки сессий запускался при каждом запросе к севреру, эти параметры нужно установить в равные значения, например «1». Такой подход гарантирует чистоту каталога сессий, но, очевидно, является слишком накладным для сервера. Поэтому в production-системах по умолчанию устанавливается значение session.gc_divisor, равное 1000, что означает, что механизм garbage collection будет запускаться с вероятностью 1/1000. Если вы поэкспериментируете с этими настройками в своем файле php.ini, то сможете заметить, что в описанном выше случае, когда браузер закрывается и очищает все свои куки, в каталоге сессий какое-то время все еще остаются старые сессии. Но это не должно вас волновать, т.к. как уже было сказано, это ни коим образом не влияет на безопасность нашего механизма.
Предотвращение зависания скриптов из-за блокировки файла сессии
В комментариях подняли вопрос о зависании одновременно выполняющихся скриптов из-за блокировки файла сессии (как самый яркий вариант — long poll).
Для начала отмечу, что эта проблема напрямую не зависит от загруженности сервера или количества пользователей. Конечно, чем больше запросов, тем медленнее выполняются скрипты. Но это коссвенная зависимость. Проблема появляется только в пределах одной сессии, когда серверу приходит несколько запросов от имени одного пользователя (например, один из них long poll, а остальные — обычные запросы). Каждый запрос пытается получить доступ к одному и тому же файлу сессии, и если предыдущий запрос не разблокировал файл, то последующий будет висеть в ожидании.
Для сведения блокировки файлов сессий к минимуму настоятельно рекомендуется закрывать сессию путем вызова функции session_write_close() сразу после того, как выполнены все действия с сессионными переменными. На практике это означает, что не следует хранить в сессионных переменных все подряд и обращаться к ним на всем протяжении выполнения скрипта. А если и надо хранить в сессионных переменных какие-то рабочие данные, то считывать их сразу при старте сессии, сохранять в локальные переменные для последующего использования и закрывать сессию (имеется ввиду закрытие сессии с помощью функции session_write_close, а не уничтожение с помощью session_destroy).
В нашем примере это означает, что сразу после открытия сессии, проверки времени ее жизни и существования авторизованного пользователя, мы должны считать и сохранить все дополнительные необходимые приложению сессионные переменные (если такие существуют), после чего закрыть сессию с помощью вызова session_write_close() и продолжить выполнение скрипта, будь то long poll или обычный запрос.
Защита сессий от несанкционированного использования
Представим себе ситуацию. Один из ваших пользователей цепляет троян, который грабит куки браузера (в котором хранится наша сессия) и отправляет его на указанный email. Злоумышленник получает куки и использует его для подделки запроса от имени нашего авторизованного пользователя. Сервер успешно принимает и обрабатывает этот запрос, как если бы он пришел от авторизованного пользователя. Если не реализована дополнительная проверка IP-адреса, такая атака приведет к успешному взлому аккаунта пользователя со всеми вытекающими последствиями.
Почему это стало возможным? Очевидно, потому что имя и идентификатор сессии всегда одни и те же на все время жизни сессии, и если получить эти данные, то можно беспрепятственно слать запросы от имени другого пользователя (естественно, в пределах времени жизни этой сессии). Возможно, это не самый распространенный вид атак, но теоретически все выглядит вполне реализуемым, особенно учитывая, что подобному трояну даже не нужны права администратора, чтобы грабить куки браузера пользователя.
Как же можно защититься от атак подобного рода? Опять-таки, очевидно, ограничив время жизни идентификатора сессии и периодически изменяя идентификатор в пределах одной сессии. Мы можем также изменять и имя сессии, полностью удаляя старую и создавая новую сессию, копируя в нее все сессионные переменные из старой. Но на суть подхода это не влияет, поэтому для простоты ограничимся только идентификатором сессии.
Понятно, что чем меньше время жизни идентификатора сессии, тем меньше будет времени у злоумышленника, чтобы получить и применить куки для подделки запроса пользователя. В идеальном случае для каждого запроса должен использоваться новый идентификатор, что позволит свести к минимуму возможность использования чужой сессии. Но мы рассмотрим общий случай, когда время регенерации идентификатора сессии устанавливается произвольно.
(Опустим ту часть кода, которая уже рассмотрена).
Итак, при создании новой сессии (которое происходит в момент успешного входа пользователя), мы устанавливаем сессионную переменную starttime, хранящую для нас время последней генерации идентификатора сессии, в значение, равное текущему времени сервера. Далее в каждом запросе мы проверяем, не прошло ли достаточно времени (idLifetime) с момента последней генерации идентификатора, и если прошло — генерируем новый. Таким образом, если в течение установленного времени жизни идентификатора злоумышленник, получивший куки авторизованного пользователя, не успеет им воспользоваться, поддельный запрос будет расценен сервером как неавторизованный, и злоумышленник попадет на страницу входа.
Примечание: Новый идентификатор сессии попадает в куки браузера при вызове функции session_regenerate_id(), которая отправляет новый куки, аналогично функции session_start(), поэтому нам нет необходимости обновлять куки самостоятельно.
Если мы хотим максимально обезопасить наши сессии, достаточно установить время жизни идентификатора в единицу или же вообще вынести функцию session_regenerate_id() за скобки и убрать все проверки, что приведет к регенерации идентификатора в каждом запросе. (Я не проверял влияние такого подхода на быстродействие, и могу только сказать, что функция session_regenerate_id(true) выполняет по сути всего 4 действия: генерация нового идентификатора, создание заголовка с куки сессии, удаление старого и создание нового файла сессии).
Лирическое отступление: Если троян окажется настолько умным, что не будет отправлять куки злоумышленнику, а сам организует отправку заранее подготовленного поддельного запроса сразу при получении куки, описанный выше метод, скорее всего, не сможет защитить от подобной атаки, потому что между временем получения трояном куки и отправкой поддельного запроса практически не будет разницы, и велика вероятность, что в этот момент не произойдет регенерации идентификатора сессии.
Возможность одновременной работы в одном браузере от имени нескольких пользователей
Последняя задача, которую хотелось бы рассмотреть — возможность одновременной работы в одном браузере нескольких пользователей. Эта возможность особенно полезна на этапе тестирования, когда нужно эмулировать одновременную работу пользователей, и желательно делать это в своем любимом браузере, а не использовать весь доступный арсенал или открывать несколько экземпляров браузера в режиме «инкогнито».
В наших предыдущих примерах мы не задавали явно имя сессии, поэтому использовалось имя, установленное в PHP по умолчанию (PHPSESSID). Это значит, что все сессии, которые создавались нами до сих пор, отправляли браузеру куки под именем PHPSESSID. Очевидно, что если имя куки всегда одинаковое, то нет возможности в пределах одного браузера организовать две сессии с одинаковым именем. Но если бы мы для каждого пользователя использовали собственное имя сессии, то проблема была бы решена. Так и сделаем.
Теперь осталось позаботиться о том, чтобы вызывающий скрипт передавал в функцию startSession() уникальный префикс для каждого пользователя. Это можно сделать, например, через передачу префикса в GET/POST параметрах каждого запроса или через дополнительный куки.
Заключение
В заключение приведу полный конечный код наших функций для работы с сессиями PHP, включающий все рассмотренные выше задачи.
Надеюсь, эта статья сэкономит немного времени тем, кто никогда особо не углублялся в механизм сессий, и даст достаточно понимания этого механизма тем, кто только начинает знакомиться с PHP.
