Сессия и куки в чем разница

Сессии (сеансы) в PHP

Сессии и cookies предназначены для хранения сведений о пользователях при переходах между несколькими страницами. При использовании сессий данные сохраняются во временных файлах на сервере. Файлы с cookies хранятся на компьютере пользователя, и по запросу отсылаются броузером серверу.

Использование сессий и cookies очень удобно и оправдано в таких приложениях как Интернет-магазины, форумы, доски объявлений, когда, во-первых, необходимо сохранять информацию о пользователях на протяжении нескольких станиц, а, во-вторых, своевременно предоставлять пользователю новую информацию.

Протокол HTTP является протоколом «без сохранения состояния». Это означает, что данный протокол не имеет встроенного способа сохранения состояния между двумя транзакциями. Т. е., когда пользователь открывает сначала одну страницу сайта, а затем переходит на другую страницу этого же сайта, то основываясь только на средствах, предоставляемых протоколом HTTP невозможно установить, что оба запроса относятся к одному пользователю. Т. о. необходим метод, при помощи которого было бы отслеживать информацию о пользователе в течение одного сеанса связи с Web-сайтов. Одним из таких методов является управление сеансами при помощи предназначенных для этого функций. Для нас важно то, что сеанс по сути, представляет собой группу переменных, которые, в отличие от обычных переменных, сохраняются и после завершения выполнения PHP-сценария.

При работе с сессиями различают следующие этапы:

открытие сессии
регистрация переменных сессии и их использование
закрытие сессии

Открытие сессии

Самый простой способ открытия сессии заключается в использовании функции session_start, которая вызывается в начале PHP-сценария:

session_start

Синтаксис:

session_start

Эта функция проверяет, существует ли идентификатор сессии, и, если нет, то создает его. Если идентификатор текущей сессии уже существует, то загружаются зарегистрированные переменные сессии.

Регистрация переменных сессии

После инициализации сессии появляется возможность сохранять информацию в су-перглобальном массиве $_SESSION. Пусть имеется файл index.php в котором в массив $_SESSION сохраняется переменная и массив.

На страницах, где происходит вызов функции session_start(), значения данных переменных можно извлечь из суперглобального массива $_SESSION. В следующем листинге приводится содержимое страницы other.php, где извлекаются данные, ранее помещенные на странице index.php.

// Инициируем сессию session_start(); // Выводим содержимое суперглобального массива $_SESSION echo ""; print_r($_SESSION); echo "

"; ?>

Результат работы скрипта выглядит следующим образом:

 Array 
( 
[name] => value 
[arr] => Array 
( 
[0] => first 
[1] => second 
[2] => third 
) 

)

Закрытие сессии

После завершения работы с сессией сначала нужно разрегистрировать все переменные сессии, а затем вызвать функцию unset():

Синтаксис:

unset

Пример простой сессии

Рассмотрим пример простой сессии, работающей с тремя страницами. При посещении пользователем первой страницы открывается сессия и регистрируется переменная $username. Соответствующий код реализации приведен в листинге:

Результат работы этого сценария показан на рис:

После этого, пользователь maksim нажимает на ссылку и попадает на страницу page2.php, код которой приведен в листинге:

Результат работы этого скрипта показан на рис:

При нажатии на ссылку, пользователь попадает на страницу page3.php, при этом происходит разрегистрация сеансовой переменной и уничтожение сессии. Соответствующий код реализации приведен в листинге:

  session_start(); 
unset($_SESSION['username']); // разрегистрировали переменную 
echo 'Привет, '.$_SESSION['username']; 
/* теперь имя пользователя уже не выводится */ 
session_destroy(); // разрушаем сессию 
?>

Как видно из рисунка, после разрегистрации сеансовой переменной значение массива $_SESSION[‘username’] уже недоступно:

Если Вам нужна частная профессиональная консультация от авторов многих книг Кузнецова М.В. и Симдянова И.В., добро пожаловать в наш Консультационный Центр SoftTime.

Разница между cookie и сессиями

