Как удалить токен из куки js

Куки, document.cookie

Куки – это небольшие строки данных, которые хранятся непосредственно в браузере. Они являются частью HTTP-протокола, определённого в спецификации RFC 6265.

Куки обычно устанавливаются веб-сервером при помощи заголовка Set-Cookie . Затем браузер будет автоматически добавлять их в (почти) каждый запрос на тот же домен при помощи заголовка Cookie .

Один из наиболее частых случаев использования куки – это аутентификация:

При входе на сайт сервер отсылает в ответ HTTP-заголовок Set-Cookie для того, чтобы установить куки со специальным уникальным идентификатором сессии («session identifier»).
Во время следующего запроса к этому же домену браузер посылает на сервер HTTP-заголовок Cookie .
Таким образом, сервер понимает, кто сделал запрос.

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

Куки имеют множество особенностей и тонкостей в использовании, и в этой главе мы подробно с ними разберёмся.

Чтение из document.cookie

Хранит ли ваш браузер какие-то куки с этого сайта? Посмотрим:

// На javascript.info мы используем сервис Google Analytics для сбора статистики, // поэтому какие-то куки должны быть alert( document.cookie ); // cookie1=value1; cookie2=value2;.

Значение document.cookie состоит из пар ключ=значение , разделённых ; . Каждая пара представляет собой отдельное куки.

Чтобы найти определённое куки, достаточно разбить строку из document.cookie по ; , и затем найти нужный ключ. Для этого мы можем использовать как регулярные выражения, так и функции для обработки массивов.

Оставим эту задачу читателю для самостоятельного выполнения. Кроме того, в конце этой главы вы найдёте полезные функции для работы с куки.

Запись в document.cookie

Мы можем писать в document.cookie . Но это не просто свойство данных, а акcессор (геттер/сеттер). Присваивание к нему обрабатывается особым образом.

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

Например, этот вызов установит куки с именем user и значением John :

document.cookie = "user=John"; // обновляем только куки с именем 'user' alert(document.cookie); // показываем все куки

Если вы запустите этот код, то, скорее всего, увидите множество куки. Это происходит, потому что операция document.cookie= перезапишет не все куки, а лишь куки с вышеупомянутым именем user .

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

// специальные символы (пробелы), требуется кодирование let name = "my name"; let value = "John Smith" // кодирует в my%20name=John%20Smith document.cookie = encodeURIComponent(name) + '=' + encodeURIComponent(value); alert(document.cookie); // . ; my%20name=John%20Smith

Ограничения

Существует несколько ограничений:

После encodeURIComponent пара name=value не должна занимать более 4Кб. Таким образом, мы не можем хранить в куки большие данные.
Общее количество куки на один домен ограничивается примерно 20+. Точное ограничение зависит от конкретного браузера.

У куки есть ряд настроек, многие из которых важны и должны быть установлены.

Эти настройки указываются после пары ключ=значение и отделены друг от друга разделителем ; , вот так:

document.cookie = "user=John; path=/; expires=Tue, 19 Jan 2038 03:14:07 GMT"

path

URL-префикс пути, куки будут доступны для страниц под этим путём. Должен быть абсолютным. По умолчанию используется текущий путь.

Если куки установлено с path=/admin , то оно будет доступно на страницах /admin и /admin/something , но не на страницах /home или /adminpage .

Как правило, указывают в качестве пути корень path=/ , чтобы наше куки было доступно на всех страницах сайта.

domain

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

Нет никакого способа разрешить доступ к файлам куки из другого домена 2-го уровня, поэтому other.com никогда не получит куки, установленный по адресу site.com .

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

По умолчанию куки доступны лишь тому домену, который его установил.

Пожалуйста, обратите внимание, что по умолчанию файл куки также не передаётся поддомену, например forum.site.com .

// если мы установим файл куки на веб-сайте site.com. document.cookie = "user=John" // . мы не увидим его на forum.site.com alert(document.cookie); // нет user

…Но это можно изменить. Если мы хотим разрешить поддоменам типа forum.site.com получать куки, установленные на site.com , это возможно.

