В РНР доступно 2 правильных способов для узнавания пользователя.
1) Модификация адресной строки.
2) Куки
Они основаны на передаче данных от пользователя.
При первом способе добавляется переменная в строку запроса – index.php?id=1
Второй Куки (Cookie).
То есть, мы записываем значение id=1 в куки и оно каждый раз при запросе с данного диапазона возвращается серверу.
Модификацию адресной строки отметаем сразу же. Остаются куки. У них как минимум 2 недостатка: они доступны для пользователя, они не защищают неРНР контент (его обсуждать не будем).
То, что кука доступна пользователю обозначает, что он может её модифицировать, от этого можно защититься с помощью криптографических функций mcrypt*. Вторая неприятность трафик, который приходится гонять в сторону сервера.
Так как для идентификации пользователя нам достаточно только уникального ключа, логично передавать только его, а на основании значения на сервере восстанавливать данные. Разработчики РНР продумали это и получились сессии.
Для работы с сессиями достаточно вызвать session_start() до вывода чего-либо в браузер, после этого становится доступен суперглобальный массив $_SESSION, в котором и хранится информация.
Важно. Идентификатор сессии может передаваться через get, post и cookie. Get и post данные являются легко изменяемыми, например пользователю подсунули ссылку с идентификатором или заставили залогиниться через поддельную форму с другого сайта, после чего злоумышленнику доступен идентификатор сессии.
Для получения идентификатора из куки в ини файле.
session.use_trans_sid = 0 – в целях безопасность отключаем.
session.use_cookies = 1 – разрешаем использовать куки.
session.use_only_cookies = 1 – используем только куки, опция отключена по умолчанию.
Теперь немного о процессе, который происходит внутри.
Сервер получает идентификатор, если он есть, имя которого можно получить-изменить с помощью session_name(), по умолчанию (session.name = PHPSESSID). Механизм сессий весьма гибок и позволяет менять обработчик сессии, для этого существует session_set_save_handler(). При вызове session_start() вызывается этот обработчик (session.save_handler = files). Если пришёл идентификатор, то восстанавливается старая сессия, если его нет, стартует новая, для этого посылается заголовок для установки куки. Данные по умолчанию хранятся в файле, который находится в директории session_save_path() и имеет имя sess_ИДЕНТИФИКАТОР. Так как он хранится в плоском файле, для записи-чтения его нужно сериализировать-десериализировать, опять же для гибкости можно менять обработчик (session.serialize_handler = php), этот процесс проходит в начале работы с сессией и по завершению работы скрипта, даже если он завершился по таймауту. При вызове session_start() вызывается open, затем read, который возвращает результат в суперглобальную переменную $_SESSION. При окончании работы скрипта или при вызове session_write_close(), данные сериализируются и записываются. Метод close вызывается в конце работы. Метод destroy, нужен для уничтожения сессии. Стоит отметить gc, который нужен для уборки мусора он вызывается с частотой session.gc_probability/session.gc_divisor.
На этом первая часть заканчивается, и переходим непосредственно к практической стороне дела.
1) Модификация адресной строки.
2) Куки
Они основаны на передаче данных от пользователя.
При первом способе добавляется переменная в строку запроса – index.php?id=1
Второй Куки (Cookie).
При отправке HTTP-объекта клиенту сервер также может отправить блок информации о состоянии соединения, который будет храниться у клиента. В состав блока включается описании диапазона URL-адресов, для которых это состоянии достоверно. Все последующие HTTP-запросы, сделанные клиентом и попадающие в этот диапазон, будут включать в себя пересылку текущего значения данного объекта состояния от клиента обратно серверу. Объект состояния называется cookie (печенюшки) по причинам. Которые не обсуждаются.
То есть, мы записываем значение id=1 в куки и оно каждый раз при запросе с данного диапазона возвращается серверу.
Модификацию адресной строки отметаем сразу же. Остаются куки. У них как минимум 2 недостатка: они доступны для пользователя, они не защищают неРНР контент (его обсуждать не будем).
То, что кука доступна пользователю обозначает, что он может её модифицировать, от этого можно защититься с помощью криптографических функций mcrypt*. Вторая неприятность трафик, который приходится гонять в сторону сервера.
Так как для идентификации пользователя нам достаточно только уникального ключа, логично передавать только его, а на основании значения на сервере восстанавливать данные. Разработчики РНР продумали это и получились сессии.
Для работы с сессиями достаточно вызвать session_start() до вывода чего-либо в браузер, после этого становится доступен суперглобальный массив $_SESSION, в котором и хранится информация.
Важно. Идентификатор сессии может передаваться через get, post и cookie. Get и post данные являются легко изменяемыми, например пользователю подсунули ссылку с идентификатором или заставили залогиниться через поддельную форму с другого сайта, после чего злоумышленнику доступен идентификатор сессии.
Для получения идентификатора из куки в ини файле.
session.use_trans_sid = 0 – в целях безопасность отключаем.
session.use_cookies = 1 – разрешаем использовать куки.
session.use_only_cookies = 1 – используем только куки, опция отключена по умолчанию.
Теперь немного о процессе, который происходит внутри.
Сервер получает идентификатор, если он есть, имя которого можно получить-изменить с помощью session_name(), по умолчанию (session.name = PHPSESSID). Механизм сессий весьма гибок и позволяет менять обработчик сессии, для этого существует session_set_save_handler(). При вызове session_start() вызывается этот обработчик (session.save_handler = files). Если пришёл идентификатор, то восстанавливается старая сессия, если его нет, стартует новая, для этого посылается заголовок для установки куки. Данные по умолчанию хранятся в файле, который находится в директории session_save_path() и имеет имя sess_ИДЕНТИФИКАТОР. Так как он хранится в плоском файле, для записи-чтения его нужно сериализировать-десериализировать, опять же для гибкости можно менять обработчик (session.serialize_handler = php), этот процесс проходит в начале работы с сессией и по завершению работы скрипта, даже если он завершился по таймауту. При вызове session_start() вызывается open, затем read, который возвращает результат в суперглобальную переменную $_SESSION. При окончании работы скрипта или при вызове session_write_close(), данные сериализируются и записываются. Метод close вызывается в конце работы. Метод destroy, нужен для уничтожения сессии. Стоит отметить gc, который нужен для уборки мусора он вызывается с частотой session.gc_probability/session.gc_divisor.
На этом первая часть заканчивается, и переходим непосредственно к практической стороне дела.