Не так давно я писал статью о том, как сделать регистрацию и авторизацию пользователей на сайте. И там я написал, что при авторизации надо записать информацию об этом (логин и шифрованный пароль) в cookie, либо в сессию. Однако, возникает вопрос: «Что же выбрать: cookie или сессии?«. В этой статье я собираюсь разобрать разницу между сессиями и cookie, чтобы Вы окончательно определились с выбором.

Принципиальная разница между cookie и сессиями состоит в том, что cookie полностью хранятся в браузере пользователя (то есть на компьютере клиента), а при сессиях в cookie хранится только идентификатор сессии, а вся информация лежит на сервере в специальном уникальном файле. Именно из этого базового различия вытекают все остальные.

Если Вы решили хранить логин и пароль в cookie, то должны понимать, что cookie можно украсть (много существует способов, но не буду сейчас на них останавливаться), а, следовательно, получить логин и, в лучшем случае, шифрованный пароль (а если не шифруете, то и сам пароль). И если он зашифрован обычной md5(), то его можно расшифровать с помощью специальных баз, которые можно поискать в Интернете. Если пароль достаточно популярный, то его легко расшифруют. То есть минус cookie — низкая безопасность.

Второй минус cookie — это то, что они живут ровно столько, сколько хранит их браузер. Чем это может обернуться? Простой пример.

У Вас серьёзный сайт, на котором у людей лежат крупные суммы денег (например, как WebMoney). Ваш посетитель пришёл в какое-нибудь Интернет-кафе, авторизовался, но выйти забыл (уверен, что с каждым из Вас это происходит регулярно). Дальше приходит злоумышленник заходит на его аккаунт и забирает cookie. Дальше процесс очевиден. А если бы использовались сессии, то по умолчанию через 15 минут бездействия пользователя происходил бы автоматический выход (файл с данными сессиями бы стирался). И ничего такого бы не произошло. Более того, ввиду того, что каждая сессия имеет уникальный идентификатор, то смысл воровства идентификатора сессии (а больше ничего взять не получится) уже отсутствует. Когда злоумшыленник придёт домой, этот идентификатор ему уже не поможет.

Но именно по причине временного хранения сессии, появляется большой минус сессий — неудобно. Допустим, человек авторизовался, чтобы следить за какими-нибудь данными (например, за входящей почтой), но делает это он примерно раз в полчаса. И каждый раз он вынужден авторизовываться, что, разумеется, неудобно.

Именно по этой причине cookie так популярны при работе с механизмом авторизации.

Вывод: если у Вас очень серьёзный сайт, где воровство аккаунта может привести к большим проблемам (любой сайт, где у людей хранятся деньги, либо какая-нибудь очень ценная личная информация), то надо использовать сессии. Если же у Вас сугубо информационный сайт, где материальная и личная ценность аккаунта стремятся к нулю — используйте cookie, и пользователи Вам скажут спасибо.

Создано 13.05.2011 00:08:21

Михаил Русаков

Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!

Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.

Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления

Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.

Порекомендуйте эту статью друзьям:

Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

Кнопка:
Она выглядит вот так:
Текстовая ссылка:
Она выглядит вот так: Как создать свой сайт
BB-код ссылки для форумов (например, можете поставить её в подписи):

Комментарии ( 3 ):

ArturPanteleev 12.07.2012 13:30:30

А можно ли как-нибудь сохранить в куки объект созданного мною класса?

Admin 12.07.2012 13:35:54

Можно преобразовать его в строку и сохранить.

pavell 08.07.2013 16:17:00

Но когда пользователь нажимает сохранить пароль в браузере а так делают многие то данные по любому в cooci браузера сохраняются.

Для добавления комментариев надо войти в систему.
Если Вы ещё не зарегистрированы на сайте, то сначала зарегистрируйтесь.

Разбираемся в кукисах, сессиях и токенах

Cookies (далее – кукисы) – это пары ключ:значение, передаваемые сервером в заголовке. Их может быть несколько: один кукис username, и один userrole, к примеру. Кукисы работают, когда у вас лень, или когда можно не особо заморачиваться c безопасностью, ведь в них передается много чего.