Чтобы это произошло, при установке файла куки в site.com , мы должны явно установить параметр domain для корневого домена: domain=site.com . После этого все поддомены увидят такой файл cookie.

// находясь на странице site.com // сделаем куки доступным для всех поддоменов *.site.com: document.cookie = "user=John; domain=site.com" // позже // на forum.site.com alert(document.cookie); // есть куки user=John

По историческим причинам установка domain=.site.com (с точкой перед site.com ) также работает и разрешает доступ к куки для поддоменов. Это старая запись, но можно использовать и её, если нужно, чтобы поддерживались очень старые браузеры.

Таким образом, опция domain позволяет нам разрешить доступ к куки для поддоменов.

expires, max-age

По умолчанию, если куки не имеют ни одного из этих параметров, то они удалятся при закрытии браузера. Такие куки называются сессионными («session cookies»).

Чтобы помочь куки «пережить» закрытие браузера, мы можем установить значение опций expires или max-age .

expires=Tue, 19 Jan 2038 03:14:07 GMT

Дата истечения срока действия куки, когда браузер удалит его автоматически.

Дата должна быть точно в этом формате, во временной зоне GMT. Мы можем использовать date.toUTCString , чтобы получить правильную дату. Например, мы можем установить срок действия куки на 1 день.

// +1 день от текущей даты let date = new Date(Date.now() + 86400e3); date = date.toUTCString(); document.cookie = "user=John; expires=" + date;

Если мы установим в expires прошедшую дату, то куки будет удалено.

Альтернатива expires , определяет срок действия куки в секундах с текущего момента.

Если задан ноль или отрицательное значение, то куки будет удалено:

// куки будет удалено через 1 час document.cookie = "user=John; max-age=3600"; // удалим куки (срок действия истекает прямо сейчас) document.cookie = "user=John; max-age=0";

secure

Куки следует передавать только по HTTPS-протоколу.

По умолчанию куки, установленные сайтом http://site.com , также будут доступны на сайте https://site.com и наоборот.

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

С этой настройкой, если куки будет установлено на сайте https://site.com , то оно не будет доступно на том же сайте с протоколом HTTP, как http://site.com . Таким образом, если в куки хранится конфиденциальная информация, которую не следует передавать по незашифрованному протоколу HTTP, то нужно установить этот флаг.

// предполагается, что сейчас мы на https:// // установим опцию secure для куки (куки доступно только через HTTPS) document.cookie = "user=John; secure";

samesite

Это ещё одна настройка безопасности, применяется для защиты от так называемой XSRF-атаки (межсайтовая подделка запроса).

Чтобы понять, как настройка работает и где может быть полезной, посмотрим на XSRF-атаки.

Атака XSRF

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

Теперь, просматривая веб-страницу в другом окне, вы случайно переходите на сайт evil.com , который автоматически отправляет форму на сайт bank.com с заполненными полями, которые инициируют транзакцию на счёт хакера.

Браузер посылает куки при каждом посещении bank.com , даже если форма была отправлена с evil.com . Таким образом, банк узнает вас и выполнит платёж.

Такая атака называется межсайтовая подделка запроса (или Cross-Site Request Forgery, XSRF).

Конечно же, в реальной жизни банки защищены от такой атаки. Во всех сгенерированных сайтом bank.com формах есть специальное поле, так называемый «токен защиты от xsrf», который вредоносная страница не может ни сгенерировать, ни каким-либо образом извлечь из удалённой страницы (она может отправить форму туда, но не может получить данные обратно). И сайт bank.com при получении формы проверяет его наличие.

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

Настройка samesite

Параметр куки samesite предоставляет ещё один способ защиты от таких атак, который (теоретически) не должен требовать «токенов защиты xsrf».

У него есть два возможных значения:

samesite=strict (или, что то же самое, samesite без значения)

Куки с samesite=strict никогда не отправятся, если пользователь пришёл не с этого же сайта.

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

