Java document cookie

Работа с куки (cookie) в JavaScript

Учебник JavaScript

Практика

Работа с DOM

Практика

Некоторые продвинутые вещи

Рекомендованное ES6

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

Регулярки

Разное

Работа с канвасом

Практика

• урок исключен (мало материала), по аяксу скоро будет отдельный учебник (много материала)
  Работа с
  AJAX в JavaScript —>
  Работа с
  AJAX + PHP —>

Контекст

Drag-and-Drop

• Урок №
  Введение
  в ООП в стиле ES6
• Урок №
  Основы
  работы с ООП
• Урок №
  Наследование
  классов в JavaScript
  Продвинутая работа
  с классами на JavaScript —>
• Урок №
  Применение
  ООП при работе с DOM
• Урок №
  Практика
  по ООП в JavaScript
• Тут скоро будут еще уроки
  по функциональному и прототипному
  стилю ООП.

Практика по ООП

Ваша задача: посмотрите, попробуйте повторить.

Практика

Promise ES6

Библиотека jQuery

Тк. jQuery устаревает, объявляю эти уроки не обязательными и выношу в конец учебника (так по уровню уроки середины учебника, если что). В перспективе переедет в отдельный учебник по jq.

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

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

Или можно показать пользователю баннер с кнопкой ‘не показывать 1 день’. По нажатию на эту кнопку баннер скрывается, но в куки пишется информация о моменте времени, когда это произошло — и ровно через сутки баннер покажется опять.

Кроме того, с куками можно работать не только из JavaScript, но и из PHP (там это нужно, например, для хранения авторизации пользователя), см. работа с куками на PHP при необходимости.

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

К сожалению, работа с куками в JavaScript реализована просто ужасно и без костылей тут не обойтись, а лучше просто использовать готовые библиотеки.

Итак, давайте приступим.

Основы работы с куками

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

В document.cookie куки хранятся просто в виде строки. Эта строка состоит из пар имя_куки=значение_куки , которые перечисляются через точку с запятой с пробелом ‘; ‘.

Пример: ‘name=Вася; age=25’.

Чтобы записать в куки, нужно просто в document.cookie присвоить куку с ее именем:

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

Если устанавливать куку с тем же именем в разные значения — новое значение будет затирать предыдущее:

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

Получение куки по ее имени

Итак, мы уже определи, что куки хранятся в виде простой строки, например, ‘name=Вася; age=25; salary=1000’. Получается, чтобы найти, к примеру, значение куки с именем age, его нужно достать из это строки каким-нибудь способом: к примеру функциями работы со строками или регулярными выражениями.

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

Давайте попробуем написать регулярку, которая вытягивает значение куки с именем age:

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

Во-первых, в нашей регулярке в конце стоит точка с запятой — разделитель разных кук в document.cookie. Но посмотрим внимательно на нашу строку с куками — ‘name=Вася; age=25; salary=1000’ — у последней куки нету точки с запятой в конце! И наша регулярка эту куку не возьмет.

Нужно ее модифицировать и сказать, что кука заканчивается или точкой с запятой, или концом строки. Модифицируем: /age=(.+?)(;|$)/.

Во-вторых, следует дописать часть регулярки перед именем куки — перед этим именем может быть пробел или начало строки, если кука первая. Допишем: /(^|s)age=(.+?)(;|$)/.

Значение куки может быть пустым, к примеру, если мы в document.cookie записывали вот так: ‘age=’. Учтем это в нашей регулярке — заменим + на *. Заменим: /(^|s)age=(.*?)(;|$)/.

Давайте теперь введем несохраняющие скобки, чтобы не плодить лишних карманов: /(?:^|s)age=(.*?)(?:;|$)/.

А теперь давайте реализуем функцию getCookie(), которая параметром будет принимать имя произвольной куки и возвращать ее значение. Вот эта функция:

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

С учетом этого исправления получим следующее:

Теперь разберемся с matches[1]. Если кука существует — все хорошо, а вот если не существует — давайте вернем undefined:

Перепишем этот if в сокращенный вариант:

С учетом исправления получим следующий код:

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

Это и есть готовая функция для получения нужной вам куки (взята отсюда learn.javascript.ru/cookie, я просто чуть подправил регулярку и объяснил как она работает).

Дополнительные настройки кук

Это еще не все: у кук есть дополнительные настройки, которые чаще всего желательно указать.