Сессии (иначе, сеансы; sessions) – это “как кукисы”, но вместо передачи реальных данных в кукисах, передается только маркер (иначе говоря, идентификатор, “айдишник”, ID). Так называемый session-id. В таком подходе, клиент не знает, что передается в сессии, только сервер имеет доступ. В этом методе, backend должен знать, какая сессия сейчас активна. То есть, backend в этом подходе считается “stateful”, то есть “работает от состояния”.

Токены – в чем-то похожи на обычные, “несессионные” кукисы. Токены хорошо шифруются, взломать-подменить сложно. Бекэнд в этом подходе – stateless, не зависит от состояния: токен, взятый из одного бекэнда, будет работать на любом другом бекэнде, то есть этот подход “горизонтально масштабируемый”.

Подробнее:

Чтобы понять нюансы применения кукисов, сессий и токенов, нужно вспомнить, где они применяются. Итак, нам надо войти в свой аккаунт в банке. Стандартом является окно входа, здесь мы вводим логин и пароль, и кнопка с надписью “Отправить” или “Войти”, для отправки пары логин/пароль на сервер банка.

Сервер, приняв эту пару, теперь должен проверить, кто вы. Для этого производится сопоставление с базой; если введенная вами пара совпадает с имеющимися в базе (и ничего не вызывает подозрений), то сервер перенаправит на главную страницу аккаунта.

При этом, в базе данных создается сессия; а также, в БД добавляется событие успешного входа. Клиенту, то есть вам, как бы в обмен на пару логин/пароль отправляется кукис, содержащий session_id.

Таким образом, сервер хранит информацию о сессии в своей базе данных, в то время как вам отправляет только кукис c идентификатором, session_id. Кукис сохраняется в вашем браузере. Session_id генерируется рандомно – поэтому угадать его невозможно. После выхода из своего аккаунта в банке, сессия удаляется из сервера, но при этом сервер передает в браузер инструкцию об удалении кукиса с session_id.

При следующем заходе в аккаунт, браузер автоматически отправляет кукис с session_id, и сервер оценивает этот кукис на валидность (неподмененность, непросроченность). Важно понимать, что в этом следующем заходе на сервер, пара логин/пароль уже не нужна для авторизации.

Кукисы можно сравнить с хранением данных о клиенте на членской карте в спортзале. Там хранится номер – membershipID, и некоторые другие уточняющие детали. Когда карту проводят через приемное устройство на двери, оно проверяет карту на валидность, и принимает решение, впускать ли. Так же и с кукисами: их session_id срабатывают только на этом сайте, подобно тому как нельзя войти в офисное здание, проводя картой для спортзала; кукисом для одного сайта нельзя воспользоваться для входа на любой другой сайт.

Банковский сервер поддерживает сессию в *живом* состоянии до тех пор, пока вы проявляете активность на банковском сайте. Если не производить никаких действий достаточно долго, сервер зафиксирует это, и спросит логин/пароль, когда попытаетесь войти снова.

Итак, этот подход называется “cookie-based authentication”. Этот метод предполагает создание сессии на сервере, для обработки авторизации. Кукис – лишь носитель для передачи маркера (sessionID). Кукисы используются, потому что это просто. И удобно – браузер всегда отправляет кукисы после каждого запроса от сервера. То же и с картой для спортзала: она удобна, (“вынул да провел”), нет нужды предъявлять свой бумажный “аусвайс” охраннику на входе. Конечно, можно и скопировать фотографию карты на смартфон и показывать эту фотографию, это без разницы, носитель не имеет значения, концепция та же. Банк хранит информацию о сессии у себя на сервере, вы ее видеть не можете, но может и хранить другую информацию у вас в браузере смартфона, а конкретно в кукисах. Там обычно хранится не только сессионный ID, но и дополняющая, уточняющая информация, которая также важна для удобства – последние посещенные страницы на сервере, размер шрифта на странице у конкретного клиента, или скажем выделение цветом какого-то уведомления.

Почему же серверы не хранят в кукисах все данные?

Теперь рассмотрим вопрос, почему серверы не “сгружают” в кукисы всю информацию о сессиях и клиенте.

Быстрый ответ: потому что кукисы ненадежные. Уточним: недостаточно надежные, чтобы доверять им в полной мере. Ведь кукисы приходят от клиента, а иногда от того, кто клиентом лишь назвался. Поэтому сервер работает со своими базами данных, которые (опять же, в идеале) – наполнены только надежными данными.