Если куки имеют настройку samesite , то атака XSRF не имеет шансов на успех, потому что отправка с сайта evil.com происходит без куки. Таким образом, сайт bank.com не распознает пользователя и не произведёт платёж.

Защита довольно надёжная. Куки с настройкой samesite будет отправлено только в том случае, если операции происходят с сайта bank.com , например отправка формы сделана со страницы на bank.com .

Хотя есть небольшие неудобства.

Когда пользователь перейдёт по ссылке на bank.com , например из своих заметок, он будет удивлён, что сайт bank.com не узнал его. Действительно, куки с samesite=strict в этом случае не отправляется.

Мы могли бы обойти это ограничение, используя два куки: одно куки для «общего узнавания», только для того, чтобы поздороваться: «Привет, Джон», и другое куки для операций изменения данных с samesite=strict . Тогда пользователь, пришедший на сайт, увидит приветствие, но платежи нужно инициировать с сайта банка, чтобы отправилось второе куки.

Это более мягкий вариант, который также защищает от XSRF и при этом не портит впечатление от использования сайта.

Режим Lax так же, как и strict , запрещает браузеру отправлять куки, когда запрос происходит не с сайта, но добавляет одно исключение.

Куки с samesite=lax отправляется, если два этих условия верны:

Используются безопасные HTTP-методы (например, GET, но не POST). Полный список безопасных HTTP-методов можно посмотреть в спецификации RFC7231. По сути, безопасными считаются методы, которые обычно используются для чтения, но не для записи данных. Они не должны выполнять никаких операций на изменение данных. Переход по ссылке является всегда GET-методом, то есть безопасным.
Операция осуществляет навигацию верхнего уровня (изменяет URL в адресной строке браузера). Обычно это так, но если навигация выполняется в , то это не верхний уровень. Кроме того, JavaScript-методы для сетевых запросов не выполняют никакой навигации, поэтому они не подходят.

Таким образом, режим samesite=lax , позволяет самой распространённой операции «переход по ссылке» передавать куки. Например, открытие сайта из заметок удовлетворяет этим условиям.

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

Если это вам подходит, то добавление samesite=lax , скорее всего, не испортит впечатление пользователей от работы с сайтом и добавит защиту.

В целом, samesite отличная настройка.

Но у неё есть важный недостаток:

samesite игнорируется (не поддерживается) старыми браузерами, выпущенными до 2017 года и ранее.

Так что, если мы будем полагаться исключительно на samesite , то старые браузеры будут уязвимы.

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

httpOnly

Эта настройка не имеет ничего общего с JavaScript, но мы должны упомянуть её для полноты изложения.

Веб-сервер использует заголовок Set-Cookie для установки куки. И он может установить настройку httpOnly .

Эта настройка запрещает любой доступ к куки из JavaScript. Мы не можем видеть такое куки или манипулировать им с помощью document.cookie .

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

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

Но если куки имеет настройку httpOnly , то document.cookie не видит его, поэтому такое куки защищено.

Приложение: Функции для работы с куки

Вот небольшой набор функций для работы с куки, более удобных, чем ручная модификация document.cookie .

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

getCookie(name)

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

Функция getCookie(name) возвращает куки с указанным name :

// возвращает куки с указанным name, // или undefined, если ничего не найдено function getCookie(name) < let matches = document.cookie.match(new RegExp( "(?:^|; )" + name.replace(/([\.$?*|<>\(\)\[\]\\\/\+^])/g, '\\$1') + "=([^;]*)" )); return matches ? decodeURIComponent(matches[1]) : undefined; >

Здесь new RegExp генерируется динамически, чтобы находить ; name= .

Обратите внимание, значение куки кодируется, поэтому getCookie использует встроенную функцию decodeURIComponent для декодирования.

setCookie(name, value, options)

Устанавливает куки с именем name и значением value , с настройкой path=/ по умолчанию (можно изменить, чтобы добавить другие значения по умолчанию):

