Php установить cookies,что это, пример использования

Введение:

Откуда возник термин «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 не установлено).

Итак,приступим к практике:

Usage

Static method

This library provides a static method that is compatible to PHP’s built-in function but includes support for more recent features such as the attribute:

\Delight\Cookie\Cookie::setcookie('SID', '31d4d96e407aad42');
// or
\Delight\Cookie\Cookie::setcookie('SID', '31d4d96e407aad42', time() + 3600, '/~rasmus/', 'example.com', true, true, 'Lax');

Builder pattern

Instances of the class let you build a cookie conveniently by setting individual properties. This class uses reasonable defaults that may differ from defaults of the function.

$cookie = new \Delight\Cookie\Cookie('SID');
$cookie->setValue('31d4d96e407aad42');
$cookie->setMaxAge(60 * 60 * 24);
// $cookie->setExpiryTime(time() + 60 * 60 * 24);
$cookie->setPath('/~rasmus/');
$cookie->setDomain('example.com');
$cookie->setHttpOnly(true);
$cookie->setSecureOnly(true);
$cookie->setSameSiteRestriction('Strict');

// echo $cookie;
// or
$cookie->save();
// or
// $cookie->saveAndSet();

The method calls can also be chained:

(new \Delight\Cookie\Cookie('SID'))->setValue('31d4d96e407aad42')->setMaxAge(60 * 60 * 24)->setSameSiteRestriction('None')->save();

A cookie can later be deleted simply like this:

$cookie->delete();
// or
$cookie->deleteAndUnset();

Note: For the deletion to work, the cookie must have the same settings as the cookie that was originally saved – except for its value, which doesn’t need to be set. So you should remember to pass appropriate values to , , and again.

Reading cookies

• Checking whether a cookie exists:

  \Delight\Cookie\Cookie::exists('first_visit');

• Reading a cookie’s value (with optional default value):

  \Delight\Cookie\Cookie::get('first_visit');
  // or
  \Delight\Cookie\Cookie::get('first_visit', \time());

Managing sessions

Using the class, you can start and resume sessions in a way that is compatible to PHP’s built-in function, while having access to the improved cookie handling from this library as well:

// start session and have session cookie with 'lax' same-site restriction
\Delight\Cookie\Session::start();
// or
\Delight\Cookie\Session::start('Lax');

// start session and have session cookie with 'strict' same-site restriction
\Delight\Cookie\Session::start('Strict');

// start session and have session cookie without any same-site restriction
\Delight\Cookie\Session::start(null);
// or
\Delight\Cookie\Session::start('None'); // Chrome 80+

All three calls respect the settings from PHP’s function and the configuration options , , , , , and .

Likewise, replacements for

session_regenerate_id();
// and
session_regenerate_id(true);

are available via

\Delight\Cookie\Session::regenerate();
// and
\Delight\Cookie\Session::regenerate(true);

if you want protection against session fixation attacks that comes with improved cookie handling.

Additionally, access to the current internal session ID is provided via

\Delight\Cookie\Session::id();

as a replacement for

session_id();

Reading and writing session data

• Read a value from the session (with optional default value):

  $value = \Delight\Cookie\Session::get($key);
  // or
  $value = \Delight\Cookie\Session::get($key, $defaultValue);

• Write a value to the session:

  \Delight\Cookie\Session::set($key, $value);

• Check whether a value exists in the session:

  if (\Delight\Cookie\Session::has($key)) {
      // ...
  }

• Remove a value from the session:

  \Delight\Cookie\Session::delete($key);

• Read and then immediately remove a value from the session:

  $value = \Delight\Cookie\Session::take($key);
  $value = \Delight\Cookie\Session::take($key, $defaultValue);

  This is often useful for flash messages, e.g. in combination with the method.

Parsing cookies

$cookieHeader = 'Set-Cookie: test=php.net; expires=Thu, 09-Jun-2016 16:30:32 GMT; Max-Age=3600; path=/~rasmus/; secure';
$cookieInstance = \Delight\Cookie\Cookie::parse($cookieHeader);

Анатомия Cookie

Файлы cookie обычно устанавливаются в HTTP-заголовке (хотя JavaScript также может устанавливать cookie непосредственно в браузере). PHP-скрипт, который устанавливает cookie, может отправлять заголовки, которые выглядят примерно так:

Как вы можете видеть, заголовок Set-Cookie содержит пару значений имени, дату GMT, путь и домен. Имя и значение будут закодированы в URL. Поле expires — это инструкция для браузера, чтобы «забыть» cookie по истечении заданного времени и даты.

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

Тогда скрипт PHP будет иметь доступ к файлу cookie в переменных окружения $_COOKIE или $HTTP_COOKIE_VARS[], который содержит все имена и значения файлов cookie. Выше cookie можно получить, используя .