Эти настройки указываются после пары ключ=значение, каждое – после точки с запятой. Как-то так:

Папка установки

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

Например: ваш сайт site.ru и вы, находясь на странице site.ru/folder/ установили куку. Так вот: эта кука будет доступна на странице site.ru/folder/, на странице site.ru/folder/subfolder/ и так далее, но не будет доступна, к примеру на странице site.ru/somefolder/.

Это очень неожиданное поведение. Чтобы исправить его существует настройка path. Обычно она используется так: path=/ — и кука устанавливается на всем сайте. Пример:

Можно указать и конкретную папку, например path=/folder:

Домен установки

Следующая настройка domain задает домен, для которого установлена кука. По умолчанию это текущий домен (но не его поддомены). Можно указать, что кука доступна именно на поддомене. К примеру, наш домен site.ru, а куку мы установим для forum.site.ru:

Если указать специальную маску .site.ru, то кука будет доступна на сайте и всех его поддоменах:

Время жизни

Все куки живут только определенное время. По умолчанию куки живут очень не долго — всего лишь до закрытия браузера. Чаще всего нас это не устраивает и мы хотели бы сделать куки более долгоживущими.

Для этого применяется настройка expires, в которую следует задавать момент времени, до которого живет кука. Этот момент устанавливается в формате GMT. Этот формат можно получить так: используем объект Date, устанавливаем в любое время, а потом вызываем метод toUTCString.

Давайте установим время жизни куки +1 день от текущего момента:

Удаление кук

Куки удаляются интересным образом: нужно установить время их жизни в прошедшее время, ну или просто поставить его как -1. Давайте удалим нашу куку:

Библиотеки для работы с куками

Так как работа с куками в JavaScript реализована просто ужасно, существуют библиотеки, которые упрощают работу с ними. Изучите эти библиотеки самостоятельно: куки на чистом JavaScript и плагин jQuery.

Что вам делать дальше:

Приступайте к решению задач по следующей ссылке: задачи к уроку.

Когда все решите — переходите к изучению новой темы.

Cookies, document.cookie

Cookies are small strings of data that are stored directly in the browser. They are a part of HTTP protocol, defined by RFC 6265 specification.

Cookies are usually set by a web-server using response Set-Cookie HTTP-header. Then the browser automatically adds them to (almost) every request to the same domain using Cookie HTTP-header.

One of the most widespread use cases is authentication:

1. Upon sign in, the server uses Set-Cookie HTTP-header in the response to set a cookie with a unique “session identifier”.
2. Next time when the request is set to the same domain, the browser sends the cookie over the net using Cookie HTTP-header.
3. So the server knows who made the request.

We can also access cookies from the browser, using document.cookie property.

There are many tricky things about cookies and their options. In this chapter we’ll cover them in detail.

Reading from document.cookie

Does your browser store any cookies from this site? Let’s see:

The value of document.cookie consists of name=value pairs, delimited by ; . Each one is a separate cookie.

To find a particular cookie, we can split document.cookie by ; , and then find the right name. We can use either a regular expression or array functions to do that.

We leave it as an exercise for the reader. Also, at the end of the chapter you’ll find helper functions to manipulate cookies.

Writing to document.cookie

We can write to document.cookie . But it’s not a data property, it’s an accessor (getter/setter). An assignment to it is treated specially.

A write operation to document.cookie updates only cookies mentioned in it, but doesn’t touch other cookies.

For instance, this call sets a cookie with the name user and value John :

If you run it, then probably you’ll see multiple cookies. That’s because document.cookie= operation does not overwrite all cookies. It only sets the mentioned cookie user .

Technically, name and value can have any characters, to keep the valid formatting they should be escaped using a built-in encodeURIComponent function:

There are few limitations:

• The name=value pair, after encodeURIComponent , should not exceed 4kb. So we can’t store anything huge in a cookie.
• The total number of cookies per domain is limited to around 20+, the exact limit depends on a browser.

Cookies have several options, many of them are important and should be set.

The options are listed after key=value , delimited by ; , like this:

• path=/mypath

The url path prefix, the cookie will be accessible for pages under that path. Must be absolute. By default, it’s the current path.

If a cookie is set with path=/admin , it’s visible at pages /admin and /admin/something , but not at /home or /adminpage .

Usually, we should set path to the root: path=/ to make the cookie accessible from all website pages.

domain

• domain=site.com

A domain where the cookie is accessible. In practice though, there are limitations. We can’t set any domain.