function setCookie(name, value, options = <>) < options = < path: '/', // при необходимости добавьте другие значения по умолчанию . options >; if (options.expires instanceof Date) < options.expires = options.expires.toUTCString(); >let updatedCookie = encodeURIComponent(name) + "=" + encodeURIComponent(value); for (let optionKey in options) < updatedCookie += "; " + optionKey; let optionValue = options[optionKey]; if (optionValue !== true) < updatedCookie += "=" + optionValue; >> document.cookie = updatedCookie; > // Пример использования: setCookie('user', 'John', );

deleteCookie(name)

Чтобы удалить куки, мы можем установить отрицательную дату истечения срока действия:

function deleteCookie(name) < setCookie(name, "", < 'max-age': -1 >) >

Операции обновления или удаления куки должны использовать те же путь и домен

Обратите внимание: когда мы обновляем или удаляем куки, нам следует использовать только такие же настройки пути и домена, как при установке куки.

Приложение: Сторонние куки

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

Страница site.com загружает баннер с другого сайта: .
Вместе с баннером удалённый сервер ads.com может установить заголовок Set-Cookie с куки, например, id=1234 . Такие куки создаются с домена ads.com и будут видны только на сайте ads.com :

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

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

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

Safari вообще не разрешает сторонние куки.
У Firefox есть «чёрный список» сторонних доменов, чьи сторонние куки он блокирует.

На заметку:

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

Если скрипт устанавливает куки, то нет разницы откуда был загружен скрипт – куки принадлежит домену текущей веб-страницы.

Приложение: GDPR

Эта тема вообще не связана с JavaScript, но следует её иметь в виду при установке куки.

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

Обратите внимание, это относится только к куки, используемым для отслеживания/идентификации/авторизации.

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

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

Есть два основных варианта как сайты следуют GDPR. Вы наверняка уже видели их в сети:

Если сайт хочет установить куки для отслеживания только для авторизованных пользователей. То в регистрационной форме должен быть установлен флажок «принять политику конфиденциальности» (которая определяет, как используются куки), пользователь должен установить его, и только тогда сайт сможет использовать авторизационные куки.
Если сайт хочет установить куки для отслеживания всем пользователям. Чтобы сделать это законно, сайт показывает модальное окно для пользователей, которые зашли в первый раз, и требует от них согласие на использование куки. Затем сайт может установить такие куки и показать пользователю содержимое страницы. Хотя это создаёт неудобства для новых посетителей – никому не нравится наблюдать модальные окна вместо контента. Но GDPR в данной ситуации требует явного согласия пользователя.

GDPR касается не только куки, но и других вопросов, связанных с конфиденциальностью, которые выходят за рамки материала этой главы.

Итого

document.cookie предоставляет доступ к куки.

Операция записи изменяет только то куки, которое было указано.
Имя и значение куки должны быть закодированы.
Одно куки вмещает до 4kb данных, разрешается более 20 куки на сайт (зависит от браузера).

path=/ , по умолчанию устанавливается текущий путь, делает куки видимым только по указанному пути и ниже.
domain=site.com , по умолчанию куки видно только на текущем домене, если явно указан домен, то куки видно и на поддоменах.
expires или max-age устанавливает дату истечения срока действия, без них куки умрёт при закрытии браузера.
secure делает куки доступным только при использовании HTTPS.
samesite запрещает браузеру отправлять куки с запросами, поступающими извне, помогает предотвратить XSRF-атаки.

Сторонние куки могут быть запрещены браузером, например Safari делает это по умолчанию.
Установка отслеживающих куки пользователям из стран ЕС требует их явного согласия на это в соответствии с законодательством GDPR.

.cookie

Единственный доступ в банку с оставленными сервером печеньками.

Время чтения: 5 мин

Открыть/закрыть навигацию по статье

Обновлено 4 ноября 2022

Cookie — один из способов хранить данные в браузере. Обзор всех способов хранения описан в статье «Хранение данных в браузере».

Кратко

Скопировать ссылку «Кратко» Скопировано

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

