что такое пользовательская сессия
HTTP сессия
Так как HTTP — это клиент-серверный протокол, HTTP сессия состоит из трёх фаз:
Начиная с версии HTTP/1.1, после третьей фазы соединение не закрывается, так как клиенту позволяется инициировать другой запрос. То есть, вторая и третья фазы могут повторяться.
Установка соединения
Так как HTTP это клиент-серверный протокол, соединение всегда устанавливается клиентом. Открыть соединение в HTTP — значит установить соединение через соответствующий транспорт, обычно TCP.
В случае с TCP, в качестве порта HTTP сервера по умолчанию на компьютере используется порт 80, хотя другие также часто используются, например 8000 или 8080. URL загружаемой страницы содержит доменное имя и порт, который можно и не указывать если он соответствует порту по умолчанию.
Отправка запроса клиента
Когда соединение установлено user-agent может послать запрос. (user-agent это обычно веб браузер, но может им не быть) Клиентский запрос это текстовые директивы, разделённые между собой при помощи CRLF (переноса строки). Сам запрос включает в себя три блока:
Примеры запросов
Получаем главную страницу developer.mozilla.org, http://developer.mozilla.org/, и говорим серверу, что user-agent предпочитает страницу на французском, если это возможно:
Обращаем внимание на пустую строку в конце, которая отделяет блок данных от блока заголовков. Так как в запросе отсутствует Content-Length: HTTP заголовок, блок с данными пуст и сервер может начать обработку запроса, как только получит пустую строку, означающую конец заголовков.
Отправляем результат сабмита формы:
Методы запроса
HTTP определяет набор методов запроса с указанием желаемого действие на ресурсе. Хотя они также могут быть и существительными, эти запросы методы иногда называют HTTP-командами. Наиболее распространённые запросы GET и POST :
Структура ответа от сервера
После того как присоединённый агент отправил свой запрос, веб сервер обрабатывает его и отправляет ответ. По аналогии с клиентским запросом, ответ сервера — это текстовые директивы разделённые между собой CRLF, сгруппированные в три разных блока:
Примеры ответов
Успешное получение веб страницы:
Сообщение о том, что запрашиваемый ресурс был перемещён:
Сообщение о том, что запрашиваемый ресурс не существует:
Коды статусов ответа
HTTP-коды ответов показывают, выполнен ли успешно определённый HTTP-запрос. Ответы сгруппированы в пять классов: информационные ответы, успешные ответы, редиректы, ошибки клиента и ошибки сервера.
Сессии — всегда ли они нужны?
Хочу еще раз поднять тему использования сессий для аутентификации пользователей. Надеюсь услышать критику приведенного в статье метода с высоты вашего опыта.
Свой session_set_save_handler. Поскольку хранить переменные сессии в фаловой системе — решение далеко не оптимальное,
рано или поздно приходится задумываться о переносе сессий в memcached, базу, или еще куда.
session.use_trans_sid = 0. Встроенный в PHP механизм url_rewriter — необычайно мощная и полезная штука, но при
использовании ее в сессиях возникает серия неприятных моментов. «Взбесившиеся» поисковики, некрасивые ссылки,
заход под чужим именем, «засвет» своего sessid в логах совершенно посторонних сайтов (через HTTP_REFERER) и т.д.
Посему обычно эту функцию отключают, и для передачи sessid используют исключительно куки.
На последнем пункте я хочу остановиться подробнее. Дело в том, что большинство крупных сайтов
(google, ozon, livejournal, paypal..) работают только через куки. Мне это показалось очень странным,
поскольку непохоже, чтобы люди без кук в интернете встречаются аж настолько редко, чтобы ими можно было пренебречь.
Статистика liveinternet показывает, что число людей с отключенными куками держится в районе 4%.
Не так уж и мало. Вряд ли такие гиганты сознательно отсекали бы эту часть аудитории, по крайней мере
на то должны были быть очень веские основания. И они нашлись.
Оказывается, эти 4% включают тех людей, у которых не работают постоянные куки
(с жестко заданным lifetime), но работают сессионные — с lifetime=0. А сессионные куки работают практически у всех,
даже у тех, кто в настройках безопасности поставил «запретить куки», и даже в lynx. 🙂
Понятно, что 100% гарантии все равно дать нельзя. Например, куки может резать фаервол (хотя опять не известно,
будет ли он резать с lifetime=0). У пользователя может быть самописный броузер без поддержки кук
(например, crawler на перле). Да мало ли чего еще…
Но судя по своему опыту, (а опыт «старших товарищей» это косвенно подтверждает), скажу, что на практике можно
смело рассчитывать, что сессионные куки у пользователя таки да, есть. И также в пользу этого тезиса говорит и то,
что по умолчанию в PHP параметр session.use_only_cookies установлен в 1, т.е. у людей без кук сессии не работают.
А раз мы можем рассчитывать на поддержку кук, то в большинстве мест, где обычно используются сессии, на практике мы можем через куки все сделать проще и удобнее, и при этом работать это будет во всех тех же случаях,
что и сессии. Почему я говорю проще? Потому что куку кинул — и забыл, ее не надо прописывать вручную при
header(Location. ), о ней не надо помнить при работе с аяксом, она присутствует в запросе не зависимо от того,
относится ли этот запрос к скрипту, статической html, картинке или css. О сессиях же забыть получится только в случае,
если они работают через те же куки, да и то не всегда. 🙂
Теперь пара слов о собственном session_set_save_handler. Конечно, тут все зависит от того, какие данные и как долго нам
нужно хранить. Для общего случая, конечно, нужно использовать базу или файловую систему. Если время жизни сессии невелико,
а сами данные в сессии легко восстановимы, то вполне сгодится и память (или memcached). А если сессия используется только для
аутентификации пользователя, то стоит задуматься, нужно ли вообще в принципе хранить что-то на стороне сервера.
Ведь при использовании кук мы можем полностью отказаться от save_handler, и хранить все данные у клиента.
Опять же, беглое изучение кук, оставляемых phpbb, wordpress, gmail и др. показало, что такой подход вполне часто
используется и вполне имеет право на жизнь. Единственное, о чем стоит помнить, это что куки легко могут быть подделаны,
а значит слепо доверять им ни в коем случае нельзя.
И тут мы подходим к пункту 1 — Session Fixation. Как и при использовании стандартного механизма сессий, свою
куку мы также должны привязывать к какой-то информации, идентифицирующей пользователя, чтобы исключить возможность передачи
ее другому. Кроме того, мы должны защитить куку от возможных изменений самим пользователем.
Как и в случае с сессиями, можно это сделать путем сохранения на сервере и последующей сверкой
нужной информации (тех же IP и UserAgent).
Но мы же решили на сервере ничего не хранить. Посмотрим, можно ли это сделать без использования памяти сервера.
Рассмотрим распространенный случай авторизации: при вводе правильного логина и пароля мы сохраняем у пользователя в куке
его уникальный идентификатор (ID), и потом при каждом обращении к серверу опознаем пользователя по этому идентификатору
и считаем залогиненым. Если идентификатора нет, или время истекло — мы опять спрашиваем у пользователя логин и пароль.
Пользователь может украсть куку у другого пользователя и выдать себя за него.
Не понятно, как определить, что время вышло. Мы на сервере не храним никакого таймаута, посему не знаем, зашел ли
к нам пользователь вчера или он уже два месяца приходит с одной и той же кукой. Мы не помним, когда он к нам логинился
конкретно с этого компьютера.
Для того, чтобы пользователь не мог изменить данные в куке, мы можем использовать цифровую подпись. Например, md5
от какого-то секретного слова и id пользователя. Или от пароля этого пользователя. Или от хеша пароля, если сам пароль мы
в базе не храним. Короче, нам нужна такая информация, которую пользователь знает только о себе, но не знает о других
пользователях, за которых он себя хочет выдать. Или же не знает вообще (секретное слово).
Таким образом, кука, которую мы ставим, будет иметь вид:
Для того, чтобы пользователь не мог прислать куку другого пользователя, мы в той же цифровой подписи используем IP и
UserAgent.
При получении куки мы проверяем подпись, используя те UserAgent и IP, с которыми эта кука к нам пришла.
Если в подписи куки использовались не те значения, что пришли сейчас — подпись окажется не верна, и куку мы не примем.
И наконец, время действия. Проще всего вообще на это забить: пока юзер присылает нам правильную куку c правильного
IP и UserAgent — мы его пускаем. Но если мы все-таки хотим насильно ограничить время действия сессии, мы можем дописать
крайний срок в саму куку. И тоже подписать.
Что мы имеем в итоге: вполне надежный механизм аутентификации пользователей на сайте, создающий минимальную нагрузку
на сервер.
Чего мы не имеем: мы не можем хранить много сессионных данных. Размер куки ограничен, md5 на длинных строках жрет
процессорное время, да и негоже пользователю каждый раз качать туда-сюда весь этот мусор.
Максимальную длину, наверное, стоит сделать как у gmail — порядка 120 байт. Хотя чего там можно столько хранить в сессии
— я не знаю. В любом случае, если надо хранить много переменных — то имхо стоит все же использовать стандартные
PHP sessions, которые разработаны для общего случая и вполне могут использоваться и в нашем, пусть и с меньшей
производительностью.
Еще мы не знаем, сколько сессий у нас в данный момент открыто. Их можно открывать неограничено много.
В принципе, ничто не мешает нам вести такой учет, но мы же сами хотели разгрузить сервер…
Чем это лучше, чем использовать стандартные сессии, но со своим save_handler и session_fixation? Тем, что тут все происходит на виду и в любое место можно вмешаться. Простота кода. Ну и скорость — в обмен на универсальность.
Что такое сессия на сайте: описание термина, использование, различия у «Яндекса» и Google
Сессия на сайте — это временной интервал, в течение которого происходит взаимодействие пользователя с сайтом. Отсчет сессии стартует сразу после перехода на сайт.
Понять смысл сессии на сайте очень просто на следующем примере:
Сценарии сессии на сайте
Сессия как событие в «Яндекс.Метрике» и Google Analytics используется для определения поведения посетителей сайта. С сессией непосредственно связаны следующие метрики:
Кроме веб-аналитики, сессия как событие применима в следующих сценариях:
Мы будем рассматривать сессию применительно к сайту и веб-аналитике. В этом контексте сессия используется для обозначения последовательности запросов, которые совершает пользователь.
Клиент и сервер. Как происходит идентификация запроса
Сессия как отдельное событие обозначает серию запросов, которые отправляются от клиента, когда он взаимодействует с каким-либо хостом / сервером. В качестве клиента может быть не только браузер, но и поисковый робот, веб-приложение и т. д. В роли хоста (или сервера) чаще всего выступает определенный сайт.
Под определение сессии могут попадать вообще все запросы, которые сделал клиент на протяжении заданного периода: час, день, неделя и более длительные.
Сервер может различать каждый запрос, который поступает от клиента. Самый популярный вариант идентификации запроса — cookies-файл, но он не единственный. Распространена идентификация запросов клиента через параметры запроса, MAC-адрес, при помощи расширенных HTTP-заголовков.
Как создается сессия на сайте и как заканчивается
Скриптовый язык PHP позволяет управлять сессией при помощи функции session_start() — это начало сессии — и завершать ее функцией session_destroy().
Механизм сессии строится следующим образом:
В качестве события завершения сессии могут выступать:
Клиент и сервер могут сохранять уникальный идентификатор сессии в течение очень длительного времени: неделями, месяцами и даже целый год.
Сессия в системах аналитики «Яндекс» и Google
В «Яндекс.Метрике» термины «сессия» и «визит» можно считать взаимозаменяемыми.
Под последовательностью действий понимается любая пользовательская активность: регистрация события (например, hit или notBounce), переход по URL, просмотр страницы. Для изучения поведения пользователя в рамках визита можно использовать «Вебвизор» «Яндекс.Метрики»:
Визит в «Яндекс.Метрике» считается оконченным в следующих сценариях:
Google Analytics для определения сессии применяет термин веб-сеанс. Google Analytics трактует сеанс как время, которое пользователь уделил сайту или приложению.
Сеанс в Google Analytics можно схематично представить в виде последовательности действий посетителя:
Сеанс по умолчанию завершается только в трех случаях:
Есть ли разница между сессией и сеансом
То, о чем сейчас пойдет речь, актуально для любой системы веб-аналитики. Сеанс и сессия не являются тождественными понятиями.
Сеанс относится к взаимодействию посетителя с сайтом. Пользовательский сеанс условно состоит из четырех частей:
Сессией же корректнее считать последовательность запросов, которые поступают от единого клиента и которые может идентифицировать сервер.
Браузерное уведомление «Время сессии истекло»: почему оно появляется
Часто в браузере появляется сообщение «Время сессии истекло». Оно может появляться при разных сценариях, но все они сводятся к одному: продолжительное бездействие на странице.
Стандартное время окончания сессии в языке PHР по умолчанию составляет ровно 24 минуты.
Если страница загружается дольше, появляется эта ошибка.
Заключение
Сегодня мы узнали, что сессия — это не только временной интервал. Это также последовательность запросов или вообще все запросы, которые совершил пользователь после перехода по ссылке. Кроме этого, важно понимать разницу между сессией и сеансом.
Вообще сессия применительно к сайту — больше многозначный термин, чем четко определенный. Но чаще всего его используют, именно когда речь заходит об отчетах веб-аналитики. Правильно понимая сессию как событие, вы можете изучать отчеты веб-аналитики с большей эффективностью.
Аутентификация пользователя на сайте. Сессии и куки
Особенности работы протокола HTTP
Как вы узнали из прошлой главы, работа с веб-сайтами в интернете происходит по протоколу HTTP.
Это замечательный и простой протокол, который действует по схеме «запрос-ответ». То есть клиент (браузер) пользователя посылает на сервер запрос, состоящий, как правило, только из заголовков, а затем получает ответ в виде заголовков ответа и тела самого документа.
В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ».
Иными словами, сервер не «запоминает» клиентов; каждый запрос он обрабатывает с «чистого листа».
Для сервера нет никакой разницы: запросил один пользователь страницу десять раз или десять разных пользователей по разу. Для него все запросы одинаковые.
Чем это неудобно для нас?
Часто сайты должны уметь идентифицировать своих посетителей, чтобы сохранять и показывать им позже какую-либо информацию.
Например, интернет-магазины могут сохранять историю просмотров, чтобы рекомендовать потенциальным покупателям наиболее подходящие им товары. Или агрегатор новостей мог бы предложить пользователям выбирать только интересующие их рубрики.
К счастью, протокол HTTP, а также все браузеры предоставляют возможность сохранения информации о пользователе.
Cookies
Cookies (в дальнейшем просто «куки») — небольшие фрагменты данных, которые веб-сервер отправляет браузеру.
Браузер сохраняет их у себя, а при следующем посещении веб-страницы отправляет обратно. Благодаря этому, веб-сервер сможет узнать своего «старого» посетителя, идентифицировать его.
Пример
Задача очень проста: сохранять и показывать посетителю страницы, сколько раз он посетил наш сайт. Для этого будем сохранять количество посещений в отдельной куке, увеличивая значения на единицу при каждой загрузке страницы.
Как установить куки: функция setcookie
Являясь серверным языком программирования, PHP может управлять заголовками, которые отправляет сервер, а значит может устанавливать и читать куки.
Чтобы добавить новую куку, необходимо вначале определиться со следующими критериями:
Обратите внимание, что срок жизни указывается в относительной величине. В этом примере кука будет существовать ровно 30 дней с момента установки.
Как прочитать куки
Собираем всё вместе
Теперь, научившись устанавливать и читать куки, напишем полноценный сценарий, который будет считать и выводить количество посещений страницы пользователем:
Сессии
Мы уже умеем сохранять информацию для пользователя между посещениями страницы с помощью кук. Но зачем же нам ещё сессии, и для чего они нужны?
Сессии, они же сеансы, это, по сути, просто удобная обёртка над куками. Они также позволяют хранить данные, релевантные пользователю, но с некоторыми отличиями и ограничениями:
Как устроены сессии
Благодаря существованию сессий в PHP, мы можем сохранять любые данные так же просто, как присваивать их переменным. Но, в отличие от переменных, эти данные будут сохраняться для пользователя между запросами в пределах сеанса.
Перепишем сценарий для подсчета посещений, но теперь используем сессии:
Аутентификация
Представим интернет-магазин. Все его страницы можно разделить на две половины: публичные и приватные.
К публичным относятся страницы каталога, информации о товаре, условия доставки и так далее. К приватным — корзина покупок, история заказов.
Совершенно очевидно, что корзина покупок у каждого покупателя должна быть своя, а иметь к ней доступ должен только сам владелец и никто больше.
Процедура проверки возможности доступа пользователя к определенной части сайта и называется аутентификацией.
Весь процесс аутентификации всегда состоит из нескольких шагов:
Ещё немного терминологии
Следует различать два термина: аутентификация и авторизация.
Аутентификация — проверка подлинности предоставленного пользователем идентификатора (пара логин-пароль).
Авторизация — процесс проверки и предоставления прав пользователю на выполнение определённого действия.
В примере с интернет-магазином аутентификация выполняется, когда пользователь заполняет форму входа и попадает в свой личный кабинет. Сценарий, обрабатывающий форму, лишь проверяет, что такой пользователь существует, и его пароль совпадает.
Авторизация включается в работу, когда пользователь выполняет какое-нибудь действие. Например, удаляет товар из своей корзины. Во время этого действия сценарий должен проверить принадлежность товара к корзине этого пользователя. Без такой проверки пользователь мог бы удалить товар из чужой корзины.
Логика авторизации намного сложнее, чем простая проверка совпадения почты и пароля при входе на сайт. В авторизацию могут также входить следующие понятия: группы пользователей, виды действий, ресурсы, иерархия ролей и действий. Этой теме можно посвятить отдельную главу. Мы не рассматриваем авторизацию в рамках этого учебника, потому что эта тема выходит за рамки «базовой».
Регистрация на сайте
Перед тем, как мы начнем добавлять аутентификацию на своем сайте, придётся добавить форму для регистрации нового аккаунта.
Аккаунт — это учётная запись пользователя.
Чтобы завести аккаунт, требуется пройти регистрацию — это заполнение специальной формы, где пользователь указывает свою почту, пароль, и, возможно, дополнительную информацию.
После регистрации все данные из формы сохраняются в базе данных как есть. Но хранению паролей нужно уделить особое внимание.
Хранение паролей
Пароль пользователя — это секретный набор символов, который используется в дальнейшем в ходе аутентификации. Зная пароль пользователя, злоумышленник может войти на сайт под его именем. По этой причине пароль нельзя хранить в базе в открытом виде. Ведь если информацию из БД сайта украдут, то данные всех пользователей станут скомпрометированными.
Вместо самого пароля, в базе будут храниться их отпечатки — хэши.
Что такое хеширование
Отпечаток (хэш) — это результат работы функции хэширования, которая вернёт для любого значения строку фиксированной длины.
Используя специальный математический алгоритм, такая функция умеет преобразовывать любую переданную информацию к строке фиксированной длины (например, 32 или 64 символа). Причём любому массиву информации, будь это все статьи из Википедии, или одно слово, всегда будет соответствовать уникальный отпечаток. Повторный вызов функции для одного и того же исходника всегда возвращает один и тот же хэш.
Обратная операция (получить из отпечатка оригинал) невозможна.
Возьмём простой пример. У нас есть информация, для которой мы хотим получить отпечаток. Пусть такой информацией будет следующая строка:
Результат обработки этой строки хэширующей функцией SHA-1 будет таким:
6b3cb0df50fe814dee886b4e1c747dda6ce88b37
Хэширующие функции часто используются для контроля целостности информации при передачи по сети. Например, чтобы убедиться в том, что загруженный файл не был повреждён, достаточно получить его хэш и сравнить данный хэш с опубликованным на сайте. Если в файле поменялся хоть один байт, то эти отпечатки будут совершенно разными.
Нам же функции хэширования помогут для сравнения паролей.
Реализация регистрации пользователя
Вернёмся к форме регистрации.
Выше говорилось, что вместо пароля лучше хранить его отпечаток. Для получения отпечатка существуют множество хэшируюших функций. К счастью, нам не надо разбираться в их многообразии, потому что в PHP есть стандартная функция, которая делает ровно то, что нужно.
Вот пример как из пароля получить отпечаток, пригодный для хранения в базе:
Проверка пароля при входе на сайт
Использование сессии для контроля доступа
Сессии чаще всего используются для хранения информации о залогиненном пользователе. Принцип работы здесь очень простой: внутри сценария, ответственного за обработку формы входа, открывается новая сессия, куда записывается информация о вошедшем пользователе. Такой информацией может быть ассоциативный массив со всеми значениями из соответствующей записи из БД.
Затем добавим код, проверяющий существование сессии в сценарии, которые должны быть закрыты от анонимных пользователей. Если сессия пуста, значит данный пользователь не выполнял вход на сайт, и доступа к данной странице он не имеет.
В этом случае можно вернуть код ответа 403 и показать сообщение об ошибке, либо принудительно выполнить переадресацию на главную страницу.
Выход с сайта
Сессии. Подробное описание работы и объяснение механизма.
Подробно расписывать нужду в таком механизме я не буду. Это такие хрестоматийнык случаи, как корзина покупок в е-магазине, авторизация, а так же, и не совсем тривиальные проблемы, такие, например, как защита интерактивных частей сайта от спама.
В принципе, довольно несложно сделать собственный аналог сессий, не такой функциональный, как встроенный в PHP, но похожий по сути. На куках и базе данных.
При запросе скрипта смотрим, пришла ли кука с определенным именем. Если куки нет, то ставим ее и записываем в базу новую строку с данными пользователя. Если кука есть, то читаем из базы данные. Еще одним запросом удаляем из базы старые записи и вот у нас готов механизм сессий. Совсем несложно. Но есть некоторые нюансы, которые делают предпочтительным использование именно встроенного механизма сессий.
Если включена только первая, то при старте сессии (при каждом вызове session_start() ) клиенту устанавливается кука. Браузер исправно при каждом следующем запросе эту куку возвращает и PHP имеет идентификатор сессии. Проблемы начинаются, если браузер куки не возвращает. В этом случае, не получая куки с идентификатором, PHP будет все время стартовать новую сессию, и механизм работать не будет.
По умолчанию в последних версиях PHP включены обе опции. Как PHP поступает в этом случае? Кука выставляется всегда. А ссылки автодополняются только если РНР не обнаружил куку с идентификатором сессии. Когда пользователь в првый раз за этот сеанс заходит на сайт, ему ставится кука, и дополняются ссылки. При следующем запросе, если куки поддерживаются, PHP видит куку и перестает дополнять ссылки. Если куки не работают, то PHP продолжает исправно добавлять ид к ссылкам, и сессия не теряется.
Пользователи, у которых работают куки, увидят длинную ссылку с ид только один раз.
Следует помнить, что пхп лочит файл сессии. То есть, если один ваш скрипт стартует сессию и долго выполняется, а другой пытается в это время стартовать её с тем же идентификатором, то он зависнет. Поэтому в долго выполняющихся скриптах следует стартовать сессию только тогда, когда она нужна, и тут же закрывать её, с помощью session_write_close()