By default, a cookie is accessible only at the domain that set it. So, if the cookie was set by site.com , we won’t get it other.com .

…But what’s more tricky, we also won’t get the cookie at a subdomain forum.site.com !

There’s no way to let a cookie be accessible from another 2nd-level domain, so other.com will never receive a cookie set at site.com .

It’s a safety restriction, to allow us to store sensitive data in cookies, that should be available only on one site.

…But if we’d like to allow subdomains like forum.site.com get a cookie, that’s possible. When setting a cookie at site.com , we should explicitly set domain option to the root domain: domain=site.com :

For historical reasons, domain=.site.com (a dot before site.com ) also works the same way, allowing access to the cookie from subdomains. That’s an old notation, should be used if we need to support very old browsers.

So, domain option allows to make a cookie accessible at subdomains.

expires, max-age

By default, if a cookie doesn’t have one of these options, it disappears when the browser is closed. Such cookies are called “session cookies”

To let cookies survive browser close, we can set either expires or max-age option.

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

Cookie expiration date, when the browser will delete it automatically.

The date must be exactly in this format, in GMT timezone. We can use date.toUTCString to get it. For instance, we can set the cookie to expire in 1 day:

If we set expires to a date in the past, the cookie is deleted.

An alternative to expires , specifies the cookie expiration in seconds from the current moment.

If zero or negative, then the cookie is deleted:

secure

• secure

The cookie should be transferred only over HTTPS.

By default, if we set a cookie at http://site.com , then it also appears at https://site.com and vice versa.

That is, cookies are domain-based, they do not distinguish between the protocols.

With this option, if a cookie is set by https://site.com , then it doesn’t appear when the same site is accessed by HTTP, as http://site.com . So if a cookie has sensitive content that should never be sent over unencrypted HTTP, then the flag is the right thing.

samesite

That’s another security attribute samesite . It’s designed to protect from so-called XSRF (cross-site request forgery) attacks.

To understand how it works and when it’s useful, let’s take a look at XSRF attacks.

XSRF attack

Imagine, you are logged into the site bank.com . That is: you have an authentication cookie from that site. Your browser sends it to bank.com with every request, so that it recognizes you and performs all sensitive financial operations.

Now, while browsing the web in another window, you accidentally come to another site evil.com . That site has JavaScript code that submits a form to bank.com with fields that initiate a transaction to the hacker’s account.

The browser sends cookies every time you visit the site bank.com , even if the form was submitted from evil.com . So the bank recognizes you and actually performs the payment.

That’s called a “Cross-Site Request Forgery” (in short, XSRF) attack.

Real banks are protected from it of course. All forms generated by bank.com have a special field, so called “XSRF protection token”, that an evil page can’t generate or extract from a remote page (it can submit a form there, but can’t get the data back). And the site bank.com checks for such token in every form it receives.

But such protection takes time to implement: we need to ensure that every form has the token field, and we must also check all requests.

Enter cookie samesite option

The cookie samesite option provides another way to protect from such attacks, that (in theory) should not require “xsrf protection tokens”.

It has two possible values:

• samesite=strict (same as samesite without value)

A cookie with samesite=strict is never sent if the user comes from outside the same site.

In other words, whether a user follows a link from their mail or submits a form from evil.com , or does any operation that originates from another domain, the cookie is not sent.

If authentication cookies have samesite option, then XSRF attack has no chances to succeed, because a submission from evil.com comes without cookies. So bank.com will not recognize the user and will not proceed with the payment.

The protection is quite reliable. Only operations that come from bank.com will send the samesite cookie, e.g. a form submission from another page at bank.com .

Although, there’s a small inconvenience.

When a user follows a legitimate link to bank.com , like from their own notes, they’ll be surprised that bank.com does not recognize them. Indeed, samesite=strict cookies are not sent in that case.

We could work around that by using two cookies: one for “general recognition”, only for the purposes of saying: “Hello, John”, and the other one for data-changing operations with samesite=strict . Then a person coming from outside of the site will see a welcome, but payments must be initiated from the bank website, for the second cookie to be sent.

A more relaxed approach that also protects from XSRF and doesn’t break user experience.

Lax mode, just like strict , forbids the browser to send cookies when coming from outside the site, but adds an exception.

A samesite=lax cookie is sent if both of these conditions are true:

The HTTP method is “safe” (e.g. GET, but not POST).

