что такое сессии и куки
Что использовать: Session против Cookie
Важнейшей особенностью веб-программирования является возможность беспрепятственно передавать данные от одной страницы к другой. Чаще всего этой возможностью пользуются для передачи логинов пользователей, сообщений об ошибке, содержимого “тележек” в интернет-магазинах и т.д.
Их разница заключается лишь в способе хранения данных: Печеньки хранят данные в браузере пользователя, а Сессии на стороне сервера.
Основы сессий (кратко)
В двух словах, сессии – это механизм, который позволяет однозначно идентифицировать клиент (браузер) пользователя и созданный для этого клиента файл на стороне сервера, в котором будут храниться необходимые данные.
Плюсы сессий
Минусы сессий
Основы “печенек”
“Печеньки” отправляются на сервер каждый раз, когда вы загружаете страницу. После создания “печеньки” ей задаётся срок жизни. По истечению этого срока – “печенька” прекращает своё существование.
Плюсы
Минусы
Использование печенек на практике
Создание печеньки.
Определение функции: bool setcookie ( string name [, string value [, int expire [, string path [, string domain [, int secure]]]]])
Создание печеньки
Использование печенек
Удаление печенек
Создание пустой печеньки равносильно её удалению, но, конечно, это действие не приведёт к удалению файла с компьютера пользователя. Однако, вы можете установить срок жизни печеньки, по истечению которого файл с информацией будет стёрт с пользовательского компьютера.
Использование сессий на практике
Создание сессии
Этот код должен находиться в верхней части кода, перед ним не должно быть сделано ни какого вывода (echo, print и т.д.). Эта функция проверяет, отправил ли пользовательский браузер печеньки или нет. Если они отправлены, то он загрузит данные из сессии, а если нет, то создаст новый файл сессии на сервере.
Присваиваем значение
Считываем значение сессии
Удаляем (очищаем значение) сессию
Уничтожаем сессию сессию
Краткий вывод
Сессии храняться на стороне сервера, а печеньки на стороне пользователя. Все они имеют свои преимущества и недостатки, но однажды, настанет день, когда вы сами поймёте, в какой ситуации лучше использовать сессии, а в какой печеньки.
Дополнение от Artem:
Вообще же лучше всего использовать клиентские способы хранения состояния + хранить состояния в базе данных и в крайнем случае (как пароли) хранить что-либо на сервере, то бишь в сессии. Иначе сервер просто не выдержит нагрузку.
Разница между cookie и сессиями
Не так давно я писал статью о том, как сделать регистрацию и авторизацию пользователей на сайте. И там я написал, что при авторизации надо записать информацию об этом (логин и шифрованный пароль) в cookie, либо в сессию. Однако, возникает вопрос: «Что же выбрать: cookie или сессии?«. В этой статье я собираюсь разобрать разницу между сессиями и cookie, чтобы Вы окончательно определились с выбором.
Принципиальная разница между cookie и сессиями состоит в том, что cookie полностью хранятся в браузере пользователя (то есть на компьютере клиента), а при сессиях в cookie хранится только идентификатор сессии, а вся информация лежит на сервере в специальном уникальном файле. Именно из этого базового различия вытекают все остальные.
У Вас серьёзный сайт, на котором у людей лежат крупные суммы денег (например, как WebMoney). Ваш посетитель пришёл в какое-нибудь Интернет-кафе, авторизовался, но выйти забыл (уверен, что с каждым из Вас это происходит регулярно). Дальше приходит злоумышленник заходит на его аккаунт и забирает cookie. Дальше процесс очевиден. А если бы использовались сессии, то по умолчанию через 15 минут бездействия пользователя происходил бы автоматический выход (файл с данными сессиями бы стирался). И ничего такого бы не произошло. Более того, ввиду того, что каждая сессия имеет уникальный идентификатор, то смысл воровства идентификатора сессии (а больше ничего взять не получится) уже отсутствует. Когда злоумшыленник придёт домой, этот идентификатор ему уже не поможет.
Именно по этой причине cookie так популярны при работе с механизмом авторизации.
Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!
Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.
Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления
Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.
Порекомендуйте эту статью друзьям:
Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):
Комментарии ( 3 ):
А можно ли как-нибудь сохранить в куки объект созданного мною класса?
Можно преобразовать его в строку и сохранить.
Но когда пользователь нажимает сохранить пароль в браузере а так делают многие то данные по любому в cooci браузера сохраняются.
Для добавления комментариев надо войти в систему.
Если Вы ещё не зарегистрированы на сайте, то сначала зарегистрируйтесь.
Copyright © 2010-2021 Русаков Михаил Юрьевич. Все права защищены.
Что такое куки и сессия?
Типичные заблуждения о компьютерных вирусах
Нужно ли удалять файлы 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. Когда посещений слишком много, будет задействовано больше ресурсов сервера.
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 и с функциями работы со строками. Для усвоения этого материала — отдельной статьи не нужно, хватит и мануала по приведенным ссылкам — никто за вас его читать не будет. Дерзайте!
И снова приветствую Вас, уважаемые читатели моего блога!
Немного подумал и решил сегодня написать статейку по программированию, а точнее про сесии и куки. Усаживайтесь поудобнее — начинаем!
Важнейшей особенностью веб-программирования является возможность беспрепятственно передавать данные от одной страницы другой. Чаще всего используется при работе с регистрацией, формами входа а также предания сообщений об ошибках и т.д.
Разница между куки и сессиями то как они хранят данные. Куки хранятся локально на компьютере пользователя тогда как сессии хранятся на сервере у вас.
Сессии
Сессии хранят временные данные о пользователях, и они особенно полезны, если вы не хотите, чтобы были доступны за пределами сервера. Это альтернатива использованию cookie, если пользователь отключил cookie на своем компьютере, поскольку PHP может автоматически переписать URL так, чтобы передать идентификатор сессии.
Cookie в действии
Cookie создаются вызовом функции setcookie(), сервер добавляет соответствующую строку в заголовок. Если вы попытаетесь послать cookie после того, как начнете посылать HTML, PHP отметит наличие серьезных ошибок, а cookie не будет размещен. Функция setcookie() принимает три основных параметра имя cookie, значение и дату окончания срока действия. Например:
Установка cookie без значения все равно что его удаление. Это не удалит файл с машины пользователя. Чтобы удалить файл вам нужно поставить значение cookie в прошлом времени и браузер удалит файл.
Сессии в действии
Получилась хоть и не большая, но познавательная статья.
Если есть вопросы или предложения — задавайте на этой странице. Обещаю, отвечу всем.
Также подписывайтесь на обновление новостей блога!
На этом буду прощаться с Вами — до новых встреч!