Чем куки отличаются от сессии в PHP?
Изучаю методы передачи данных, и возник такой вопрос: чем куки отличаются от сессий? Знаю, что кукам можно задать время, которое они будут действовать, а сессия умирает после закрытия браузера.
Но мне не понятно, в каких случаях нужно использовать куки, а в каких сессии?
- Вопрос задан более трёх лет назад
- 17481 просмотр
- Вконтакте
Нууу давайте разбираться.
Для начала почитайте про HTTP на той же вики. Досканально знать не нужно, но стоит минимально понимать структуру запросов/ответов, понимать что у запроса и ответа есть заголовки и тело (тела может и не быть, зависит от типа запроса/ответа).
Так вот. Куки. Куки живут на стороне браузера. Они передаются HTTP заголовком на каждый запрос на сервер (даже если вы за картинками полезли). Есть просто куки, есть http-only куки. Куки могут быть разграничены по хосту и пути. Все это дает нам гибкость и помогает с секьюрностью. В PHP содержимое $_COOKIE предоставляет нам SAPI. Когда PHP получает на обработку запрос, SAPI используемое (php-fpm, cgi, mod_php имеют свои реализации SAPI) в данный момент берет заголовки и тело запроса, парсит их и заполняет все эти суперглобальные массивы типа $_SERVER, $_GET и в том числе и $_COOKIE. Все что прислал нам клиент (что-то что делает запросы это клиент, что-то что их обрабатывает — сервер), а куки шлет нам браузер только те что можно исходя из того куда шлется запрос. Устанавливаются куки заголовком Set-Cookie в ответе, то есть тут больше нужно читать в принципе про HTTP а не про PHP. PHP просто позволяет вам работать с этим добром. Вы можете сэтить куки напрямую работая с заголовками ответа при помощи функции header. Более того, если выставить время жизни куки в 0, то как раз таки они а не сессия будет сбрасываться при закрытии браузера так как тот будет забывать все такие куки.
Вот. сессии. В PHP сессия обычно это файл. Просто какой-то файл с рандомным именем. Если скажем в php.ini указано session.autostart или делается вызов session_start то создается файл под сессию пользователя (можно переместить в рэдис или мемкэш, свое хранилище и т.д в зависимости от нужд. Так же данные можно шифровать, что по умолчанию и происходит). Этот файл имеет ID, просто какая-то рандомная строка. И если при обработке запроса не нашлась сессия с предыдущего запроса — создается новая.
И вот мы подошли к самому интересному — как PHP связывает сессию с предыдущего запроса с текущей. И тут все довольно просто — куки. Когда пользователю присваивается сессия, автоматически сэтится http-only (что бы нехорошие люди не могли из js увести нашу сессию) кука, в которую записан идентификатор сессии. В дебагере браузера можете посмотреть есть ли у вас кука PHPSESSID (название можно менять в настройках, да и вообще сессии можно не только через куки связывать, но это уже загоны по секьюрности) когда будете эксперементировать с сессиями.
Когда запрос обрабатывается SAPI, при наличии session.autostart, перед тем как начинать создавать новую сессию, пых все же смотрит а есть ли у нас кука с идентификатором сессии, проверяет есть ли у него такая, и если есть успокаивается и не создает новую. Поскольку сессия привязывается через куки, то можно выставить время жизни этой самой куки (в php.ini) и таким образом регулировать время жизни сессии.
Вот. когда использовать куки а когда сессии? Желательно понимать, что чем больше данных в куках (а у них есть лимит к слову) — тем больше данных мы передаем на каждый запрос. То есть это не круто когда что бы получить 1 килобайт данных мы должны в заголовках передать пару килобайт кук. Люди, повернутые на оптимизации, даже картинки хранят на отдельных cookie-less доменах что бы уменьшить количество трафика и пакетов (обычно простенький HTTP запрос влазит в размеры одного TCP пакета). Если вам нужно работать с этими данными из JS на любой странице, например локаль выбранноую пользователем для того что бы применять переводы еще и в JS, то стоит использовать куки. Для всео остального лучше конечно же использовать сессии. Во всяком случае на начальных этапах когда что-то сильно сложное вам делать не придется.
Разница между cookie и сессиями
Не так давно я писал статью о том, как сделать регистрацию и авторизацию пользователей на сайте. И там я написал, что при авторизации надо записать информацию об этом (логин и шифрованный пароль) в cookie, либо в сессию. Однако, возникает вопрос: «Что же выбрать: cookie или сессии?«. В этой статье я собираюсь разобрать разницу между сессиями и cookie, чтобы Вы окончательно определились с выбором.
Принципиальная разница между cookie и сессиями состоит в том, что cookie полностью хранятся в браузере пользователя (то есть на компьютере клиента), а при сессиях в cookie хранится только идентификатор сессии, а вся информация лежит на сервере в специальном уникальном файле. Именно из этого базового различия вытекают все остальные.
Если Вы решили хранить логин и пароль в cookie, то должны понимать, что cookie можно украсть (много существует способов, но не буду сейчас на них останавливаться), а, следовательно, получить логин и, в лучшем случае, шифрованный пароль (а если не шифруете, то и сам пароль). И если он зашифрован обычной md5(), то его можно расшифровать с помощью специальных баз, которые можно поискать в Интернете. Если пароль достаточно популярный, то его легко расшифруют. То есть минус cookie — низкая безопасность.
Второй минус cookie — это то, что они живут ровно столько, сколько хранит их браузер. Чем это может обернуться? Простой пример.
У Вас серьёзный сайт, на котором у людей лежат крупные суммы денег (например, как WebMoney). Ваш посетитель пришёл в какое-нибудь Интернет-кафе, авторизовался, но выйти забыл (уверен, что с каждым из Вас это происходит регулярно). Дальше приходит злоумышленник заходит на его аккаунт и забирает cookie. Дальше процесс очевиден. А если бы использовались сессии, то по умолчанию через 15 минут бездействия пользователя происходил бы автоматический выход (файл с данными сессиями бы стирался). И ничего такого бы не произошло. Более того, ввиду того, что каждая сессия имеет уникальный идентификатор, то смысл воровства идентификатора сессии (а больше ничего взять не получится) уже отсутствует. Когда злоумшыленник придёт домой, этот идентификатор ему уже не поможет.
Но именно по причине временного хранения сессии, появляется большой минус сессий — неудобно. Допустим, человек авторизовался, чтобы следить за какими-нибудь данными (например, за входящей почтой), но делает это он примерно раз в полчаса. И каждый раз он вынужден авторизовываться, что, разумеется, неудобно.
Именно по этой причине cookie так популярны при работе с механизмом авторизации.
Вывод: если у Вас очень серьёзный сайт, где воровство аккаунта может привести к большим проблемам (любой сайт, где у людей хранятся деньги, либо какая-нибудь очень ценная личная информация), то надо использовать сессии. Если же у Вас сугубо информационный сайт, где материальная и личная ценность аккаунта стремятся к нулю — используйте cookie, и пользователи Вам скажут спасибо.
Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!
Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.
Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления
Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.
Порекомендуйте эту статью друзьям:
Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):
Она выглядит вот так:
Комментарии ( 3 ):
А можно ли как-нибудь сохранить в куки объект созданного мною класса?
Можно преобразовать его в строку и сохранить.
Но когда пользователь нажимает сохранить пароль в браузере а так делают многие то данные по любому в cooci браузера сохраняются.
Для добавления комментариев надо войти в систему.
Если Вы ещё не зарегистрированы на сайте, то сначала зарегистрируйтесь.
Сессия и куки в чем разница
Видео: HTTP протокол для Java-разработчика. Часть 2. Куки и сессии. Примеры на Java Spring Bean.
Содержание
главное отличие между сессией и куки является то, что сеанс хранится на стороне сервера, в то время как куки хранятся в браузере клиента.
Сессия и куки — это два термина, которые связаны с веб-сайтами и веб-разработкой. Сеанс создает файл во временном каталоге на сервере. В этом файле хранятся переменные сеанса и их значения. Во время посещения данные доступны для всех страниц сайта. С другой стороны, куки — это текстовые файлы, которые хранятся в браузере клиента. Когда клиент отправляет запрос на сервер, cookie-файл внедряется в запрос.
Ключевые области покрыты
1. Что такое сессия
— определение, функциональность
2. Что такое куки?
— определение, функциональность
3. Разница между сессией и куки
— Сравнение основных различий
Основные условия
Файлы cookie, сессии, веб-сайты
Что такое сессия
Сайт состоит из нескольких веб-страниц. Например, когда пользователь вводит свои данные в форму, эта информация будет передаваться с одной страницы на другую. Сессия может быть использована в этих ситуациях. Он хранит и передает информацию с одной страницы на другую временно. Сеанс сохраняется до тех пор, пока пользователь не закроет веб-сайт.
Например, веб-сайту покупок может потребоваться хранить и передавать такую информацию, как имя пользователя, идентификатор продукта, название продукта, цена продукта и т. Д., С одной страницы на другую. Сессия может быть использована в этих ситуациях. Обычно сеанс создает уникальный идентификатор для каждого браузера, чтобы распознать пользователя. Это позволяет избежать конфликта между несколькими браузерами.
Что такое куки?
Файлы cookie — это текстовые файлы, которые хранятся в браузере клиента. Они используются для целей отслеживания и идентификации пользователя. Во-первых, серверный скрипт отправляет набор файлов cookie в браузер. Это может быть имя, идентификационный номер и т. Д. Затем браузер сохраняет эту информацию на локальном компьютере.
Позже, когда браузер отправляет любой запрос на веб-сервер, он отправляет информацию о файлах cookie на сервер. Сервер использует эту информацию для распознавания пользователя. Поэтому куки могут быть использованы для дальнейшего использования. Они хранят информацию до тех пор, пока не будут удалены пользователем или установлены в соответствии с таймером. Закрытие браузера не удалит куки.
Разница между сессией и куки
Определение
Сеанс — это временный и интерактивный обмен информацией между двумя или более устройствами связи или между компьютером и пользователем. Файлы cookie представляют собой небольшие фрагменты данных, отправляемые с веб-сайта и сохраняемые на компьютере пользователя веб-браузером пользователя во время просмотра.
Способ хранения
Сеанс сохраняется на стороне сервера, в то время как файлы cookie хранятся в браузере клиента в виде текстовых файлов. В этом основное отличие сеанса от файлов cookie.
Количество данных
При рассмотрении возможностей этих двух сеансов может храниться большой объем данных, в то время как файлы cookie могут хранить минимальный объем данных.
Безопасность
Сеанс обеспечивает большую безопасность, поскольку трудно получить доступ к значениям сеанса. Файлы cookie обеспечивают минимальную безопасность, потому что легче получить доступ к значениям файлов cookie.
Удаление
Пользователь должен закрыть браузер, чтобы закрыть сеанс, так как сеанс доступен, пока браузер не будет открыт. Напротив, куки хранят информацию до тех пор, пока пользователь не удалит ее или не установит таймер.
Удержание нескольких переменных
В то время как сеанс содержит несколько переменных, куки нет.
надежность
Сеанс более надежен, чем файлы cookie, поскольку данные сеанса хранятся на сервере.
Заключение
Разница между сеансом и файлами cookie заключается в том, что сеанс хранится на стороне сервера, а файлы cookie хранятся в браузере клиента. Кроме того, сеанс является более надежным и безопасным, чем файлы cookie.
Разница между Cookies и сессиями
Здравствуйте, все никак не могу понять разницы между куки и сеансом. Насколько мне известно, если в броузере отключен прием кук, то авторизацию и регистрацию пользователь не пройдет, исходя из этих соображений для регистрации я делаю на session_start , но если я в броузере выключаю куки, то все ровно не заходит.
Как работать с куки и сессиями? В каждом файле надо делать проверку на существование сессии, для того, чтобы если их нет, то человек не смог зайти на эту страницу? Еще я замечал на некоторых сайтах, что в броузерной строке по мимо адреса еще есть session_name и session_id . Как это делается и для чего?
Пожалуйста, объяснить мне простыми словами, а не заученными терминами, как и с чем работать? Что и для чего надо? Можно с примерами в которых будет пояснение, спасибо.
Это разные явления.
Cookie — это просто пара имя-значение, которую (точнее, которые) сервер может оставить у клиента (браузера). Наглядно:
- Приходит клиент, спрашивает у сервера страницу.
- Сервер в заголовках ответе может установить cookies. Например, выдав два заголовка: Set-Cookie: foo=123 и Set-Cookie: bar=baz — по-русски — «запомни, foo — 123, а bar — baz».
- При следующем обращении клиент, если он решил запомнить, говорит серверу «Cookie: bar=baz; foo=123».
Упрощенно, не затрагивая тонкости — все, вот все, что представляют собой cookies.
Сессии — более эфемерное понятие, которое не привязано к какой-то конкретной реальной технологии. Это просто некая методика, которая позволяет отличить одного клиента от другого, и, как правило, где-то хранить связанные с каждым клиентом данные.
Как правило, сессии реализуются используя cookies и идентификаторы сессий. Т.е. сервер со своей стороны создает уникальный идентификатор, например, «1a2b3c» ( session_id про который вы справшивали), а клиента просит его запомнить. Обычно — при помощи cookies, говоря что-то в духе Set-Cookie: PHPSESSID=1a2b3c (где « PHPSESSID » — имя сессии, обычно, оно только одно, вести параллельно несколько сессий нужно редко). Со своей стороны сервер где-то (зависит от реализации, иногда это файл, например, /tmp/1a2b3c , иногда запись в БД, иногда еще что-то) хранит различные данные, которые ему приказано связывать с этой сессией. Например, имя пользователя.
PHP’шные сессии использовали не только cookies, но и аргументы в адресной строке. Т.е. перед отдачей страницы пользователю «переписывали» все ссылки в ней, добавляя свое «?PHPSESSID=1a2b3c». И клиент вместо « /forum.php » шел на « /forum.php?PHPSESSID=1a2b3c ». Таким образом сервер получал идентификатор сессии и все работало. Сейчас PHP по умолчанию такого не делает — у этого метода есть куча своих недостатков. Хотите включить — напишите ini_set(‘session.use_trans_sid’, true); , но нужно понимать связанные риски.
Еще можно хранить идентификаторы сессий в других местах. Например, Local Shared Objects («флэшевские cookie»), использовать возможности хранилищ HTML5, и еще ряде менее тривиальных мест, но PHP этого «из коробки» не умеет.
Соответственно, раз и cookies и поддержка use_trans_sid (перезаписи адресов) отключены, то PHP не может нигде оставить у клиента «метку». И сессии, по сути, не работают. Это, в общем-то, не должно быть проблемой — если клиенту надо — он включит cookies.
Еще момент. Сами по себе сессии не дают авторизации — это только хранилище. Авторизацию делаете Вы сами (или фреймворк, которым Вы воспользовались). Вы пользуетесь тем, что данные, связанные с сессией (в типичной PHP’шной реализации) хранятся на сервере, и клиент их там подменить не может.
Соответственно, когда клиент аутентифицируется — в сессии сохраняется кто он. Обратно — если у нас в сессии записано кто он — можно этому верить. Вся дальнейшая логика — пускать ли клиента, давать ли ему какие-то возможности и т.д. — на Вас.
Как работать с куки и сессиями? В каждом файле надо делать проверку на существование сессии, для того чтобы если их нет то человек не смог зайти на эту страницу?
Зависит от того, что Вы хотите, и от того, как Вы все строите. Если к этой странице должен быть доступ только у авторизованных пользователей — да, как вариант, так.
Иногда все запросы пропускают через один скрипт-«диспетчер». Иногда во все скрипты в начало вставляют include, которое инициализирует общую для всего сайта логику (сессии, авторизация).