The full list of safe HTTP methods is in the RFC7231 specification. Basically, these are the methods that should be used for reading, but not writing the data. They must not perform any data-changing operations. Following a link is always GET, the safe method.

The operation performs top-level navigation (changes URL in the browser address bar).

That’s usually true, but if the navigation is performed in an , then it’s not top-level. Also, JavaScript methods for network requests do not perform any navigation, hence they don’t fit.

So, what samesite=lax does is basically allows a most common “go to URL” operation to have cookies. E.g. opening a website link from notes satisfies these conditions.

But anything more complicated, like a network request from another site or a form submittion loses cookies.

If that’s fine for you, then adding samesite=lax will probably not break the user experience and add protection.

Overall, samesite is a great option, but it has an important drawback:

• samesite is ignored (not supported) by old browsers, year 2017 or so.

So if we solely rely on samesite to provide protection, then old browsers will be vulnerable.

But we surely can use samesite together with other protection measures, like xsrf tokens, to add an additional layer of defence and then, in the future, when old browsers die out, we’ll probably be able to drop xsrf tokens.

httpOnly

This option has nothing to do with JavaScript, but we have to mention it for completeness.

The web-server uses Set-Cookie header to set a cookie. And it may set the httpOnly option.

This option forbids any JavaScript access to the cookie. We can’t see such cookie or manipulate it using document.cookie .

That’s used as a precaution measure, to protect from certain attacks when a hacker injects his own JavaScript code into a page and waits for a user to visit that page. That shouldn’t be possible at all, a hacker should not be able to inject their code into our site, but there may be bugs that let hackers do it.

Normally, if such thing happens, and a user visits a web-page with hacker’s JavaScript code, then that code executes and gains access to document.cookie with user cookies containing authentication information. That’s bad.

But if a cookie is httpOnly , then document.cookie doesn’t see it, so it is protected.

Appendix: Cookie functions

Here’s a small set of functions to work with cookies, more convenient than a manual modification of document.cookie .

There exist many cookie libraries for that, so these are for demo purposes. Fully working though.

getCookie(name)

The shortest way to access cookie is to use a regular expression.

The function getCookie(name) returns the cookie with the given name :

Here new RegExp is generated dynamically, to match ; name= .

Please note that a cookie value is encoded, so getCookie uses a built-in decodeURIComponent function to decode it.

setCookie(name, value, options)

Sets the cookie name to the given value with path=/ by default (can be modified to add other defaults):

Работа с куки в JavaScript, document.cookie

Работа с куки в JavaScript, document.cookie

Здравствуйте! В этом уроке я расскажу о работе с куки в JavaScript. Давайте для начала разберемся что такое куки файлы и для чего они нужны. Cookie — это файлы, которые хранятся на компьютере пользователя и по которым сервер, то есть сайт сможет опознать посетителя. как правило в таких файлах хранят пару логин — пароль, хотя можно сохранять и другую информацию. Объем таких файлов не большой и составляет 5 килобайт. Сейчас на смену куам пришло LocalStorage (локальное хранилище), но о нем еще будет отдельный разговор.

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

Чтение document.cookie

Наверняка у вас есть cookie, которые привязаны к этому сайту. Давайте полюбуемся на них. Вот так например:

Эта строка состоит из пар ключ=значение, которые перечисляются через точку с запятой с пробелом «; «.
Значит, чтобы прочитать cookie, достаточно разбить строку по «; «, и затем найти нужный ключ. Это можно делать либо через split и работу с массивом, либо через регулярное выражение.

Функция getCookie(name)

Следующая функция getCookie(name) вернет cookie с именем name:

Обратите внимание, что значение может быть любым. Если оно содержит символы, нарушающие форматирование, например, пробелы или ;, то оно кодируется при помощи encodeURIComponent. Функция getCookie автоматически раскодирует его.

Запись в document.cookie

В document.cookie можно и записывать. При этом запись не перезаписывает существующие cookie, а дополняет к ним, что немаловажно!

Например, такая строка поставит cookie с именем user и значением Petya:

Однако, всё не так просто. У cookie есть ряд очень важных настроек, которые очень желательно указать, так как значения по умолчанию у них довольно неудобны.

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

path=/mypath Путь, внутри которого будет доступ к cookie. Если не указывайте, то имеется в виду текущий путь и все пути ниже него.

