Set 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 и другие методы собственного воссоздания в случае, если обнаружено их отсутствие.
setcookie
(PHP 4, PHP 5, PHP 7, PHP 8)
setcookie — Отправляет cookie
Описание
Альтернативная сигнатура доступна с PHP 7.3.0:
Список параметров
(Под)домен, которому доступны cookie. Задание поддомена (например, ‘www.example.com’ ) сделает cookie доступными в нем и во всех его поддоменах (например, w2.www.example.com). Для того, чтобы сделать cookie доступными для всего домена (включая поддомены), нужно просто указать имя домена (то есть ‘example.com’ ).
Возвращаемые значения
Список изменений
Примеры
Ниже представлено несколько примеров, как отправлять cookie:
Пример #1 Пример использования setcookie()
Пример #2 Пример удаления cookie посредством setcookie()
Чтобы удалить cookie достаточно в качестве срока действия указать какое-либо время в прошлом. Это запустит механизм браузера, удаляющий истёкшие cookie. В примерах ниже показано, как удалить cookie, заданные в предыдущих примерах:
Пример #3 setcookie() и массивы
Имеется возможность помещать в cookie массивы. Для этого каждому cookie нужно дать имя в соответствии с правилами именования массивов. Такая возможность позволяет поместить столько значений, сколько имеется элементов в массиве. При обратном получении все эти значения будут помещены в массив с именем этого cookie:
Результат выполнения данного примера:
Замечание: Использование разделительных символов, таких как [ и ] как часть имени файла cookie, не соответствует RFC 6265, раздел 4, но предполагается, что оно поддерживается пользовательскими агентами в соответствии с RFC 6265, раздел 5.
Примечания
Чтобы иметь возможность отправлять вывод скрипта до вызова этой функции, можно воспользоваться буферизацией. В этом случае весь вывод скрипта помещается в буфер на сервере и остаётся там, пока вы явно не отправите его браузеру. Управление буферизацией осуществляется функциями ob_start() и ob_end_flush() в скрипте, либо можно задать директиву output_buffering в файле php.ini или конфигурационных файлах сервера.
При многократных вызовах setcookie() функции выполняются в том порядке, в котором вызывались.
Set-Cookie
BCD tables only load in the browser
HTTP заголовок Set-Cookie используется для отправки cookies с сервера на агент пользователя.
Для детальной информации, смотрите руководство по HTTP cookies.
Максимальное время жизни cookie в формате метки даты-времени HTTP. См. Date о деталях формата Если не определён, cookie будет иметь время жизни сессионного cookie. Сессия окончена, когда клиент отключается, что приводит к удалению сессионных cookie в этот момент. Однако, многие браузеры имеют возможность, называемую восстановление сессии, которая сохраняет все ваши вкладки и затем возвращает их, когда вы в следующий раз запускаете браузер. Cookies будут также присутствовать, словно вы никогда не закрывали браузер.
Когда устанавливается срок действия, время и дата устанавливаются не относительно сервера, а относительно клиента, на котором установлено cookie,
Max-Age= Необязательный Количество секунд, после которого cookie устаревает. Ноль или отрицательное число приводят к моментальному устареванию cookie. Старые браузеры (ie6, ie7, and ie8) не поддерживают Max-Age. Для прочих браузеров, если оба параметра ( Expires and Max-Age ) установлены, Max-Age будет иметь преимущество. Domain= Необязательный Хост, на который будут отправляться cookie.
Cookie не будет дополнительно шифроваться, поэтому в нем не стоит хранить конфиденциальную информацию.
Note: небезопасные сайты ( http: ) не могут использовать cookie с атрибутом «secure» (начиная с Chrome 52+ и Firefox 52+).
Allows servers to assert that a cookie ought not to be sent along with cross-site requests, which provides some protection against cross-site request forgery attacks (CSRF).
Вместо истечения срока действия, когда клиент закрыт, срок действия постоянных файлов cookie истекает в определённую дату ( Expires ) или по истечении определённого промежутка времени ( Max-Age ).
Файл cookie, принадлежащий домену, который не включает исходный сервер, должен быть отклонён пользовательским. Следующий cookie будет отклонён, если он был установлен сервером, размещённым на originalcompany.com.
Cookies names with the prefixes __Secure- and __Host- can be used only if they are set with the secure directive from a secure (HTTPS) origin. In addition, cookies with the __Host- prefix must have a path of «/» (the entire host) and must not have a domain attribute. For clients that don’t implement cookie prefixes, you cannot count on having these additional assurances and the cookies will always be accepted.
setcookie — Посылает cookie
Описание
Список параметров
Можно заметить, что expire принимает в качестве значения метку времени Unix, а хранит его в формате Wdy, DD-Mon-YYYY HH:MM:SS GMT. PHP делает внутреннее преобразование автоматически.
Домен, которому доступны cookie. Задание домена ‘www.example.com’ сделает cookie доступными в поддомене www и поддоменах более высоких порядков. Cookie доступные низким уровням, таким как ‘example.com’, будут доступны во всех поддоменах высших уровней, с том числе ‘www.example.com’. Старые броузеры, следующие устаревшим нормативам » RFC 2109, могут требовать . перед доменом, чтобы включались все поддомены.
Возвращаемые значения
Примеры
Ниже представлено несколько примеров, как отправлять cookie:
Пример #1 Пример использования setcookie()
Стоит отметить, что значение cookie перед отправкой клиенту подвергается URL-кодированию. При обратном получении значение cookie декодируется и помещается в переменную, с тем же именем, что и имя cookie. Если вы не хотите, чтобы значения кодировались, используйте функцию setrawcookie() (работает в PHP 5). Посмотреть содержимое наших тестовых cookie можно, запустив один из следующих примеров:
Пример #2 Пример удаления cookie посредством setcookie()
Чтобы удалить cookie достаточно в качестве срока действия указать какое-либо время в прошлом. Это запустит механизм броузера, удаляющий истекшие cookie. В примерах ниже показано, как удалить cookie, заданные в предыдущих примерах:
Пример #3 setcookie() и массивы
Имеется возможность помещать в cookie массивы. Для этого каждому cookie нужно дать имя в соответствии с правилами именования массивов. Такая возможность позволяет поместить столько значений, сколько имеется элементов в массиве. При обратном получении все эти значения будут помещены в массив с именем этого cookie:
Результат выполнения данного примера:
Список изменений
Примечания
Чтобы иметь возможность отправлять вывод скрипта до вызова этой функции, можно воспользоваться буферизацией. В этом случае весь вывод скрипта помещается в буфер на сервере и остается там, пока вы явно не отправите его броузеру. Управление буферизацией осуществляется функциями ob_start() и ob_end_flush() в скрипте, либо можно задать директиву output_buffering в файле php.ini или конфигурационных файлах сервера.
При многократных вызовах setcookie() функции выполняются в том порядке, в котором вызывались.
Куки, document.cookie
Куки – это небольшие строки данных, которые хранятся непосредственно в браузере. Они являются частью HTTP-протокола, определённого в спецификации RFC 6265.
Один из наиболее частых случаев использования куки – это аутентификация:
Куки имеют множество особенностей и тонкостей в использовании, и в этой главе мы подробно с ними разберёмся.
Чтение из document.cookie
Хранит ли ваш браузер какие-то куки с этого сайта? Посмотрим:
Оставим эту задачу читателю для самостоятельного выполнения. Кроме того, в конце этой главы вы найдёте полезные функции для работы с куки.
Запись в document.cookie
Запись в document.cookie обновит только упомянутые в ней куки, но при этом не затронет все остальные.
Например, этот вызов установит куки с именем user и значением John :
Технически, и имя и значение куки могут состоять из любых символов, для правильного форматирования следует использовать встроенную функцию encodeURIComponent :
Существует несколько ограничений:
У куки есть ряд настроек, многие из которых важны и должны быть установлены.
URL-префикс пути, куки будут доступны для страниц под этим путём. Должен быть абсолютным. По умолчанию используется текущий путь.
domain
Домен, на котором доступны наши куки. На практике, однако, есть ограничения – мы не можем указать здесь какой угодно домен.
Это ограничение безопасности, чтобы мы могли хранить в куки конфиденциальные данные, предназначенные только для одного сайта.
…Однако, если мы всё же хотим дать поддоменам типа forum.site.com доступ к куки, это можно сделать. Достаточно при установке куки на сайте site.com в качестве значения опции domain указать корневой домен: domain=site.com :
По историческим причинам установка domain=.site.com (с точкой перед site.com ) также работает и разрешает доступ к куки для поддоменов. Это старая запись, но можно использовать и её, если нужно, чтобы поддерживались очень старые браузеры.
Таким образом, опция domain позволяет нам разрешить доступ к куки для поддоменов.
expires, max-age
По умолчанию, если куки не имеют ни одного из этих параметров, то они удалятся при закрытии браузера. Такие куки называются сессионными («session cookies»).
Дата истечения срока действия куки, когда браузер удалит его автоматически.
Если мы установим в expires прошедшую дату, то куки будет удалено.
Если задан ноль или отрицательное значение, то куки будет удалено:
secure
Куки следует передавать только по HTTPS-протоколу.
То есть, куки, по умолчанию, опираются на доменное имя, они не обращают внимания на протоколы.
samesite
Это ещё одна настройка безопасности, применяется для защиты от так называемой XSRF-атаки (межсайтовая подделка запроса).
Чтобы понять, как настройка работает и где может быть полезной, посмотрим на XSRF-атаки.
Атака XSRF
Такая атака называется межсайтовая подделка запроса (или Cross-Site Request Forgery, XSRF).
Конечно же, в реальной жизни банки защищены от такой атаки. Во всех сгенерированных сайтом bank.com формах есть специальное поле, так называемый «токен защиты от xsrf», который вредоносная страница не может ни сгенерировать, ни каким-либо образом извлечь из удалённой страницы (она может отправить форму туда, но не может получить данные обратно). И сайт bank.com при получении формы проверяет его наличие.
Но такая защита требует усилий на её реализацию: нам нужно убедиться, что в каждой форме есть поле с токеном, также мы должны проверить все запросы.
Настройка samesite
Параметр куки samesite предоставляет ещё один способ защиты от таких атак, который (теоретически) не должен требовать «токенов защиты xsrf».
У него есть два возможных значения:
Куки с samesite=strict никогда не отправятся, если пользователь пришёл не с этого же сайта.
Другими словами, если пользователь переходит по ссылке из почты, отправляет форму с evil.com или выполняет любую другую операцию, происходящую с другого домена, то куки не отправляется.
Хотя есть небольшие неудобства.
Это более мягкий вариант, который также защищает от XSRF и при этом не портит впечатление от использования сайта.
Куки с samesite=lax отправляется, если два этих условия верны:
Используются безопасные HTTP-методы (например, GET, но не POST).
Полный список безопасных HTTP-методов можно посмотреть в спецификации RFC7231. По сути, безопасными считаются методы, которые обычно используются для чтения, но не для записи данных. Они не должны выполнять никаких операций на изменение данных. Переход по ссылке является всегда GET-методом, то есть безопасным.
Операция осуществляет навигацию верхнего уровня (изменяет URL в адресной строке браузера).
Но что-то более сложное, например, сетевой запрос с другого сайта или отправка формы, теряет куки.
В целом, samesite отличная настройка, но у неё есть важный недостаток:
Но мы, безусловно, можем использовать samesite вместе с другими методами защиты, такими как XSRF-токены, чтобы добавить дополнительный слой защиты, а затем, в будущем, когда старые браузеры полностью исчезнут, мы, вероятно, сможем полностью удалить XSRF-токены.
httpOnly
Эта настройка не имеет ничего общего с JavaScript, но мы должны упомянуть её для полноты изложения.
Эта настройка используется в качестве меры предосторожности от определённых атак, когда хакер внедряет свой собственный JavaScript-код в страницу и ждёт, когда пользователь посетит её. Это вообще не должно быть возможным, хакер не должен быть в состоянии внедрить свой код на ваш сайт, но могут быть ошибки, которые позволят хакеру сделать это.
Приложение: Функции для работы с куки
Для этого существует множество библиотек, так что они, скорее, в демонстрационных целях. Но при этом полностью рабочие.
getCookie(name)
Самый короткий способ получить доступ к куки – это использовать регулярные выражения.
Функция getCookie(name) возвращает куки с указанным name :
Обратите внимание, значение куки кодируется, поэтому getCookie использует встроенную функцию decodeURIComponent для декодирования.
setCookie(name, value, options)
deleteCookie(name)
Чтобы удалить куки, мы можем установить отрицательную дату истечения срока действия:
Обратите внимание: когда мы обновляем или удаляем куки, нам следует использовать только такие же настройки пути и домена, как при установке куки.
Приложение: Сторонние куки
Куки называются сторонними, если они размещены с домена, отличающегося от страницы, которую посещает пользователь.
В следующий раз при доступе к ads.com удалённый сервер получит куки id и распознает пользователя:
Сторонние куки в силу своей специфики обычно используются для целей отслеживания посещаемых пользователем страниц и показа рекламы. Они привязаны к исходному домену, поэтому ads.com может отслеживать одного и того же пользователя на разных сайтах, если оттуда идёт обращение к нему.
Естественно, некоторым пользователям не нравится, когда их отслеживают, поэтому браузеры позволяют отключать такие куки.
Кроме того, некоторые современные браузеры используют специальные политики для таких куки:
Если мы загружаем скрипт со стороннего домена, например