Attributes

A cookie begins with a name-value pair:

• A can be any US-ASCII characters, except control characters, spaces, or tabs. It also must not contain a separator character like the following: .
• A can optionally be wrapped in double quotes and include any US-ASCII characters excluding control characters, Whitespace, double quotes, comma, semicolon, and backslash. Encoding: Many implementations perform URL encoding on cookie values, however it is not required per the RFC specification. It does help satisfying the requirements about which characters are allowed for <cookie-value> though.
• prefix: Cookies names starting with (dash is part of the prefix) must be set with the flag from a secure page (HTTPS).
• prefix: Cookies with names starting with must be set with the flag, must be from a secure page (HTTPS), must not have a domain specified (and therefore aren’t sent to subdomains) and the path must be .

Optional

Cgi: пишем простой сайт на python. часть 2: обработка форм, cookies

The maximum lifetime of the cookie as an HTTP-date timestamp. See for the required formatting.

If unspecified, the cookie becomes a session cookie. A session finishes when the client shuts down, and session cookies will be removed.

Warning: Many web browsers have a session restore feature that will save all tabs and restore them next time the browser is used. Session cookies will also be restored, as if the browser was never closed.

When an Expires date is set, the deadline is relative to the client the cookie is being set on, not the server.

Optional

Number of seconds until the cookie expires. A zero or negative number will expire the cookie immediately. If both and are set, has precedence.

Optional

Host to which the cookie will be sent.

• If omitted, defaults to the host of the current document URL, not including subdomains.
• Contrary to earlier specifications, leading dots in domain names () are ignored.
• Multiple host/domain values are not allowed, but if a domain is specified, then subdomains are always included.

Optional

A path that must exist in the requested URL, or the browser won’t send the header.

The forward slash () character is interpreted as a directory separator, and subdirectories will be matched as well: for , , , and will all match.

Optional

Cookie is only sent to the server when a request is made with the scheme (except on localhost), and therefore is more resistent to man-in-the-middle attacks.

Note: Do not assume that  prevents all access to sensitive information in cookies (session keys, login details, etc.). Cookies with this attribute can still be read/modified with access to the client’s hard disk, or from JavaScript if the  cookie attribute is not set.

Note: Insecure sites () can’t set cookies with the attribute (since Chrome 52 and Firefox 52). For Firefox, the requirements are ignored when the attribute is set by localhost (since Firefox 75).

Optional

Forbids JavaScript from accessing the cookie, for example, through the property. Note that a cookie that has been created with HttpOnly will still be sent with JavaScript-initiated requests, e.g. when calling  or . This mitigates attacks against cross-site scripting (XSS).

Optional

Controls whether a cookie is sent with cross-origin requests, providing some protection against cross-site request forgery attacks (CSRF).

Standards related to the SameSite Cookies recently changed such that:

1. The cookie-sending behaviour if  is not specified is . Previously the default was that cookies were sent for all requests.
2. Cookies with  must now
   also specify the  attribute (i.e. they require a secure context).

The options below covers the new behaviour. See the  table for information about specific browser implementation (rows: «: Defaults to » and «: Secure context required»).

Inline options are:

• : 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 attribute are sent.
• : The cookie is not sent on cross-site requests, such as calls to load images or frames, but is sent when a user is navigating to the origin site from an external site (e.g. if following a link).
  This is the default behaviour if the attribute is not specified.
• : The browser sends the cookie with both cross-site and same-site requests. The attribute must also be set when !

Definition and Usage

The setcookie() function defines a cookie to be sent along with the rest of the HTTP headers.

A cookie is often used to identify a user. A cookie is a small file that the
server embeds on the user’s computer. Each time the same computer requests a
page with a browser, it will send the cookie too. With PHP, you can both create and retrieve cookie values.

The name of the cookie is automatically assigned to a variable of the same
name. For example, if a cookie was sent with the name «user», a variable is
automatically created called $user, containing the cookie value.

Note: The setcookie() function must appear BEFORE the <html> tag.

Note: The value of the cookie is automatically URLencoded when
sending the cookie, and automatically decoded when received (to prevent
URLencoding, use setrawcookie() instead).

Cookie: создание и параметры

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

Браузер, посылая запрос на конкретный домен, смотрит, есть ли у него куки для этого домена

Пример cookie

Рис. 9.1. Параметры cookie

параметры cookie

1. Имя куки: только латинские буквы, цифры, символ подчеркивания и дефис
2. Значение параметра
3. Дата истечения срока годности
4. Путь, который определяет, в каком месте домена может использоваться файл куки
5. Домен
6. Указание, что данные куки должны передаваться посредством безопасного соединения HTTPS

Рис. 9.2. Пример установки cookie

Рис. 9.3. Проверка передачи cookie

