И снова приветствую Вас, уважаемые читатели моего блога!
Немного подумал и решил сегодня написать статейку по программированию, а точнее про сесии и куки. Усаживайтесь поудобнее — начинаем!
Важнейшей особенностью веб-программирования является возможность беспрепятственно передавать данные от одной страницы другой. Чаще всего используется при работе с регистрацией, формами входа а также предания сообщений об ошибках и т.д.
Разница между куки и сессиями то как они хранят данные. Куки хранятся локально на компьютере пользователя тогда как сессии хранятся на сервере у вас.
Сессии
Сессии хранят временные данные о пользователях, и они особенно полезны, если вы не хотите, чтобы были доступны за пределами сервера. Это альтернатива использованию cookie, если пользователь отключил cookie на своем компьютере, поскольку PHP может автоматически переписать URL так, чтобы передать идентификатор сессии.
Cookie в действии
Cookie создаются вызовом функции setcookie(), сервер добавляет соответствующую строку в заголовок. Если вы попытаетесь послать cookie после того, как начнете посылать HTML, PHP отметит наличие серьезных ошибок, а cookie не будет размещен. Функция setcookie() принимает три основных параметра имя cookie, значение и дату окончания срока действия. Например:
Установка cookie без значения все равно что его удаление. Это не удалит файл с машины пользователя. Чтобы удалить файл вам нужно поставить значение cookie в прошлом времени и браузер удалит файл.
Сессии в действии
Получилась хоть и не большая, но познавательная статья.
Если есть вопросы или предложения — задавайте на этой странице. Обещаю, отвечу всем.
Также подписывайтесь на обновление новостей блога!
На этом буду прощаться с Вами — до новых встреч!
Куки HTTP
Cookie используются, главным образом, для:
⦁ Управления сеансом (логины, корзины для виртуальных покупок)
⦁ Персонализации (пользовательские предпочтения)
⦁ Мониторинга (отслеживания поведения пользователя)
До недавнего времени cookie принято было использовать в качестве хранилища информации на стороне пользователя. Это могло иметь смысл в отсутствии вариантов, но теперь, когда в распоряжении браузеров появились различные API (программные интерфейсы приложения) для хранения данных, это уже не так. Из-за того, что cookie пересылаются с каждым запросом, они могут слишком сильно снижать производительность (особенно в мобильных устройствах). В качестве хранилищ данных на стороне пользователя вместо них можно использовать Web storage API ( localStorage and sessionStorage ) и IndexedDB.
Чтобы посмотреть сохранённые cookies (и какие ещё способы хранения данных использует веб-страница), можно использовать Storage Inspector (Инспектор хранилища) из раздела Developer Tools (Веб-разработка).
Создание cookie
Получив HTTP-запрос, вместе с откликом сервер может отправить заголовок Set-Cookie с ответом. Cookie обычно запоминаются браузером и посылаются в значении заголовка HTTP Cookie (en-US) с каждым новым запросом к одному и тому же серверу. Можно задать срок действия cookie, а также срок его жизни, после которого cookie не будет отправляться. Также можно указать ограничения на путь и домен, то есть указать, в течении какого времени и к какому сайту оно отсылается.
Заголовки Set-Cookie и Cookie
Заголовок Set-Cookie HTTP-отклика используется для отправки cookie с сервера на клиентское приложение (браузер). Простой cookie может задаваться так:
Теперь, с каждым новым запросом к серверу, при помощи заголовка Cookie (en-US) браузер будет возвращать серверу все сохранённые ранее cookies.
Сессионные cookie
Постоянные cookies
Постоянные cookie ( permanent cookies) удаляются не с закрытием клиента, а при наступлении определённой даты (атрибут Expires ) или после определённого интервала времени (атрибут Max-Age ).
Secure («безопасные») и HttpOnly cookies
Область видимости куков
Директивы Domain и Path определяют область видимости куки, то есть те URL-адреса, к которым куки могут отсылаться.
Атрибут Domain указывает хосты, на которые отсылаются куки. Если он не задан, то по умолчанию берётся доменная часть адреса документа (но без поддоменов). Если домен указан явно, то поддомены всегда включены.
Атрибут Path указывает URL, который должен быть в запрашиваемом ресурсе на момент отправки заголовка Cookie. Символ %x2F («/») интерпретируется как разделитель разделов, подразделы также включаются.
Если задано Path=/docs, то подходят и такие пути, как:
Куки SameSite
Куки SameSite позволяют серверам декларировать, что куки не должны отсылаться с межсайтовыми запросами, что в некотором роде обеспечивает защиту от межсайтовых подделок запроса (CSRF). Куки SameSite находятся пока в стадии эксперимента и поддерживаются не всеми браузерами.
Доступ из JavaScript посредством Document.cookie
Учитывайте, пожалуйста, вытекающие из этого проблемы в отношении безопасности, подчёркнутые ниже (раздел Security). Куки, доступные для JavaScript, могут быть похищены посредством XSS.
Безопасность
Важная информация никогда не должна храниться или передаваться в куках HTTP, поскольку этот механизм сам по себе небезопасен.
Захват сессии (session hijacking) и XSS
Атрибут HttpOnly помогает понизить эту угрозу, перекрывая доступ к кукам из JavaScript..
В Wikipedia приведён хороший пример CSRF. В сообщение (например, в чате или на форуме) включают (якобы) изображение, которое, на самом деле, представляет собой запрос к банковскому серверу на снятие денег:
Теперь, если вы зашли в свой банковский аккаунт, а куки по-прежнему действительны (и никакой дополнительной проверки не требуется), то при загрузке HTML-документа с этим изображением деньги будут переведены с вашего счета. Для защиты от этого используется ряд методов:
Отслеживание и частные данные
Сторонние (Third-party) куки
Куки связаны с определённым доменом. Если он совпадает с доменом страницы, на которой вы находитесь, то их называют «куками первого лица» (first-party cookies). Если это другой домен, их называют «сторонними куками» (third-party cookies). Куки первого лица отсылаются только на тот сервер, который их создал. Однако, страница может содержать изображения или другие компоненты (например, рекламные баннеры), хранящиеся на других серверах. Куки, посылаемые через такие компоненты, используются, главным образом, в рекламных целях или для отслеживания информации в сети. В качестве примера можно рассмотреть типы файлов cookie, используемые Google. Большинство браузеров по умолчанию разрешают использование сторонних куков, но есть расширения, позволяющие их блокировать (например, Privacy Badger от EFF).
Если вы не сообщите об использовании сторонних куков, а пользователь обнаружит их самостоятельно, то доверие к вам может пошатнуться. Чтобы избежать этого, лучше предоставлять соответствующую информацию. В некоторых странах использование куков регламентируется законодательством. Прочитать об этом можно, например, в Википедии в разделе cookie statement (создание куков).
Не отслеживать (Do-Not-Track)
Директива Евросоюза о куках
Правила по использованию куков в Евросоюзе (ЕС) определены в Директиве 2009/136/EC Европарламента (Directive 2009/136/EC), вступившей в действие 25 мая 2011. Это не закон, как таковой, а рекомендация странам-членам ЕС принять законы, соответствующие её требованиям. В каждой стране на этот счёт могут быть свои законы.
Согласно этой директиве для хранения или извлечения информации с компьютера пользователя требуется проинформировать его и получить соответствующее разрешение. С момента её появления многие сайты добавили баннеры, информирующие пользователя об использовании куков.
Подробнее об этом можно прочитать в соответствующем разделе Википедии (Wikipedia). За наиболее полной и точной информацией обращайтесь к законодательствам конкретных стран.
Куки-зомби и «вечные» куки
Более радикальный подход к кукам представляют собой куки-зомби, или «вечные» куки, которые восстанавливаются после удаления, и полное удаление которых умышленно затруднено. Они используют прикладные интерфейсы веб-хранилищ (Web storage API), Flash Local Shared Objects и другие методы собственного воссоздания в случае, если обнаружено их отсутствие.
Аутентификация пользователя на сайте. Сессии и куки
Особенности работы протокола HTTP
Как вы узнали из прошлой главы, работа с веб-сайтами в интернете происходит по протоколу HTTP.
Это замечательный и простой протокол, который действует по схеме «запрос-ответ». То есть клиент (браузер) пользователя посылает на сервер запрос, состоящий, как правило, только из заголовков, а затем получает ответ в виде заголовков ответа и тела самого документа.
В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ».
Иными словами, сервер не «запоминает» клиентов; каждый запрос он обрабатывает с «чистого листа».
Для сервера нет никакой разницы: запросил один пользователь страницу десять раз или десять разных пользователей по разу. Для него все запросы одинаковые.
Чем это неудобно для нас?
Часто сайты должны уметь идентифицировать своих посетителей, чтобы сохранять и показывать им позже какую-либо информацию.
Например, интернет-магазины могут сохранять историю просмотров, чтобы рекомендовать потенциальным покупателям наиболее подходящие им товары. Или агрегатор новостей мог бы предложить пользователям выбирать только интересующие их рубрики.
К счастью, протокол HTTP, а также все браузеры предоставляют возможность сохранения информации о пользователе.
Cookies
Cookies (в дальнейшем просто «куки») — небольшие фрагменты данных, которые веб-сервер отправляет браузеру.
Браузер сохраняет их у себя, а при следующем посещении веб-страницы отправляет обратно. Благодаря этому, веб-сервер сможет узнать своего «старого» посетителя, идентифицировать его.
Пример
Задача очень проста: сохранять и показывать посетителю страницы, сколько раз он посетил наш сайт. Для этого будем сохранять количество посещений в отдельной куке, увеличивая значения на единицу при каждой загрузке страницы.
Как установить куки: функция setcookie
Являясь серверным языком программирования, PHP может управлять заголовками, которые отправляет сервер, а значит может устанавливать и читать куки.
Чтобы добавить новую куку, необходимо вначале определиться со следующими критериями:
Обратите внимание, что срок жизни указывается в относительной величине. В этом примере кука будет существовать ровно 30 дней с момента установки.
Как прочитать куки
Собираем всё вместе
Теперь, научившись устанавливать и читать куки, напишем полноценный сценарий, который будет считать и выводить количество посещений страницы пользователем:
Сессии
Мы уже умеем сохранять информацию для пользователя между посещениями страницы с помощью кук. Но зачем же нам ещё сессии, и для чего они нужны?
Сессии, они же сеансы, это, по сути, просто удобная обёртка над куками. Они также позволяют хранить данные, релевантные пользователю, но с некоторыми отличиями и ограничениями:
Как устроены сессии
Благодаря существованию сессий в PHP, мы можем сохранять любые данные так же просто, как присваивать их переменным. Но, в отличие от переменных, эти данные будут сохраняться для пользователя между запросами в пределах сеанса.
Перепишем сценарий для подсчета посещений, но теперь используем сессии:
Аутентификация
Представим интернет-магазин. Все его страницы можно разделить на две половины: публичные и приватные.
К публичным относятся страницы каталога, информации о товаре, условия доставки и так далее. К приватным — корзина покупок, история заказов.
Совершенно очевидно, что корзина покупок у каждого покупателя должна быть своя, а иметь к ней доступ должен только сам владелец и никто больше.
Процедура проверки возможности доступа пользователя к определенной части сайта и называется аутентификацией.
Весь процесс аутентификации всегда состоит из нескольких шагов:
Ещё немного терминологии
Следует различать два термина: аутентификация и авторизация.
Аутентификация — проверка подлинности предоставленного пользователем идентификатора (пара логин-пароль).
Авторизация — процесс проверки и предоставления прав пользователю на выполнение определённого действия.
В примере с интернет-магазином аутентификация выполняется, когда пользователь заполняет форму входа и попадает в свой личный кабинет. Сценарий, обрабатывающий форму, лишь проверяет, что такой пользователь существует, и его пароль совпадает.
Авторизация включается в работу, когда пользователь выполняет какое-нибудь действие. Например, удаляет товар из своей корзины. Во время этого действия сценарий должен проверить принадлежность товара к корзине этого пользователя. Без такой проверки пользователь мог бы удалить товар из чужой корзины.
Логика авторизации намного сложнее, чем простая проверка совпадения почты и пароля при входе на сайт. В авторизацию могут также входить следующие понятия: группы пользователей, виды действий, ресурсы, иерархия ролей и действий. Этой теме можно посвятить отдельную главу. Мы не рассматриваем авторизацию в рамках этого учебника, потому что эта тема выходит за рамки «базовой».
Регистрация на сайте
Перед тем, как мы начнем добавлять аутентификацию на своем сайте, придётся добавить форму для регистрации нового аккаунта.
Аккаунт — это учётная запись пользователя.
Чтобы завести аккаунт, требуется пройти регистрацию — это заполнение специальной формы, где пользователь указывает свою почту, пароль, и, возможно, дополнительную информацию.
После регистрации все данные из формы сохраняются в базе данных как есть. Но хранению паролей нужно уделить особое внимание.
Хранение паролей
Пароль пользователя — это секретный набор символов, который используется в дальнейшем в ходе аутентификации. Зная пароль пользователя, злоумышленник может войти на сайт под его именем. По этой причине пароль нельзя хранить в базе в открытом виде. Ведь если информацию из БД сайта украдут, то данные всех пользователей станут скомпрометированными.
Вместо самого пароля, в базе будут храниться их отпечатки — хэши.
Что такое хеширование
Отпечаток (хэш) — это результат работы функции хэширования, которая вернёт для любого значения строку фиксированной длины.
Используя специальный математический алгоритм, такая функция умеет преобразовывать любую переданную информацию к строке фиксированной длины (например, 32 или 64 символа). Причём любому массиву информации, будь это все статьи из Википедии, или одно слово, всегда будет соответствовать уникальный отпечаток. Повторный вызов функции для одного и того же исходника всегда возвращает один и тот же хэш.
Обратная операция (получить из отпечатка оригинал) невозможна.
Возьмём простой пример. У нас есть информация, для которой мы хотим получить отпечаток. Пусть такой информацией будет следующая строка:
Результат обработки этой строки хэширующей функцией SHA-1 будет таким:
6b3cb0df50fe814dee886b4e1c747dda6ce88b37
Хэширующие функции часто используются для контроля целостности информации при передачи по сети. Например, чтобы убедиться в том, что загруженный файл не был повреждён, достаточно получить его хэш и сравнить данный хэш с опубликованным на сайте. Если в файле поменялся хоть один байт, то эти отпечатки будут совершенно разными.
Нам же функции хэширования помогут для сравнения паролей.
Реализация регистрации пользователя
Вернёмся к форме регистрации.
Выше говорилось, что вместо пароля лучше хранить его отпечаток. Для получения отпечатка существуют множество хэшируюших функций. К счастью, нам не надо разбираться в их многообразии, потому что в PHP есть стандартная функция, которая делает ровно то, что нужно.
Вот пример как из пароля получить отпечаток, пригодный для хранения в базе:
Проверка пароля при входе на сайт
Использование сессии для контроля доступа
Сессии чаще всего используются для хранения информации о залогиненном пользователе. Принцип работы здесь очень простой: внутри сценария, ответственного за обработку формы входа, открывается новая сессия, куда записывается информация о вошедшем пользователе. Такой информацией может быть ассоциативный массив со всеми значениями из соответствующей записи из БД.
Затем добавим код, проверяющий существование сессии в сценарии, которые должны быть закрыты от анонимных пользователей. Если сессия пуста, значит данный пользователь не выполнял вход на сайт, и доступа к данной странице он не имеет.
В этом случае можно вернуть код ответа 403 и показать сообщение об ошибке, либо принудительно выполнить переадресацию на главную страницу.
Выход с сайта
Что такое куки и сессия?
Типичные заблуждения о компьютерных вирусах
Нужно ли удалять файлы cookie
Cookie и session – что это? Как работают файлы куки и сеанса посещения (сессии)? В чем разница?
Предварительно о файлах cookie и session
HTTP — это протокол * без сохранения состояния, что означает, что каждый запрос, отправляемый клиентом на сервер, полностью независим. Сервер не может подтвердить идентификационную информацию текущего клиента, а также не может определить, является ли отправитель предыдущего запроса и отправитель этого запроса одним и тем же клиентом.
* Протокол — это система обязательных к соблюдению правил при обмене данными внутри или между компьютерами, принятых с целью совместимости программного обеспечения.
Чтобы отслеживать взаимодействие между клиентом и сервером, технология поддержки состояния HTTP-соединения стала Cookie и Session.
Что такое cookie?
Cookie (куки) — это небольшой файл или фрагмент данных, который сервер отправляет в веб-браузер пользователя.
Браузер может сохранить его и отправить обратно с последующими запросами на тот же сервер. Обычно он используется, чтобы определить, поступили ли два запроса из одного и того же браузера.
Сервер также может изменять содержимое файла cookie по мере необходимости.
Важно: файлы cookie не являются междоменными. Файлы cookie на стороне клиента управляются браузером, гарантируя, что, к примеру, Google будет использовать только файлы cookie Google, а не файлы cookie Facebook, тем самым обеспечивая конфиденциальность пользователя. Браузер определяет, может ли веб-сайт использовать файлы cookie на основе имени домена.
Что такое session?
Session (сессия или сеанс посещения)- это ещё один механизм для записи состояния сессии между сервером и клиентом, чтобы различать файлы cookie. Разница в том, что куки хранятся в клиентском браузере, а сессия хранится на сервере.
Сессия хранится на сервере, а идентификатор сессии будет храниться в файле cookie о клиенте.
Как работают файлы куки и сессии
Куки и сессия — принцип работы
Когда клиент отправляет запрос на сервер в первый раз, сервер создаёт соответствующий пакет данных сессии согласно соответствующей информации, представленной пользователем. Сервер отвечает на запрос клиента и возвращает браузеру уникальную идентификационную информацию SessionID.
Браузер сохраняет преобразованный SessionID в cookie, а cookie записывает, к какому доменному имени принадлежит SessionID.
Когда клиент посещает сервер во второй раз, запрос автоматически определяет, есть ли информация cookie под этим доменным именем.
Если это так, то информация cookie будет отправлена на сервер. Сервер получит идентификатор сессии из файла куки, а затем найдет соответствующую информацию о сессии в соответствии с идентификатором session.
Различия между куки и сессией
Безопасность
Сессия безопаснее, чем куки. Сессия хранится на стороне сервера, а файл cookie хранится на стороне клиента.
Данные о статусе, хранящиеся в браузере, опасны, и не исключено, что информация о статусе в браузере может быть искусственно изменена с целью обмана сервера. Как только это произойдет, ваша конфиденциальность может быть утрачена, что приведёт к нежелательным потерям.
Типы хранимых значений
Куки поддерживают только сохранение строковых данных. Если для них заданы другие типы данных, их необходимо преобразовать в строку.
Сессия может хранить данные любого типа.
Период действия
Cookie можно настроить на длительное хранение.
Время окончания сессии относительно короткое, и клиент перестанет быть допущенным, если сессия закончится.
Размеры хранилища
Объём данных, содержащихся в одном файле cookie, не может превышать 4 КБ, что явно недостаточно для сложных данных состояния.
Данные хранилища session выше, чем cookie. Когда посещений слишком много, будет задействовано больше ресурсов сервера.
Разница между Cookies и сессиями
Пожалуйста, объяснить мне простыми словами, а не заученными терминами, как и с чем работать? Что и для чего надо? Можно с примерами в которых будет пояснение, спасибо.
3 ответа 3
Это разные явления.
Cookie — это просто пара имя-значение, которую (точнее, которые) сервер может оставить у клиента (браузера). Наглядно:
Упрощенно, не затрагивая тонкости — все, вот все, что представляют собой cookies.
Сессии — более эфемерное понятие, которое не привязано к какой-то конкретной реальной технологии. Это просто некая методика, которая позволяет отличить одного клиента от другого, и, как правило, где-то хранить связанные с каждым клиентом данные.
Еще можно хранить идентификаторы сессий в других местах. Например, Local Shared Objects («флэшевские cookie»), использовать возможности хранилищ HTML5, и еще ряде менее тривиальных мест, но PHP этого «из коробки» не умеет.
Соответственно, раз и cookies и поддержка use_trans_sid (перезаписи адресов) отключены, то PHP не может нигде оставить у клиента «метку». И сессии, по сути, не работают. Это, в общем-то, не должно быть проблемой — если клиенту надо — он включит cookies.
Еще момент. Сами по себе сессии не дают авторизации — это только хранилище. Авторизацию делаете Вы сами (или фреймворк, которым Вы воспользовались). Вы пользуетесь тем, что данные, связанные с сессией (в типичной PHP’шной реализации) хранятся на сервере, и клиент их там подменить не может.
Соответственно, когда клиент аутентифицируется — в сессии сохраняется кто он. Обратно — если у нас в сессии записано кто он — можно этому верить. Вся дальнейшая логика — пускать ли клиента, давать ли ему какие-то возможности и т.д. — на Вас.
Как работать с куки и сессиями? В каждом файле надо делать проверку на существование сессии, для того чтобы если их нет то человек не смог зайти на эту страницу?
Зависит от того, что Вы хотите, и от того, как Вы все строите. Если к этой странице должен быть доступ только у авторизованных пользователей — да, как вариант, так.
Иногда все запросы пропускают через один скрипт-«диспетчер». Иногда во все скрипты в начало вставляют include, которое инициализирует общую для всего сайта логику (сессии, авторизация).