Как правило, используется path=/, то есть cookie доступно со всех страниц сайта. domain=site.com Домен, на котором доступно cookie. Если не указать, то используется текущий домен. Допустимо указывать текущий домен site.com и его поддомены, например podsite.site.com.

Если указать специальную маску .site.com, то cookie будет доступно на сайте и всех его поддоменах. Это используется, например, в случаях, когда кукис содержит данные авторизации и должна быть доступна как на site.com, так и на podsite.site.com. expires=Tue, 21 Jan 2039 03:14:07 GMT Дата истечения куки в формате GMT. Получить нужную дату можно, используя объект Date. Его можно установить в любое время, а потом вызвать toUTCString(), например:

Если дату не указать, то cookie будет считаться «сессионным». Такое cookie удаляется при закрытии браузера. Если дата в прошлом, то кукис будет удален. secure Cookie можно передавать только по HTTPS.

Например, чтобы поставить cookie name=val по текущему пути с датой истечения через 60 секунд:

Чтобы удалить этот куки:

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

Функция setCookie(name, value, options)

Если собрать все настройки воедино, вот такая функция может ставит куки:

name название cookie value значение cookie (строка) options Объект с дополнительными свойствами для установки cookie: expires Время истечения cookie. Интерпретируется по-разному, в зависимости от типа:

• Число – количество секунд до истечения. Например, expires: 3600 – кука на 1 час.
• Объект типа Date – дата истечения.
• Если expires в прошлом, то cookie будет удалено при выходе из браузера.
• Если expires отсутствует или 0, то cookie будет установлено как сессионное и исчезнет при закрытии браузера.

path Путь для cookie. domain Домен для cookie. secure Если true, то пересылать cookie только по защищенному соединению https.

Функция deleteCookie(name)

Здесь всё очень просто – удаляем вызовом setCookie с датой в прошлом.

Сторонние cookie

При работе с cookie есть важная тонкость, которая касается внешних ресурсов.

Теоретически, любой ресурс, который загружает браузер, может поставить cookie.

• Если на странице есть , то вместе с картинкой в ответ сервер может прислать заголовки, устанавливающие cookie.
• Если на странице есть , то во-первых сервер может вместе с button.php прислать cookie, а во-вторых JS-код внутри ифрейма может записать в document.cookie

При этом cookie будут принадлежать тому домену, который их поставил. То есть, на liveinternet.ru для первого случая, и на twitter.com во втором.

Такие cookie, которые не принадлежат основной странице, называются «сторонними» (3rd party) cookies. Не все браузеры их разрешают.

Как правило, в настройках браузера можно поставить «Блокировать данные и файлы cookie сторонних сайтов» (Chrome).

Большой брат смотрит за тобой.

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

Например, на многих сайтах размещаются баннеры и другая реклама Google Ads. При помощи таких cookie компания Google будет знать, какие именно сайты вы посещаете, сколько времени вы на них проводите и многое другое. И потом вам будет показываться соответствующая реклама. Например вы смотрели утюги даже если вы не купили утюг. Вам все равно будут показывать именно утюги.

Как? Да очень просто – на каждом сайте загружается, к примеру, картинка с рекламой. При этом баннер берётся с домена, принадлежащего Google. Вместе с баннером Google ставит cookie со специальным уникальным идентификатором.

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

• Cookie с домена баннера, то есть уникальный идентификатор, который был поставлен ранее.
• Стандартный заголовок Referrer (его не будет при использовании HTTPS!), который говорит, с какого сайта сделан запрос. Да, впрочем, Google и так знает, с какого сайта запрос, ведь идентификатор сайта есть в адресе URL.

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

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

А если очень надо?

Браузеры можно настроить на то, чтобы не принимать куки со сторонних сайтов.

А что, если ну очень надо поставить стороннюю cookie, и чтобы это было надёжно?

Такая задача действительно возникает, например, в системе кросс-доменной авторизации, когда есть несколько доменов 2-го уровня, и хочется, чтобы посетитель, который входит в один сайт, автоматически распознавался во всей сетке доменов. При этом cookie для авторизации ставятся на главный домен – «мастер», а остальные сайты запрашивают их при помощи специального скрипта (и, как правило, копируют к себе для оптимизации, но здесь это не суть).

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

Есть несколько способов поставить y cookie для стронних сайтов.