Задание 9_1: Создать cookie, установить значение – ваше имя. Написать код с проверкой передачи и выводом данного cookie на экран. Добавить текстовое поле для вывода значения cookie в нем.

Задание 9_2:
Выводите на экран количество посещений страницы, используя cookie.Предлагаемый алгоритм (возможен другой вариант выполнения):

1. Установите переменную для счетчика ($counter), обнулив ее.
2. Проверьте, установлен ли уже cookie, если да — то присвойте переменной $counter значение cookie (см. пункт 3).
3. Добавьте cookie для хранения количества посещений.
4. Приращивайте счетчик.
5. Проверьте, установлен ли уже cookie, если да — то выводите значение cookie.

Помимо стандартного создания cookie

setcookie("TestCookie", "Ivan", time()+300);

существует возможность создания массива из разных cookie:

Рис. 9.3. Создание массива из разных cookie

Пример: Создать два cookie для хранения имени и возраста. Представить cookie, как массив из двух элементов

Выполнение:

1
2
3
4
5
6
7

while(list($name,$value)=each($_COOKIE)){
	$array="Иван";
	$array1="23";
}
foreach($array as $val){
	echo "значение=".$val."<br>";
}

Результат:

значение=Иван
значение=23

Данное задание также можно выполнить при помощи ассоциативного массива:Выполнение:

1
2
3
4
5
6

while(list($name,$value)=each($_COOKIE)){
	$array"Иван"=23;
}
foreach($array as $k=>$val){
  echo "индекс= ".$k." значение=".$val."<br>";
}

Результат:

значение=Иван
значение=23

Задание:
Создать массив данных для хранения паролей. Значения паролей сохранить в cookie. В html-код добавить текстовые поля, выводить в них значения паролей.

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

Заголовок используется для отправки cookie с сервера на клиентское приложение (браузер). Этот заголовок с сервера дает клиенту указание сохранить cookie.

Set-Cookie: <имя-cookie>=<значение-cookie>

HTTP/1.1 200 OK
Date: Sun, 07 Oct 2018 13:31:17 GMT
Server: Apache/2.4.34 (Win64) mod_fcgid/2.3.9
X-Powered-By: PHP/7.1.10
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Set-Cookie: PHPSESSID=m2iut9i59p73ld1c5q9j49c6t0; path=/
Set-Cookie: visitor=0d3749f09d222bea3b8f163937eb9bf1; Max-Age=31536000; path=/
Set-Cookie: lastvisit=1538919655; path=/
Vary: Accept-Encoding
Content-Encoding: gzip
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ru" lang="ru">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
..........

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

GET /catalog HTTP/1.1
Host: www.server.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://www.server.com/
Cookie: PHPSESSID=m2iut9i59p73ld1c5q9j49c6t0; visitor=0d3749f09d222bea3b8f163937eb9bf1; lastvisit=1538919655
Connection: keep-alive
Upgrade-Insecure-Requests: 1

samesite

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

samesite=lax

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

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

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

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

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

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

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

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

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

Работа с cookie из PHP

Для сохранения cookie в браузере пользователя используется функция :

bool setcookie(
    string $name,
    string $value,
    int $expire, 
    string $path,
    string $domain,
    bool $secure,
    bool $httponly
);

Может принимать следующие параметры:

• : имя cookie, которое будет использоваться для доступа к его значению.
• : значение или содержимое cookie — любой алфавитно-цифровой текст не более 4 кБайт.
• (необязательный параметр): срок действия, после которого cookie уничтожаются. Если данный параметр не установлен или равен 0, то уничтожение cookie происходит после закрытия браузера.
• (необязательный параметр): путь к каталогу на сервере, для которого будут доступны cookie. Если задать «/», cookie будут доступны для всего сайта. Если задать, например, , cookie будут доступны из этого каталога и всех его подкаталогов (, ). По умолчанию значением является текущий каталог, в котором устанавливаются cookie.
• (необязательный параметр): задает домен, для которого будут доступны cookie. Если это домен второго уровня, например, , то cookie доступны для всего сайта , в том числе и для его поддоменов типа . Если задан поддомен , то cookie доступны только внутри этого поддомена.
• (необязательный параметр): указывает на то, что значение cookie должно передаваться по протоколу HTTPS. Если задано , cookie от клиента будет передано на сервер, только если установлено защищенное соединение. По умолчанию параметр равен .
• (необязательный параметр): если равно , cookie будут доступны только через HTTP протокол. То есть cookie в этом случае не будут доступны из JavaScript. По умолчанию параметр равен .

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

setcookie('lastvisit', '', time() - 3600);

Чтобы к идентификатору сессии не было доступа из JavaScript, нужно отредактировать файл :

; Name of the session (used as cookie name).
; http://php.net/session.name
session.name = PHPSESSID