Есть и альтернатива. Хранить данные о клиенте – у клиента, и подписывать их. То есть, удостоверять. В этом подходе, каждый кто обладает подписью, может быстро проверить, подменяли ли данные. Простой способ проверить это – JSON WEB TOKENS.

Авторизация кукисами отлично работала много-много лет, но она медленно устаревает, особенно в специфических сферах, например финансы.

Представим, что вам нужно поставить в смартфон некое финансовое приложение, для контроля своих расходов. Естественно, для этого нужен доступ к банковскому счету. Но вы не хотите давать этому приложению свой логин/пароль к банковскому счету. Хотя бы потому, что компания, которая создает приложения – это по умолчанию не банковская, не “серьезная”. В этом случае банк переправляет вас к странице с вопросом “Эй, тут какое-то приложение запрашивает разрешение на доступ к вашим банковским транзакциям, разрешить?”. Если вы ответите “Да”, приложение получит токен с доступом к транзакциям.

Однако, приложение всего лишь видит список транзакций, и оно не сможет “самоуправно” сделать переводы между счетами, и даже видеть то обилие деталей о счетах, которые видны вам на сайте банка.

Этот токен как бы аналогичен рандомно сгенерированному паролю. Еще лучше сравнить токен с выдачей однодневного пароля к Wi-Fi в гостинице.

Аналогичная процедура работает всякий раз, когда Facebook или Google показывают диалог: “Разрешать ли этому сайту доступ к Вашему профилю в Facebook?”

Таким образом, в этом подходе вы никогда не отправляете свой логин/пароль; и в любой момент вы можете отозвать разрешение на доступ к своему банковскому аккаунту. Просто сгенерированный ранее токен объявляется более недействующим.

Вообще, в таких случаях чаще применяется механизм OpenID, но и его аналог JSON Web Tokens применяется очень часто.

Еще раз о важной разнице между токеном и session_id в кукисе

Разница состоит в том, что токен всегда следует принятому стандарту, тогда как сессии применяются по мере необходимости. Кроме того, для токенов не всегда нужна открытая сессия.

Если идет речь о JWT-токенах, то такой токен, помимо “своей” нагрузки, содержит и информацию о сессии, и актуальные данные о клиенте.

Когда говорим о токенах, важно заметить, что этот тип взаимодействия предполагает наличие нескольких сторон, среди которых могут быть не вполне надежные, точнее “не вполне доверяющие друг другу”. То есть, вы доверяете своему банку, передаете туда логин/пароль, но, вполне естественно, боитесь передавать их приложению, скачанному в аппсторе, или вообще найденному на файло-свалке.

Еще один нюанс: токен имеет ограниченное “время жизни”, то есть срок валидности. После “просрочки” токена, генерируется новый; как принято говорить – refreshed, “освежается.”

Токен дает доступ к некоему, достаточно ограниченному, набору данных о клиенте или компании; то есть, он позволяет приложению видеть финансовые транзакции, и это все; не видны другие данные, это укрепляет безопасность.

Токены отправляются посредством HTTP-заголовков, но не в кукисах, поскольку сейчас большая часть взаимодействий происходит в браузерах смартфонов, и кукисы тут уже не очень удобны.

Как говорится, “Кукисы отправляются как HTTP-заголовки, но браузеры обрабатывают их по другому, не как другие заголовки”

Итак

В целом, распространены оба подхода, как сессии с кукисами, так и токены. Часто они применяются параллельно в проекте. К примеру, сессия с кукисами – на сайте, а токены – в приложении той же компании. Поэтому нужно знать, как работают оба эти подхода.

Разница между Cookies и сессиями

Ключевое отличие: Cookie, также известный как HTTP cookie, веб cookie или cookie браузера, представляет собой небольшой пакет данных, который отправляется с веб-сайта на сервер и хранится в веб-браузере пользователя. Файлы cookie используются для отправки информации создателю веб-сайта о предыдущих действиях пользователя, когда они последний раз обращались к веб-сайту. Сеансы — это полупостоянный интерактивный обмен информацией между двумя взаимодействующими устройствами, такими как пользовательский компьютер и сервер. Это также называется диалогом, беседой или встречей между двумя или более устройствами. Сессия — это, по сути, общение, которое устанавливается в одной точке и разрывается в другой точке.