Куки передаются в виде HTTP-заголовка, это накладывает на них ограничения. Например, максимальный размер куки в 4096 байт или отсутствие в содержимом пробелов или запятых. Чтобы обезопасить содержимое, можно закодировать его с помощью функции encode U R I Component ( )

Как пользоваться

Скопировать ссылку «Как пользоваться» Скопировано

Все куки хранятся в свойстве document . cookie . Это свойство представляет собой строку в формате имя = значение , где пары имён и значений разделяются знаком ; . При этом взаимодействие с полем весьма необычное — если присвоить document . cookie новое значение, то оно не заменит полностью старую строку, а добавит или изменит значение по ключу.

Запись

Скопировать ссылку «Запись» Скопировано

Запись в cookie работает с помощью присвоения значения новой куки в поле document . cookie . За один раз можно записать лишь одно значение.

Вот так можно добавить значение 1 по ключу counter:

 document.cookie = 'counter=1'console.log(document.cookie)// 'counter=1' document.cookie = 'counter=1' console.log(document.cookie) // 'counter=1'

При присвоении свойству куки с другим именем, получим два записанных значения:

 document.cookie = 'sidebar=false'console.log(document.cookie)// 'counter=1; sidebar=false;' document.cookie = 'sidebar=false' console.log(document.cookie) // 'counter=1; sidebar=false;'

При повторной записи в то же поле другого значения оно будет перезаписано.

 document.cookie = 'sidebar=true'console.log(document.cookie)// -> 'counter=1; sidebar=true;' document.cookie = 'sidebar=true' console.log(document.cookie) // -> 'counter=1; sidebar=true;'

При установке кук можно указывать не только её название и значение, но и другие параметры. Все они являются необязательными и разделяются точкой с запятой ;

path – определяет путь, по которому будет доступна кука. Он должен быть абсолютным, то есть начинаться с / . Если параметр не передан, то кука будет доступна на всех страницах сайта.
domain — определяет домен, для которого указана кука. Если не указано, то будет использоваться текущий домен.
max — age и expires — определяет время жизни куки. max — age указывает, через сколько секунд, а expires указывает точное время, когда кука станет недействительна. Время для expires можно отформатировать с помощью встроенного метода даты Date . toUTC String ( )
secure — указывает, что данная кука может быть передана только при запросах по защищённому протоколу HTTPS.
samesite — определяет, может ли данная кука быть отправлена при кросс-доменном запросе. Значение параметра strict будет предотвращать отправку на другие домены, а lax разрешит отправлять куки с GET-запросами.

Есть пара ограничений при специфичных названиях кук. Если название куки начинается с _ _ Secure — , то обязательно должен быть передан параметр secure . При этом мы должны находиться на странице, которая была получена по HTTPS-протоколу. Если название куки начинается с _ _ Host — , то обязательно должны быть переданы параметры path = / и secure (страница также должна быть открыта по HTTPS-протоколу), а атрибут domain должен отсутствовать для снижения кроссдоменных уязвимостей.

Запись куки с разрешением передавать её только по HTTPS и только для текущего домена, со временем жизни в 1 час будет выглядеть так:

 document.cookie = 'sidebar=true;secure;samesite=strict;max-age=3600' document.cookie = 'sidebar=true;secure;samesite=strict;max-age=3600'

Все возможные параметры установки куки

Для установки куки, которая будет доступна на текущем домене и всех его поддоменах, используйте название текущего домена и поставьте точку в начале – .$

Чтение

Скопировать ссылку «Чтение» Скопировано

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

 console.log(document.cookie); console.log(document.cookie);

Учитывая, что мы уже дважды записывали куки, при вызове команды выше в консоли выведется counter = 1; sidebar = true; .

Чтобы получить значение конкретной куки, нам нужно будет прочитать строки и разобрать её по значениям. Например, так:

 function getCookie()  return document.cookie.split('; ').reduce((acc, item) =>  const [name, value] = item.split('=') acc[name] = value return acc >, <>)> const cookie = getCookie() console.log(cookie.counter)// 1console.log(cookie.sidebar)// true function getCookie()  return document.cookie.split('; ').reduce((acc, item) =>  const [name, value] = item.split('=') acc[name] = value return acc >, >) > const cookie = getCookie() console.log(cookie.counter) // 1 console.log(cookie.sidebar) // true