; Whether or not to add the httpOnly flag to the cookie, which makes
; it inaccessible to browser scripting languages such as JavaScript.
; http://php.net/session.cookie-httponly
session.cookie_httponly = 1

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

ini_set('session.cookie_httponly', 1);
session_start();

Еще одни способ изменить флаг — вызов функции перед :

session_set_cookie_params(/*...*/);
session_start();

Установить флаг для из :

; http://php.net/session.cookie-secure
session.cookie_secure = 1

Установить флаг во время работы приложения:

ini_set('session.cookie_secure', 1);
session_start();

session_set_cookie_params(/*...*/);
session_start();

Поиск:
Cookie • HTTP • HTTPS • JavaScript • PHP • Web-разработка • expire • httponly • localStorage • php.ini • secure • sessionStorage • setcookie

Что такое сессия в PHP?

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

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

Следующая диаграмма вкратце изображает протокол HTTP.

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

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

Обработка входа с сессиями и файлами «куки» (cookie)

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

1. Пользователь открывает страницу входа на веб-сайт.
2. После отправки формы входа, сервер, на другом конце, аутентифицирует запрос, проверив введённые учётные данные.
3. Если учётные данные, введённые пользователем, верны, сервер создаёт новый сеанс. Сервер генерирует уникальное случайное число, которое называется идентификатором сеанса. Также, на сервере, создаётся новый файл, который используется для хранения информации, относящейся к сеансу.
4. Затем, идентификатор сеанса передаётся обратно пользователю, вместе с тем, что он запросил. За кулисами этот идентификатор сеанса отправляется в заголовке ответа «куки» (так называется по умолчанию).
5. Когда браузер получает ответ от сервера, он получает заголовок куки-файла . Если в браузере разрешены «куки», то он сохранит этот , в котором хранится идентификатор сеанса, переданный сервером.
6. Для последующих запросов, «кука» передаётся обратно на сервер. Когда сервер получает «куку» , он пытается инициализировать сеанс с этим идентификатором сеанса.  Он делает это, загружая файл сеанса, который был создан ранее во время инициализации сеанса. Затем он инициализирует суперглобальную переменную массива с данными, хранящимися в файле сеанса.

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

На следующей диаграмме показано, как протокол HTTP работает с сеансами.

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

Коротко о главном

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

Цели отправки разносторонние, но основная – различение пользователей и хранение о них информации. Это удобно, так как если те авторизуются на сайте, система запоминает на определенное время их логин и пароль (что это такое я писал здесь) и в дальнейшем пропускает без дополнительной авторизации.

Есть у куки и другие задачи:

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

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

Browser compatibility

The compatibility table in this page is generated from structured data. If you’d like to contribute to the data, please check out https://github.com/mdn/browser-compat-data and send us a pull request.

Update compatibility data on GitHub

2. Задание cookie с помощью JavaScript

Алексеем Александровым

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

// name - имя cookie
// value - значение cookie
//  - дата окончания действия cookie (по умолчанию - до конца сессии)
//  - путь, для которого cookie действительно (по умолчанию - документ, в котором значение было установлено)
//  - домен, для которого cookie действительно (по умолчанию - домен, в котором значение было установлено)
//  - логическое значение, показывающее требуется ли защищенная передача значения cookie

function setCookie(name, value, expires, path, domain, secure) {
var curCookie = name + "=" + escape(value) +
((expires) ? "; expires=" + expires.toGMTString() : "") +
((path) ? "; path=" + path : "") +
((domain) ? "; domain=" + domain : "") +
((secure) ? "; secure" : "")
if (!caution || (name + "=" + escape(value)).length 

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

// name - имя считываемого cookie

function getCookie(name) {
var prefix = name + "="
var cookieStartIndex = document.cookie.indexOf(prefix)
if (cookieStartIndex == -1)
return null
var cookieEndIndex = document.cookie.indexOf(";", cookieStartIndex + prefix.length)
if (cookieEndIndex == -1)
cookieEndIndex = document.cookie.length
return unescape(document.cookie.substring(cookieStartIndex + prefix.length, cookieEndIndex))
}

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

// name - имя cookie
//  - путь, для которого cookie действительно
//  - домен, для которого cookie действительно
function deleteCookie(name, path, domain) {
if (getCookie(name)) {
document.cookie = name + "=" +
((path) ? "; path=" + path : "") +
((domain) ? "; domain=" + domain : "") +
"; expires=Thu, 01-Jan-70 00:00:01 GMT"
}

3. Задание cookie с помощью Perl

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

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

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

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

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

$cookie = $ENV{'HTTP_COOKIE'};

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

А теперь о грусном…

Ограничения:

Клиент (браузер) имеет следующие ограничения для cookies:

всего может храниться до 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.

Вот и все, удачи!