Файлы cookie и сеансы — это два типа технологий, используемых при работе со Всемирной паутиной. Файлы cookie и сеансы используются для сохранения данных определенного типа, чтобы страницы загружались быстрее, быстрее и использовали меньшую пропускную способность. Файлы cookie обычно хранятся на клиентской машине, а сеансы хранятся на серверной машине. Эти двое отличаются друг от друга тем, как они ведут себя и что они делают, поэтому их не следует путать как одно и то же.

Cookie, также известный как HTTP cookie, веб cookie или cookie браузера, представляет собой небольшой пакет данных, который отправляется с веб-сайта на сервер и хранится в веб-браузере пользователя. Файлы cookie используются для отправки информации создателю веб-сайта о предыдущих действиях пользователя, когда они последний раз обращались к веб-сайту. Эти файлы cookie были разработаны, чтобы позволить веб-сайтам запоминать действия клиента во время предыдущих посещений. Когда клиент получает доступ к веб-сайту во второй раз, файлы cookie отправляются из браузера клиента на веб-сайт. Файлы cookie сохраняют такие данные, как нажатие на определенные кнопки, вход в систему или запись о том, какие страницы посетил пользователь даже несколько месяцев или лет назад. Многие компании также используют файлы cookie в рекламных целях, показывая рекламу того, что ищет пользователь.

Хотя cookie-файлы не могут содержать вирусы или другие виды вредоносного ПО, довольно просто отслеживать cookie-файлы и сторонние cookie-файлы для проверки истории браузера пользователя. Это считается незаконным правительством. Cookies также могут быть использованы для сохранения форм и паролей. Обратите внимание, что когда вы начинаете вводить адрес электронной почты, он автоматически показывает вам варианты адресов электронной почты, ранее вошедших в систему. Если вы сохраните пароль, файлы cookie также автоматически сохранят пароль и сохранят вашу регистрацию на веб-сайте. Существуют различные типы файлов cookie: файлы cookie сеанса, постоянные файлы cookie, защищенные файлы cookie, файлы cookie HttpOnly, файлы cookie сторонних производителей, файлы cookie Supercookie и файлы зомби.

Сеансы — это полупостоянный интерактивный обмен информацией между двумя взаимодействующими устройствами, такими как пользовательский компьютер и сервер. Это также называется диалогом, беседой или встречей между двумя или более устройствами. Сессия — это, по сути, общение, которое устанавливается в одной точке и разрывается в другой точке. Во время сеанса устройство отправляет информацию туда и обратно. Сеансы также хранятся на сервере-компьютере, что означает, что клиентские компьютеры не имеют к нему доступа. В сеансах данные хранятся с обеих сторон. Файл cookie на стороне клиента хранит только ссылочный номер данных, хранящихся на сервере.

Во время сеанса, когда клиент входит на веб-сайт, cookie-файл на стороне клиента отправляет данные в cookie-файл на стороне сервера, который затем загружает данные, сохраненные клиентом. Например: если пользователь заходит на сайт Macy, создает профиль и добавляет вещи в свою корзину. Когда человек снова войдет в систему, профиль будет таким, каким он его создал, и элементы, добавленные в корзину, все еще будут там. Так работает сессия. Сеансы обычно являются краткосрочными и могут быть сорваны после отмены браузера. Например: если пользователь входит в свою учетную запись gmail и случайно продолжает открывать страницы, он все равно будет зарегистрирован в своей учетной записи. Если они откажутся от браузера и через некоторое время получат доступ к Gmail, они автоматически выйдут из системы. Это было потому, что сессия была закончена.

Хотя сеансы и файлы cookie являются обоими способами хранения информации на веб-страницах, они различаются по способу доступа к информации. Файлы cookie хранятся только на клиентском компьютере, а сеансы хранятся на обоих. Файлы cookie также используются для сохранения паролей и данных форм в браузере, поэтому пользователю не требуется входить в систему. Файлы cookie также считаются менее безопасными по сравнению с сеансами.