Удаление

Скопировать ссылку «Удаление» Скопировано

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

 document.cookie = `sidebar=;expires=$` document.cookie = `sidebar=;expires=$new Date(0)>`

В этом примере, передав число 0 в конструктор Date мы получаем время на начало эпохи Unix, а именно 1 января 1970 г. Поскольку эта дата из прошлого, то кука будет удалена моментально.

На практике

Скопировать ссылку «На практике» Скопировано

Павел Минеев советует

Скопировать ссылку «Павел Минеев советует» Скопировано

Есть куки, которые нельзя прочитать или записать из JavaScript. Если сервер устанавливает куки с параметром HttpOnly (доступен только для установки сервером), то такие куки будут недоступны в document . cookie . Как правило, такие куки используются для хранения чувствительной информации, как, например, токены для авторизации. Проверка авторизации происходит с помощью запроса с текущим авторизованным пользователем и считается при успешном ответе сервера.

Игорь Камышев советует

Скопировать ссылку «Игорь Камышев советует» Скопировано

Формат строки document . cookie не очень удобен для работы, поэтому обычно в проекте создают функции, которые упрощают чтение и запись кук. Чтобы не писать эти функции самостоятельно, можно взять библиотеку js-cookie — это совсем небольшая обёртка над стандартным браузерным API, которая здорово упрощает жизнь.

С этой библиотекой установка значения для куки выполняется так:

 import Cookies from "js-cookie"; Cookies.set("foo", "bar"); import Cookies from "js-cookie"; Cookies.set("foo", "bar");

 import Cookies from "js-cookie"; const nameFromCookie = Cookies.get("name"); import Cookies from "js-cookie"; const nameFromCookie = Cookies.get("name");

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

Удалить значение из куки ответом от сервера.

Удаление cookies ответом сервера
Здравствуйте. Для создания cookies в заголовке ответа сервера используем: Set-Cookie: Cookie1=.

Работа с ответом сервера JSON
Как правильно выводить пользователю пришедшие данные? Таким вот образом можно? Или есть способ.

Проблема с ответом от сервера Google для recaptcha
Всем привет. Прошу помощи! Сколько ни разбирался..не получается решить проблемы с работой.

Найти значение выражения, не сходится с ответом
Подскажите пожалуйста где ошибка в формуле, не понимаю почему ответ не сходится. #include<stdio.h>.

Эксперт JS

1586 / 796 / 362
Регистрация: 01.02.2019
Сообщений: 1,047

marginald, вы немного странно записываете куки — обычно параметры передают через объект. А для удаления кук есть же метод clearCookie:

res.clearCookie('token', { secure: true, httpOnly: true });

Регистрация: 24.11.2019
Сообщений: 312

Цитата Сообщение от Iverycool Посмотреть сообщение

res.clearCookie(‘token’, < secure: true, httpOnly: true >);
не помогло, куки не удаляется

1 2 3

let token = await generateAccessToken(user._id, user.email); res.cookie(`token`, `${token}`, {secure: true, httpOnly: true}) res.json({token: token})

1 2 3 4