Использовать ифрейм. Ифрейм является полноценным окном браузера. В нём должна быть доступна вся функциональность, в том числе cookie. Как браузер решает, что ифрейм «сторонний» и нужно запретить для него и его скриптов установку cookie? Критерий таков: «в ифрейме нет навигации». Если навигация есть, то ифрейм признаётся полноценным окном.

Например, в сторонний iframe можно сделать POST. И тогда, в ответ на POST, сервер может поставить cookie. Или прислать документ, который это делает. Ифрейм, в который прошёл POST, считается родным и надёжным. Popup-окно Другой вариант – использовать popup, то есть при помощи window.open открывать именно окно со стороннего домена, и уже там ставить cookie. Это тоже работает. Редирект Ещё одно альтернативное решение, которое подходит не везде – это сделать интеграцию со сторонним доменом, такую что на него можно сделать редирект, он ставит cookie и делает редирект обратно.

Дополнительно

• На Cookie наложены ограничения:
  • Имя и значение (после encodeURIComponent) вместе не должны превышать 4кб.
  • Общее количество cookie на домен ограничено 30-50, в зависимости от браузера.
  • Разные домены 2-го уровня полностью изолированы. Но в пределах доменов 3-го уровня куки можно ставить свободно с указанием domain.
  • Сервер может поставить cookie с дополнительным флагом HttpOnly. Cookie с таким параметром передаётся только в заголовках, оно никак не доступно из JavaScript.
• Иногда посетители отключают cookie. Отловить это можно проверкой свойства navigator.cookieEnabled

• Конечно, предполагается, что включён JavaScript. Впрочем, посетитель без JS и cookie с большой вероятностью не человек, а робот.

Итоги

Для того чтобы прочитать cookie используется свойство document.cookie.

Для тогочтобы добавить новую пару ключ=значение используется document.cookie = «user=Petya»

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

работа с куками из javascript

Сегодня хочется поделиться с теми кто еще не в теме, теорией о том как работать с cookie из JS

JS не предоставляет удобного API для работы с cookies. И это в принципе не плохо, могло бы быть и хуже (например js вообще не реализовывал бы работы с куками), но все же, лучше, когда можно читать куки с помощью одной инструкции (чего пока нативным js — невозможно).

Существует множество framework’ов и plugin’ов к ним, которые восполняют данный недостаток. Однако бывают проекты где нецелесообразно подключать framework лишь для удобства работы с куками.

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

cookie.set(‘bla’, ‘blabla’);
cookie.get(‘bla’);

Немножечко теории о механизме предоставляемом js’ом для работы с cookie:

Все что у нас есть — свойство document.cookie, оно не реализует за собой никаких привычных рядовому программисту методов, типа document.cookie.get(‘bla’);

Чтение cookie

document.cookie содержит набор значений cookie_name=cookie_value; (разделенных между собой «; » (точка с запятой плюс пробел)), отсюда следует, что бы получить значение конкретной куки — необходимо пропарсить всю строку и выдернуть необходимые данные. Что примечательно, в свойстве содержится пары имя=значение, никаких дополнительный данных о куках таких как: expires time, path, domain, secure — не содержит.

Создание/обновление cookie

document.cookie ведет себя как строка, но не обычная. представим что у нас есть 2 куки key1 = val1 и key2 = val2.

alert(document.cookie) //key1=val1; key2=val2;

Для того что бы добавить новую куку key3 = val3

document.cookie= ‘key3=val3; ‘;
alert(document.cookie) //key1=val1; key2=val2; key3=val3;

Для того что бы обновить куку, зададим key2 значение hello world

document.cookie= ‘key2=hello world; ‘;
alert(document.cookie) //key1=val1; key2=hello world; key3=val3;

Удаление Cookie

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

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

expires — время, после которого кука удаляется.
domain — домен для которого кука действительна, грубо говоря, если кука была создана на домене js.com, то ни на каком другом домене она не будет видна.
path — множество документов, при запросе на которые браузер будет посылать куку
secure — свойство-флаг разрешающий посылать браузуру куку только при https соединении

вообщем все это записывается в виде document.cookie = ‘key4=val4; [expires=Sat, 09 Jan 2010 16:14:53 GMT; ][path=/; ][domain=js.com; ][secure; ]

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

document.cookie= ‘key2=; expires=Mon, 05 Jul 1982 16:37:55 GMT; ‘;
alert(document.cookie)//key1=val1; key3=val3;

Собственно все

UPD: это мой первый пост, прошу сильно не пинать. Надеюсь кому то будет полезно