что такое сессия пользователя на сайте
Сессия
Сессия (от лат. – sessio — заседание, англ. – session) – это промежуток времени, охватывающий работу пользователя в интернете с момента открытия первой и до последней ссылок. Рассчитывается как разница во времени между начальным и финальным запросами. Однако последняя страница может просматриваться пользователем различное время, из чего, следовательно, измерение времени между двумя запросами становится более затруднительным.
Как связана сессия с протоколом HTTP и COOKIES
Что такое сессия можно объяснить, отталкиваясь от протокола HTTP. Сам по себе, этот протокол не располагает способом сохранения состояния между двумя операциями. Т.е., проще говоря, открывая одну страничку, а затем, перейдя с неё на другую, HTTP не сможет установить, что оба запроса принадлежат одному пользователю. И тут на помощь приходит особый метод отслеживания – управление сеансами (нашими сессиями).
Отсюда, отвечая на вопрос, что такое сессия, можно сказать, что это – вспомогательный логический объект, способствующий передачи данных между последовательными HTTP – запросами от одного юзера.
Cookies, как и сессия, хранят сведения о пользователе во время его перемещения по разным страницам и улучшают работу протокола. Но в отличие от второй, где данные хранятся во временных файлах на сервере, они сохраняют их на компьютере пользователя в виде небольших фрагментов.
Для чего нужны сессии
Использование сессий становится незаменимым при работе с такими сайтами, как форумы, доски объявлений и Интернет – магазины, ведь в этом случае нужно сохранять данные о юзере на протяжении нескольких страниц.
Этапы сессии
Всю сессию можно разделить на три этапа:
Советы при использовании сесии
Из-за того, что данные сессии сохраняются на стороннем сервере, то лучше всего не держать большие объемы информации в них, а использовать cookies.
Как использовать сессии и переменные сессий в PHP
Дата публикации: 2018-10-19
От автора: обработка сессии PHP является ключевой концепцией языка, которая позволяет сохранять информацию пользователя на всех страницах веб-сайта или приложения. В этом посте вы узнаете основы обработки сессий в PHP.
Мы начнем с пояснения того, как работают сессии и как они связаны с файлами куки. Затем мы рассмотрим несколько фрагментов кода, демонстрирующих, как работать с сессиями. Вы узнаете, как создавать и удалять сессии и как изменять переменные сессии.
Что такое сессия в PHP?
Сессия — это механизм для сохранения информации на разных веб-страницах для идентификации пользователей при навигации по сайту или приложению. Вам интересно, почему сессии необходимы для веб-сайта? Чтобы понять, для чего необходимы сессии, нам нужно рассмотреть, как работает протокол HTTP.
Протокол HTTP — это протокол без учета состояния, что означает, что сервер не может запоминать конкретного пользователя между несколькими запросами. Например, при доступе к веб-странице сервер отвечает за предоставление содержимого запрашиваемой страницы. Поэтому, когда вы обращаетесь к другим страницам одного и того же веб-сайта, веб-сервер интерпретирует каждый запрос отдельно, как если бы они не были связаны друг с другом. Серверу не известно, что каждый запрос исходит от одного и того же пользователя. Следующая диаграмма иллюстрирует протокол HTTP.
Бесплатный курс по PHP программированию
Освойте курс и узнайте, как создать динамичный сайт на PHP и MySQL с полного нуля, используя модель MVC
В курсе 39 уроков | 15 часов видео | исходники для каждого урока
В этой модели, если вы хотите отображать информацию пользователя, вам нужно будет аутентифицировать пользователя в каждом запросе. Представьте, что вам нужно было бы вводить имя пользователя и пароль на каждой странице, на которой была представлена ваша информация о профиле! Да, это было бы вообще не практичным, и именно здесь на сцену выходят сессии.
Сессия позволяет обмениваться информацией на разных страницах одного сайта или приложения, что помогает поддерживать состояние. Это позволяет серверу знать, что все запросы исходят от одного и того же пользователя, что дает возможность отображать информацию и настройки пользователя.
Поток авторизации с помощью сессий и файлов куки
Давайте кратко рассмотрим общий поток авторизации, чтобы понять, что происходит за кулисами.
Пользователь открывает страницу авторизации на сайте.
После отправки данных формы входа сервер на другом конце аутентифицирует запрос, проверив введенные учетные данные.
Если учетные данные, введенные пользователем, действительны, сервер создает новую сессию. Сервер генерирует уникальное случайное число, которое называется идентификатором сессии. Он также создает новый файл, который используется для хранения информации, относящейся к сессии.
Затем пользователю передается идентификатор сессии, а также любой запрошенный ресурс. За кулисами этот идентификатор сеанса отправляется в файле куки PHPSESSID в заголовке ответа.
Когда браузер получает ответ от сервера, он находит его в заголовке файла куки PHPSESSID. Если куки разрешены браузером, он сохранит этот файл PHPSESSID, в котором хранится идентификатор сессии, переданный сервером.
Таким образом, пользовательские данные сохраняются для нескольких запросов, и пользователь остается авторизованным на протяжении всей сессии. На следующей диаграмме показано, как протокол HTTP работает с сессиями.
Теперь, когда мы кратко рассмотрели сессии, мы возьмем несколько практических примеров, чтобы продемонстрировать, как создавать и изменять переменные сессии.
Как начать сессию
В этом разделе мы рассмотрим, как в PHP начать сессию. Каждый раз, когда вы хотите работать с переменными сессии, вам необходимо убедиться, что сессия уже запущена. Есть несколько способов начать сессию в PHP.
Использовать функцию session_start
Это метод, который вы встретите чаще всего, когда сессия запускается функцией session_start.
Аутентификация пользователя на сайте. Сессии и куки
Особенности работы протокола HTTP
Как вы узнали из прошлой главы, работа с веб-сайтами в интернете происходит по протоколу HTTP.
Это замечательный и простой протокол, который действует по схеме «запрос-ответ». То есть клиент (браузер) пользователя посылает на сервер запрос, состоящий, как правило, только из заголовков, а затем получает ответ в виде заголовков ответа и тела самого документа.
В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ».
Иными словами, сервер не «запоминает» клиентов; каждый запрос он обрабатывает с «чистого листа».
Для сервера нет никакой разницы: запросил один пользователь страницу десять раз или десять разных пользователей по разу. Для него все запросы одинаковые.
Чем это неудобно для нас?
Часто сайты должны уметь идентифицировать своих посетителей, чтобы сохранять и показывать им позже какую-либо информацию.
Например, интернет-магазины могут сохранять историю просмотров, чтобы рекомендовать потенциальным покупателям наиболее подходящие им товары. Или агрегатор новостей мог бы предложить пользователям выбирать только интересующие их рубрики.
К счастью, протокол HTTP, а также все браузеры предоставляют возможность сохранения информации о пользователе.
Cookies
Cookies (в дальнейшем просто «куки») — небольшие фрагменты данных, которые веб-сервер отправляет браузеру.
Браузер сохраняет их у себя, а при следующем посещении веб-страницы отправляет обратно. Благодаря этому, веб-сервер сможет узнать своего «старого» посетителя, идентифицировать его.
Пример
Задача очень проста: сохранять и показывать посетителю страницы, сколько раз он посетил наш сайт. Для этого будем сохранять количество посещений в отдельной куке, увеличивая значения на единицу при каждой загрузке страницы.
Как установить куки: функция setcookie
Являясь серверным языком программирования, PHP может управлять заголовками, которые отправляет сервер, а значит может устанавливать и читать куки.
Чтобы добавить новую куку, необходимо вначале определиться со следующими критериями:
Обратите внимание, что срок жизни указывается в относительной величине. В этом примере кука будет существовать ровно 30 дней с момента установки.
Как прочитать куки
Собираем всё вместе
Теперь, научившись устанавливать и читать куки, напишем полноценный сценарий, который будет считать и выводить количество посещений страницы пользователем:
Сессии
Мы уже умеем сохранять информацию для пользователя между посещениями страницы с помощью кук. Но зачем же нам ещё сессии, и для чего они нужны?
Сессии, они же сеансы, это, по сути, просто удобная обёртка над куками. Они также позволяют хранить данные, релевантные пользователю, но с некоторыми отличиями и ограничениями:
Как устроены сессии
Благодаря существованию сессий в PHP, мы можем сохранять любые данные так же просто, как присваивать их переменным. Но, в отличие от переменных, эти данные будут сохраняться для пользователя между запросами в пределах сеанса.
Перепишем сценарий для подсчета посещений, но теперь используем сессии:
Аутентификация
Представим интернет-магазин. Все его страницы можно разделить на две половины: публичные и приватные.
К публичным относятся страницы каталога, информации о товаре, условия доставки и так далее. К приватным — корзина покупок, история заказов.
Совершенно очевидно, что корзина покупок у каждого покупателя должна быть своя, а иметь к ней доступ должен только сам владелец и никто больше.
Процедура проверки возможности доступа пользователя к определенной части сайта и называется аутентификацией.
Весь процесс аутентификации всегда состоит из нескольких шагов:
Ещё немного терминологии
Следует различать два термина: аутентификация и авторизация.
Аутентификация — проверка подлинности предоставленного пользователем идентификатора (пара логин-пароль).
Авторизация — процесс проверки и предоставления прав пользователю на выполнение определённого действия.
В примере с интернет-магазином аутентификация выполняется, когда пользователь заполняет форму входа и попадает в свой личный кабинет. Сценарий, обрабатывающий форму, лишь проверяет, что такой пользователь существует, и его пароль совпадает.
Авторизация включается в работу, когда пользователь выполняет какое-нибудь действие. Например, удаляет товар из своей корзины. Во время этого действия сценарий должен проверить принадлежность товара к корзине этого пользователя. Без такой проверки пользователь мог бы удалить товар из чужой корзины.
Логика авторизации намного сложнее, чем простая проверка совпадения почты и пароля при входе на сайт. В авторизацию могут также входить следующие понятия: группы пользователей, виды действий, ресурсы, иерархия ролей и действий. Этой теме можно посвятить отдельную главу. Мы не рассматриваем авторизацию в рамках этого учебника, потому что эта тема выходит за рамки «базовой».
Регистрация на сайте
Перед тем, как мы начнем добавлять аутентификацию на своем сайте, придётся добавить форму для регистрации нового аккаунта.
Аккаунт — это учётная запись пользователя.
Чтобы завести аккаунт, требуется пройти регистрацию — это заполнение специальной формы, где пользователь указывает свою почту, пароль, и, возможно, дополнительную информацию.
После регистрации все данные из формы сохраняются в базе данных как есть. Но хранению паролей нужно уделить особое внимание.
Хранение паролей
Пароль пользователя — это секретный набор символов, который используется в дальнейшем в ходе аутентификации. Зная пароль пользователя, злоумышленник может войти на сайт под его именем. По этой причине пароль нельзя хранить в базе в открытом виде. Ведь если информацию из БД сайта украдут, то данные всех пользователей станут скомпрометированными.
Вместо самого пароля, в базе будут храниться их отпечатки — хэши.
Что такое хеширование
Отпечаток (хэш) — это результат работы функции хэширования, которая вернёт для любого значения строку фиксированной длины.
Используя специальный математический алгоритм, такая функция умеет преобразовывать любую переданную информацию к строке фиксированной длины (например, 32 или 64 символа). Причём любому массиву информации, будь это все статьи из Википедии, или одно слово, всегда будет соответствовать уникальный отпечаток. Повторный вызов функции для одного и того же исходника всегда возвращает один и тот же хэш.
Обратная операция (получить из отпечатка оригинал) невозможна.
Возьмём простой пример. У нас есть информация, для которой мы хотим получить отпечаток. Пусть такой информацией будет следующая строка:
Результат обработки этой строки хэширующей функцией SHA-1 будет таким:
6b3cb0df50fe814dee886b4e1c747dda6ce88b37
Хэширующие функции часто используются для контроля целостности информации при передачи по сети. Например, чтобы убедиться в том, что загруженный файл не был повреждён, достаточно получить его хэш и сравнить данный хэш с опубликованным на сайте. Если в файле поменялся хоть один байт, то эти отпечатки будут совершенно разными.
Нам же функции хэширования помогут для сравнения паролей.
Реализация регистрации пользователя
Вернёмся к форме регистрации.
Выше говорилось, что вместо пароля лучше хранить его отпечаток. Для получения отпечатка существуют множество хэшируюших функций. К счастью, нам не надо разбираться в их многообразии, потому что в PHP есть стандартная функция, которая делает ровно то, что нужно.
Вот пример как из пароля получить отпечаток, пригодный для хранения в базе:
Проверка пароля при входе на сайт
Использование сессии для контроля доступа
Сессии чаще всего используются для хранения информации о залогиненном пользователе. Принцип работы здесь очень простой: внутри сценария, ответственного за обработку формы входа, открывается новая сессия, куда записывается информация о вошедшем пользователе. Такой информацией может быть ассоциативный массив со всеми значениями из соответствующей записи из БД.
Затем добавим код, проверяющий существование сессии в сценарии, которые должны быть закрыты от анонимных пользователей. Если сессия пуста, значит данный пользователь не выполнял вход на сайт, и доступа к данной странице он не имеет.
В этом случае можно вернуть код ответа 403 и показать сообщение об ошибке, либо принудительно выполнить переадресацию на главную страницу.
Выход с сайта
HTTP сессия. Session. Состояние сеанса. Работа с сессиями в ASP.NET MVC
Давайте рассмотрим такое понятие как сессия (HTTP-сессия, Session). Или по-другому, сеанс пользователя. Почему важно понимать механизм работы сессий. И посмотрим, как можно работать с состояниями сеансов на платформе ASP.NET.
Прежде чем мы дадим определение термину «сессия», давайте немного рассмотрим предысторию, зачем вообще возникла потребность в сессиях, рассмотрим одну особенность протокола HTTP.
Одной из основных особенностей протокола HTTP является то, что он не обязывает сервер сохранять информацию о клиенте между запросами, то есть идентифицировать клиента. Это так называемый stateless-протокол. Связь между клиентом и сервером заканчивается как только завершается обработка текущего запроса. Каждый новый запрос к серверу подразумевается как абсолютно уникальный и независимый, даже если он был отправлен повторно от одного и того же источника.
Что, если оставить stateless-природу протокола HTTP и не идентифицировать пользователя? Без состояний сеанса можно легко обойтись, если на вашем сайте представлена статичная (обезличенная) информация, например, новостная статья, состоящая из текста и изображений. В таком контексте совершенно необязательно ассоциировать несколько запросов с одним пользователем. Ведь содержание статьи никак не изменится, будь то десять запросов с одного устройства, либо десять запросов от разных людей с разных устройств.
Но как только мы собираемся передать персональную информацию на сервер, нам необходимо каким-то образом сделать так, чтобы сервер ассоциировал все наши запросы именно с нами, и в будущем верно определял все исходящие от нас запросы. Если этого не сделать, то с каждым новым запросом мы будем вынуждены повторно передавать необходимые персональные данные. Например, логин для входа в личный кабинет на сайте, или такую информацию как имя, адрес доставки, при совершении покупки в интернет-магазине.
Вот как раз в таких ситуациях, когда требуется персонализировать запросы от одного клиента, мы будем использовать сессии.
Когда клиент впервые передает персональные данные в запросе, на сервере создается новая сессия для этого клиента. В период времени жизни сессии все запросы от этого клиента будут однозначно распознаны и связаны с ним. По истечении этого времени связь с клиентом будет потеряна, и очередной запрос от него будет обрабатываться как абсолютно уникальный, никак не связанный с предыдущими.
Например, при совершении покупки в онлайн магазине персональная информация пользователя сохраняется в сессии, пока он путешествует по сайту. Это выбранные товары в корзине, адрес доставки, контактные данные и так далее.
Теперь давайте посмотрим, как это мы можем реализовать технически. Вообще существует несколько техник управления сессиями клиента, их количество и способ реализации во многом зависит от веб-платформы или технологии, что работает на сервере. В этом уроке мы рассмотрим следующие:
Попробуем их реализовать, используя платформу ASP.NET. Давайте кратко рассмотрим первые два механизма, и особое внимание уделим третьему, как более надежному, удобному и безопасному.
Скрытые поля на HTML-форме (hidden form fields)
Суть данного подхода состоит в том, что мы обеспечиваем навигацию по сайту при помощи стандартных html-форм. И при каждом следующем запросе мы сохраняем данные из предыдущего в скрытых полях на форме. Например:
Давайте рассмотрим особенности такого подхода. Плюсов практически нет, разве что реализовать данную технику можно очень быстро. Но опять же и другие подходы тоже можно реализовать очень быстро. А вот минусы есть, и довольно существенные:
Куки (cookies)
В данном подходе мы не храним сессионные данные непосредственно на форме, вместо этого используется стандартный механизм работы cookies между клиентом и сервером. В cookies и хранятся все пользовательские данные.
При выборе этого подхода опять же главной остается проблема безопасности наших данных, которые мы передаем на сервер – их легко подменить или украсть, они лежат в открытом виде. Также, если в настройках приватности браузера клиента отключен прием куки с сайтов, то такой вариант ведения сессии вовсе не будет работать.
Серверный механизм управления сессией (Session, SessionState)
Разберем, как работает механизм сессии со стороны сервера и со стороны клиента.
При стандартных настройках работы состояния сеанса для отслеживания серии запросов от одного клиента используется т.н. сессионная куки (session cookie). Алгоритм следующий:
В этом участке кода мы записываем в состояние сеанса имя пользователя. Это имя мы забираем с html-формы, которую он нам отправил. Дополнительно через свойства мы узнаем, создана ли эта сессия только что, то есть в рамках текущего запроса (если да, то и значение свойства IsNewSession будет равняться true), и уникальный идентификатор сессии. Этот идентификатор после обработки запроса будет автоматически записан в сессионную куки (если еще нет) и отправлен в ответе клиенту.
В браузере клиента можно наблюдать соответствующую куки и идентификатор его сессии:
В процессе следующего запроса от этого клиента давайте прочитаем его ранее сохраненное имя из сессии. Также принудительно завершим сессию. Работа с этим клиентом закончена, например, все данные обработаны и товар отправлен.
Как видно, работать с сессиями очень просто и удобно. Большинство процессов, связанных с обработкой сессии, происходит автоматически в фоновом режиме. Естественно, разработчик может вмешаться на любой стадии обработки сессии и внести свои коррективы.
В конфигурации выше мы указали, что таймаут сессии будет 40 минут, сессионные данные пользователя будут храниться в оперативной памяти, будут использоваться сессионные куки, также поменяли стандартное название такой куки на собственное.
PHP для начинающих. Сессия
Начну с сессий — это один из самых важных компонентов, с которыми вам придется работать. Не понимая принципов его работы — наворотите делов. Так что во избежание проблем я постараюсь рассказать о всех возможных нюансах.
Но для начала, чтобы понять зачем нам сессия, обратимся к истокам — к HTTP протоколу.
HTTP Protocol
Изначально подразумевали, что по этому протоколу будет только HTML передаваться, отсель и название, а сейчас чего только не отправляют и =^.^= и（•_ㅅ_•）
Чтобы не ходить вокруг да около, давайте я вам приведу пример общения по HTTP протоколу.
Вот пример запроса, каким его отправляет ваш браузер, когда вы запрашиваете страницу http://example.com :
А вот пример ответа:
Это очень упрощенные примеры, но и тут можно увидеть из чего состоят HTTP запрос и ответ:
Т.е. если украсть cookie из вашего браузера, то можно будет зайти на вашу страничку в facebook от вашего имени? Не пугайтесь, так сделать нельзя, по крайней мере с facebook, и дальше я вам покажу один из возможных способов защиты от данного вида атаки на ваших пользователей.
Давайте теперь посмотрим как изменятся наши запрос-ответ, будь там авторизация:
Метод у нас изменился на POST, и в теле запроса у нас передаются логин и пароль. Если использовать метод GET, то строка запроса будет содержать логин и пароль, что не очень правильно с идеологической точки зрения, и имеет ряд побочных явлений в виде логирования (например, в том же access.log ) и кеширования паролей в открытом виде.
Как можно заметить, заголовки отправляемые браузером (Request Headers) и сервером (Response Headers) отличаются, хотя есть и общие и для запросов и для ответов (General Headers)
Сервер узнал нашего пользователя по присланным cookie, и дальше предоставит ему доступ к личной информации. Так, ну вроде с сессиями и HTTP разобрались, теперь можно вернутся к PHP и его особенностям.
PHP и сессия
Я надеюсь, у вас уже установлен PHP на компьютере, т.к. дальше я буду приводить примеры, и их надо будет запускать
Вот вам статейка на тему PHP is meant to die, или вот она же на русском языке, но лучше отложите её в закладки «на потом».
Перво-наперво необходимо «стартовать» сессию — для этого воспользуемся функцией session_start(), создайте файл session.start.php со следующим содержимым:
Запустите встроенный в PHP web-server в папке с вашим скриптом:
Запустите браузер, и откройте в нём Developer Tools (или что там у вас), далее перейдите на страницу http://127.0.0.1:8080/session.start.php — вы должны увидеть лишь пустую страницу, но не спешите закрывать — посмотрите на заголовки которые нам прислал сервер:
Там будет много чего, интересует нас только вот эта строчка в ответе сервера (почистите куки, если нет такой строчки, и обновите страницу):
Увидев сие, браузер сохранит у себя куку с именем `PHPSESSID`:
PHPSESSID — имя сессии по умолчанию, регулируется из конфига php.ini директивой session.name, при необходимости имя можно изменить в самом конфигурационном файле или с помощью функции session_name()
И теперь — обновляем страничку, и видим, что браузер отправляет эту куку на сервер, можете попробовать пару раз обновить страницу, результат будет идентичным:
Итого, что мы имеем — теория совпала с практикой, и это просто отлично.
Обновляем страничку и видим время сервера, обновляем ещё раз — и время обновилось. Давайте теперь сделаем так, чтобы установленное время не изменялось при каждом обновлении страницы:
Обновляем — время не меняется, то что нужно. Но при этом мы помним, PHP умирает, значит данную сессию он где-то хранит, и мы найдём это место…
Всё тайное становится явным
В вашей конфигурации путь к файлам может быть не указан, тогда файлы сессии будут хранится во временных файлах вашей системы — вызовите функцию sys_get_temp_dir() и узнайте где это потаённое место.
Так, идём по данному пути и находим ваш файл сессии (у меня это файл sess_dap83arr6r3b56e0q7t5i0qf91 ), откроем его в текстовом редакторе:
Как видим — вот оно наше время, вот в каком хитром формате хранится наша сессия, но мы можем внести правки, поменять время, или можем просто вписать любую строку, почему бы и нет:
Так, что мы ещё не пробовали? Правильно — украсть «печеньки», давайте запустим другой браузер и добавим в него теже самые cookie. Я вам для этого простенький javascript написал, скопируйте его в консоль браузера и запустите, только не забудьте идентификатор сессии поменять на свой:
Вот теперь у вас оба браузера смотрят на одну и туже сессию. Я выше упоминал, что расскажу о способах защиты, рассмотрим самый простой способ — привяжем сессию к браузеру, точнее к тому, как браузер представляется серверу — будем запоминать User-Agent и проверять его каждый раз:
Ключевое слово в предыдущем абзаце похоже, в реальных проектах cookies уже давно «бегают» по HTTPS протоколу, таким образом никто их не сможет украсть без физического доступа к вашему компьютеру или смартфону
Стоит упомянуть директиву session.cookie-httponly, благодаря ей сессионная кука будет недоступна из JavaScript’a. Кроме этого — если заглянуть в мануал функции setcookie(), то можно заметить, что последний параметр так же отвечает за HttpOnly. Помните об этом — эта настройка позволяет достаточно эффективно бороться с XSS атаками в практически всех браузерах.
По шагам
А теперь поясню по шагам алгоритм, как работает сессия в PHP, на примере следующего кода (настройки по умолчанию):
А есть ли жизнь без «печенек»?
PHP может работать с сессией даже если cookie в браузере отключены, но тогда все URL на сайте будут содержать параметр с идентификатором вашей сессии, и да — это ещё настроить надо, но оно вам надо? Мне не приходилось это использовать, но если очень хочется — я просто скажу где копать:
А если надо сессию в базе данных хранить?
Отдельно замечу, что не надо писать собственные обработчики сессий для redis и memcache — когда вы устанавливаете данные расширения, то вместе с ними идут и соответствующие обработчики, так что RTFM наше всё. Ну и да, обработчик нужно указывать до вызова session_start() 😉
Когда умирает сессия?
За время жизни сессии отвечает директива session.gc_maxlifetime. По умолчанию, данная директива равна 1440 секундам (24 минуты), понимать её следует так, что если к сессии не было обращении в течении заданного времени, то сессия будет считаться «протухшей» и будет ждать своей очереди на удаление.
Интересен другой вопрос, можете задать его матёрым разработчикам — когда PHP удаляет файлы просроченных сессий? Ответ есть в официальном руководстве, но не в явном виде — так что запоминайте:
Самая тривиальная ошибка
Ошибка у которой более полумиллиона результатов в выдаче Google:
Cannot send session cookie — headers already sent by
Cannot send session cache limiter — headers already sent
Для получения таковой, создайте файл session.error.php со следующим содержимым:
Во второй строке странная «магия» — это фокус с буфером вывода, я ещё расскажу о нём в одной из следующих статей, пока считайте это лишь строкой длинной в 4096 символов, в данном случае — это всё пробелы
Для проверки полученных знаний, я хочу, чтобы вы реализовали свой собственный механизм сессий и заставили приведенный код работать:
Блокировка
Ещё одна распространённая ошибка у новичков — это попытка прочитать файл сессии пока он заблокирован другим скриптом. Собственно, это не совсем ошибка, это недопонимание принципа блокировки 🙂
Но давайте ещё раз по шагам:
«Воткнутся» в данную ошибку очень легко, создайте два файла:
Есть пару вариантов, как избежать подобного явления — «топорный» и «продуманный».
«Топорный»
Использовать самописный обработчик сессий, в котором «забыть» реализовать блокировку 🙂
Чуть лучше вариант, это взять готовый и отключить блокировку (например у memcached есть такая опция — memcached.sess_locking) O_o
Потратить часы на дебаг кода в поисках редко всплывающей ошибки…
«Продуманный»
Куда как лучше — самому следить за блокировкой сессии, и снимать её, когда она не требуется:
— Если вы уверенны, что вам не потребуется вносить изменения в сессионные данные используйте опцию read_and_close при старте сессии:
Таким образом, блокировка будет снята сразу по прочтению данных сессии.
— Если вам таки нужно вносить изменения в сессию, то после внесения оных закрывайте сессию от записи:
В заключение
В этой статье вам дано семь заданий, при этом они касаются не только работы с сессиями, но так же познакомят вас с MySQL и с функциями работы со строками. Для усвоения этого материала — отдельной статьи не нужно, хватит и мануала по приведенным ссылкам — никто за вас его читать не будет. Дерзайте!