let cookie = req.cookies['token'] if (typeof cookie !== 'undefined') { console.log('---') res.clearCookie('token', { secure: true, httpOnly: true });

Регистрация: 24.11.2019
Сообщений: 312
на сервер от клиента поступает delete-метод на удаление куки

Эксперт JS

1586 / 796 / 362
Регистрация: 01.02.2019
Сообщений: 1,047

marginald, у меня всё работает, посмотрите ответ сервера во вкладке Network, у него в заголовках должно быть такое поле:

Set-Cookie: token=; Path=/; Expires=Thu, 01 Jan 1970 00:00:00 GMT; HttpOnly; Secure

363 / 262 / 104
Регистрация: 28.08.2013
Сообщений: 610

marginald, Установите в cookie значение Expires на прошедшие дату/время. Такие cookie сервер не добавляет в ответ.

Регистрация: 24.11.2019
Сообщений: 312

Цитата Сообщение от kidASM Посмотреть сообщение

marginald, Установите в cookie значение Expires на прошедшие дату/время. Такие cookie сервер не добавляет в ответ.

пробовал, все равно не получается
Регистрация: 24.11.2019
Сообщений: 312

res.clearCookie('token', {httpOnly: true}); res.status(200).json({message: "OK"})

этот код мне помог, теперь токен удаляется
87844 / 49110 / 22898
Регистрация: 17.06.2006
Сообщений: 92,604
Помогаю со студенческими работами здесь

Достать куки со стороны сервера
Не подскажите,пож-та, а если у нас к примеру есть свой сайт интернет-магазина, как можно достать.

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

Как извлечь куки на стороне сервера
устанавливаю куки async function Authorization(user, req, res) < try < const.

В каком виде передаются куки от сервера пользователю и обратно?
Народ. В каком виде передаются куки от сервера пользователю и обратно? (понимаю, что надо самому.

Удалить куки
как удалить такую куки setcookie(‘userd’,$_SESSION,time()+3600*24*31, "/");

Удалить куки WebBrowser
Собственно сабж. Каким образом можно удалить все куки из WebBrowser?

Set-Cookie

HTTP заголовок Set-Cookie используется для отправки cookies с сервера на агент пользователя.

Для детальной информации, смотрите руководство по HTTP cookies.

Тип заголовка	Response header (en-US)
Forbidden header name	нет

Синтаксис

Set-Cookie: = Set-Cookie: =; Expires= Set-Cookie: =; Max-Age= Set-Cookie: =; Domain= Set-Cookie: =; Path= Set-Cookie: =; Secure Set-Cookie: =; HttpOnly Set-Cookie: =; SameSite=Strict Set-Cookie: =; SameSite=Lax Set-Cookie: =; SameSite=None Экспериментальная возможность  // Multiple directives are also possible, for example: Set-Cookie: =; Domain=; Secure; HttpOnly

Директивы

По умолчанию — хост текущего URL документа, не включая поддомены
В текущей спецификация начальная точка в имени хоста игнорируется ( .example.com )
Cookie будут отправляться также на поддомены указанного хоста
Указывать несколько хостов недопустимо.

По умолчанию — хост текущего URL документа, не включая поддомены
В текущей спецификация начальная точка в имени хоста игнорируется (.example.com)
Cookie будут отправляться также на поддомены указанного хоста
Указывать несколько хостов недопустимо.

Cookie начинается с пары имя-значение:

может содержать любые символы US-ASCII, за исключением управляющих символов (CTLs), пробелов, или табуляций. Оно также не должно содержать разделительных символов, таких как следующие: ( ) < >@ , ; : \ » / [ ] ? = < >.
может быть опционально заключено в двойные кавычки, разрешены любые символы US-ASCII за исключением CTLs, пробела, двойных кавычек, запятой, точки с запятой, и обратного слеша. Кодирование: Многие реализации выполняют кодирование в значениях cookies, однако этого не требуется по спецификации RFC. Однако, это помогает удовлетворить требование о разрешённых символах в .
__Secure- prefix Non-standard : Cookies с именем, начинающимся с __Secure- (подчёркивание является частью префикса ) должны быть установлены вместе с флагом secure, и должны быть с безопасной страницы (HTTPS).
__Host- prefix Non-standard : Cookies с именем, начинающимся с __Host- должны быть установлены с флагом secure secure , должны быть с безопасной страницы (HTTPS), не должны иметь определённый домен (и, следовательно, не не посылаются поддоменами), а также параметр Path должен быть «/».

Максимальное время жизни cookie в формате метки даты-времени HTTP. См. Date о деталях формата Если не определён, cookie будет иметь время жизни сессионного cookie. Сессия окончена, когда клиент отключается, что приводит к удалению сессионных cookie в этот момент. Однако, многие браузеры имеют возможность, называемую восстановление сессии, которая сохраняет все ваши вкладки и затем возвращает их, когда вы в следующий раз запускаете браузер. Cookies будут также присутствовать, словно вы никогда не закрывали браузер.

Когда устанавливается срок действия, время и дата устанавливаются не относительно сервера, а относительно клиента, на котором установлено cookie,

Количество секунд, после которого cookie устаревает. Ноль или отрицательное число приводят к моментальному устареванию cookie. Старые браузеры (ie6, ie7, and ie8) не поддерживают Max-Age. Для прочих браузеров, если оба параметра ( Expires and Max-Age ) установлены, Max-Age будет иметь преимущество.

Хост, на который будут отправляться cookie.

По умолчанию — хост текущего URL документа, не включая поддомены В текущей спецификация начальная точка в имени хоста игнорируется (.example.com) Cookie будут отправляться также на поддомены указанного хоста Указывать несколько хостов недопустимо.

Путь, который должен существовать в запрошенном URL, иначе браузер не отправит заголовок Cookie.

Пример: / — cookie будет отправляться со всеми запросами Пример: /docs/ — cookie будет отправляться с запросами к директории docs и её поддиректориям

Cookie будет отправлен на сервер только с запросами c использованием SSL и протокола HTTPS.

Cookie не будет дополнительно шифроваться, поэтому в нем не стоит хранить конфиденциальную информацию.

Note: небезопасные сайты ( http: ) не могут использовать cookie с атрибутом «secure» (начиная с Chrome 52+ и Firefox 52+).

Запрещает JavaScript доступ к cookie

Полезно для защиты от XSS-атак.

Strict : The browser sends the cookie only for same-site requests (that is, requests originating from the same site that set the cookie). If the request originated from a different URL than the current one, no cookies with the SameSite=Strict attribute are sent.
Lax : The cookie is withheld on cross-site subrequests, such as calls to load images or frames, but is sent when a user navigates to the URL from an external site, such as by following a link
None : The browser sends the cookie with both cross-site and same-site requests

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).

Современные браузеры используют SameSite=Lax . Если необходима работа SameSite=None cookie должна быть установлена с атрибутом Secure .

Примеры

Сессионный cookie

Сессионные cookies будут удалены после отключения клиента. В них не указываются директивы Expires или Max-Age . Учитывайте, что часто в браузере включено восстановление сессии.

Set-Cookie: sessionid=38afes7a8; HttpOnly; Path=/

Постоянный cookie

Вместо истечения срока действия, когда клиент закрыт, срок действия постоянных файлов cookie истекает в определённую дату ( Expires ) или по истечении определённого промежутка времени ( Max-Age ).

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

Неверные домены

Файл cookie, принадлежащий домену, который не включает исходный сервер, должен быть отклонён пользовательским. Следующий cookie будет отклонён, если он был установлен сервером, размещённым на originalcompany.com.

Set-Cookie: qwerty=219ffwef9w0f; Domain=somecompany.co.uk; Path=/; Expires=Wed, 30 Aug 2019 00:00:00 GMT

Cookie prefixes

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.

// Both accepted when from a secure origin (HTTPS) Set-Cookie: __Secure-ID=123; Secure; Domain=example.com Set-Cookie: __Host-ID=123; Secure; Path=/ // Rejected due to missing Secure directive Set-Cookie: __Secure-id=1 // Rejected due to the missing Path=/ directive Set-Cookie: __Host-id=1; Secure // Rejected due to setting a domain Set-Cookie: __Host-id=1; Secure; Path=/; domain=example.com

Specifications

Specification	Title
RFC 6265, секция 4.1: Set-Cookie	HTTP State Management Mechanism
draft-ietf-httpbis-rfc6265bis-02	Cookie Prefixes, Same-Site Cookies, and Strict Secure Cookies

Browser compatibility

BCD tables only load in the browser

Compatibility notes

Starting with Chrome 52 and Firefox 52, insecure sites ( http: ) can’t set cookies with the «secure» directive anymore.