В чем разница между созданием файлов cookie на сервере и на клиенте? Это файлы cookie на стороне сервера и файлы cookie на стороне клиента? Есть ли способ создавать файлы cookie, которые можно читать только на сервере или на клиенте?
В чем разница между cookie на стороне сервера и cookie на стороне клиента?
comment
Не существует такой вещи, как «cookie на стороне сервера» и «cookie на стороне клиента». Есть только файлы cookie, пары имя / значение, отправляемые в заголовках HTTP как с запросами, так и с ответами.
- person Dan Grossman schedule 03.08.2011
comment
Возможно, ссылка на переменные сеанса, которые содержат данные на сервере. Обычно идентификатор сеанса сохраняется как файл cookie на стороне клиента.
- person AndrewR schedule 03.08.2011
comment
По всей вероятности, вопрос относится к различным способам кодирования файлов cookie на стороне сервера (то есть способу их кодирования в заголовке ответа «Cookie» и «Set-Cookie») и на стороне клиента (т.е. способу, которым они 'перекодированы в заголовке запроса Cookie - переменная $ Path и все такое). См. RFC 2109.
- person Ophir Radnitz schedule 26.07.2012
comment
Основное различие можно усилить, слегка переименовав вещи: файлы cookie, устанавливаемые клиентом и сервером. Файлы cookie отправляются в запросах и ответах, но основное различие заключается в том, на какой стороне создается файл cookie (или другой идентификатор, относящийся к сеансу).
- person Jochem Schulenklopper schedule 25.05.2021
Ответы (5)
HTTP-файлы cookie
Файлы cookie - это пары ключ / значение, используемые веб-сайтами для хранения информации о состоянии в браузере. Допустим, у вас есть веб-сайт (example.com), когда браузер запрашивает веб-страницу, веб-сайт может отправлять файлы cookie для хранения информации в браузере.
Пример запроса браузера:
GET /index.html HTTP/1.1
Host: www.example.com
Пример ответа с сервера:
HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: foo=10
Set-Cookie: bar=20; Expires=Fri, 30 Sep 2011 11:48:00 GMT
... rest of the response
Здесь в браузере хранятся два файла cookie: foo = 10 и bar = 20. Срок действия второго истекает 30 сентября. В каждом последующем запросе браузер отправляет файлы cookie обратно на сервер.
GET /spec.html HTTP/1.1
Host: www.example.com
Cookie: foo=10; bar=20
Accept: */*
СЕССИИ: файлы cookie на стороне сервера
Файлы cookie на стороне сервера известны как «сеансы». В этом случае веб-сайт сохраняет в браузере один файл cookie, содержащий уникальный идентификатор сеанса. Информация о состоянии (foo = 10 и bar = 20 выше) хранится на сервере, а идентификатор сеанса используется для сопоставления запроса с данными, хранящимися на сервере.
Примеры использования
Вы можете использовать как сеансы, так и файлы cookie для хранения: данных аутентификации, пользовательских настроек, содержимого диаграммы на веб-сайте электронной коммерции и т. Д.
Плюсы и минусы
Ниже плюсы и минусы решений. Это первое, что приходит мне в голову, наверняка есть и другие.
Плюсы cookie:
- масштабируемость: все данные хранятся в браузере, поэтому каждый запрос может проходить через балансировщик нагрузки на разные веб-серверы, и у вас есть вся информация, необходимая для выполнения запроса;
- к ним можно получить доступ через javascript в браузере;
- не будучи на сервере, они переживут перезапуск сервера;
- RESTful: запросы не зависят от состояния сервера
Минусы файлов cookie:
- хранилище ограничено до 80 КБ (20 файлов cookie, по 4 КБ каждое)
- реализовать безопасные файлы cookie непросто: прочтите бумажный документ Безопасный протокол cookie
Плюсы сеанса:
- в целом проще в использовании, в PHP, вероятно, нет большой разницы.
- неограниченное хранилище
Минусы сеанса:
- сложнее масштабировать
- при перезапуске веб-сервера вы можете потерять все сеансы или нет, в зависимости от реализации
- не RESTful
person
filippo
schedule
03.08.2011
Плюсы сеанса:
secure?
- person user2167582; 06.07.2015
почему сеансы более безопасны? Если вы отправите файл cookie сеанса через http, он может быть взломан. Если сайт использует https, безопасность должна быть такой же, пока вы используете безопасные файлы cookie (зашифрованные, подписанные и т. Д.)
- person filippo; 09.07.2015
Минусы файлов cookie: увеличивает размер каждого запроса, что может повлиять на производительность. Я не знаю цифр, но поскольку люди действительно используют домены без файлов cookie для вещей, я считаю, что это нетривиально.
- person maniexx; 29.05.2017
Ответ, в основном вводящий в заблуждение - сеансы - это не файлы cookie. en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#HTTP_session В зависимости от попутно управление сессией реализовано на сервере. Обычно у вас есть один или несколько файлов cookie, которые связаны с управлением сеансом и содержат идентификатор сеанса. Также REST и RESTful не имеют ничего общего с файлами cookie или управлением сеансами - реализации REST и RESTful могут иметь сеансы и файлы cookie.
- person Zlatin Zlatev; 20.11.2017
@ZlatinZlatev, это зависит ... Если бэкэнд (например, article-service) должен сделать запрос, скажем, user-service, который хранит все текущие идентификаторы сеансов, то это вызовет проблемы с производительностью и масштабируемостью. Но если файлы cookie / сеансы нигде не хранятся на бэкэнде, а только секрет для алгоритма подписи, тогда article-service может сказать да, дорогой клиент, cookie, предоставленный вам пользовательской службой, является законным и немедленно отвечает без сделать запрос к пользователю-сервису
- person Phil; 13.01.2019
@ Фил, спасибо за некромантию. Однако вы имеете в виду основные и сторонние файлы cookie. И представление стороннего cookie (одного из того, что вы называете пользовательской службой) в качестве основного файла cookie (в качестве файла cookie, происходящего из того, что вы называете службой статей). В любом случае мое утверждение было связано с тем фактом, что переменные сеанса имеют мало общего с файлами cookie, вы можете иметь переменные сеанса до тех пор, пока вы можете идентифицировать сеанс. Также то, что вы предлагаете, имеет потенциальную уязвимость для перехвата сеанса.
- person Zlatin Zlatev; 14.01.2019
@ZlatinZlatev в моем опыте переменные сеанса реализуются с использованием некоторой формы cookie SessionID большую часть времени (PHP, Java, .NET), другой вариант, который я видел, - это добавление SessionID в URL-адреса, но этот подход также имеет захват сеанса риски. URL-адреса можно копировать и вставлять, читать из вредоносного js-скрипта и т. Д. Чтобы сделать файлы cookie безопасными, вы должны всегда использовать https и устанавливать флаги httpOnly и secure, чтобы сделать их нечитаемыми из js. Кстати, есть ли другие способы реализовать сеансы?
- person filippo; 14.01.2019
@ZlatinZlatev то, о чем я имел в виду, в основном JWT. Вы можете разместить его внутри заголовка авторизации или внутри файла cookie. User-Service также может быть внешним ресурсом / поставщиком, таким как сервер авторизации в OAuth2. Файл cookie используется веб-сайтом только для сохранения состояния при обновлении. Вы также можете использовать для этого localstorage (помните, даже если JWT не будет удален, токен истечет и через некоторое время станет бесполезным)
- person Phil; 14.01.2019
См. stackoverflow.com/questions/35054840/ Я не говорил, что сеансы обычно не реализуются с помощью файлов cookie, но что есть другие варианты управления сеансами, поэтому неправильно говорить о переменных сеанса как о файлах cookie на стороне сервера. Я также имел в виду JWT, когда в 2017 году в комментарии выше сказал, что реализации REST и RESTful могут иметь сеансы и файлы cookie. Хотя некоторые пуристы могут возразить, что это неправильный способ реализации REST API.
- person Zlatin Zlatev; 17.01.2019
есть кое-что, чего я не понимаю, меня беспокоит ... если кто-то может отлаживать: файлы cookie хранятся как файлы на клиенте 1. Почему они отправляются на сервер в заголовках http ?? (они могут быть прочитаны на клиенте!) 2. Если сервер отправляет Set-Cookie: foo = 10 BACK клиенту, это предполагает, что файлы cookie также хранятся на сервере. Я предполагаю, что $ _COOKIE (php) получает значение из локального файла. Верно ли, что значение также хранится на стороне сервера? в таком случае, как я могу получить значение на стороне сервера?
- person v2belleville; 21.08.2019
Я пытаюсь отладить :-) 1. tools.ietf.org/html/rfc6265 реферат должен ответить. HTTP - это протокол без сохранения состояния. Заголовок Set-Cookie хранит информацию о состоянии в клиенте. Клиенту необходимо отправить его обратно, иначе сервер не получит доступа к этой информации о состоянии. 2. Нет, как правило, сервер не хранит информацию, отправленную с помощью Set-Cookie (если это не идентификатор сеанса - см. Ответ выше). $ _COOKIE читает из HTTP-заголовка, $ _SESSION вместо этого читает из локальных файлов и отправляет клиенту cookie PHPSESSIONID, чтобы сопоставить клиента с информацией, хранящейся на сервере.
- person filippo; 21.08.2019
@filippo спасибо за попытку, но я все еще кое-что упустил ..; -} ... позвольте мне спросить по-другому: текстовые файлы, которые хранятся на клиенте, те, которые вы можете увидеть в настройках вашего браузера, как они используются? это для чего-то совершенно другого, чем то, что происходит в инструкции setcookie ()?
- person v2belleville; 21.08.2019
Вы имеете в виду пример использования cookie? Или как получить доступ к cookie в браузере? Для второго вы можете использовать document.cookie developer.mozilla.org / en-US / docs / Web / API / Document / cookie в javascript (это единственный способ), но не все файлы cookie доступны для чтения через javascript. Это сервер, который решает использовать флаг HTTP-Only
- person filippo; 21.08.2019
я пытаюсь выяснить, как информация перемещается между файлами cookie на сервере, переменными в коде и любым другим хранилищем, которое может быть на сервере. Я попробовал образец document.cookie на указанной вами странице, и я не понимаю, почему сейчас я не вижу файл cookie в списке браузера. где создается файл cookie document.cookie ??
- person v2belleville; 21.08.2019
Вы, наверное, имеете в виду разницу между файлами cookie только Http и их аналогом?
Файлы cookie только Http не могут быть доступны (прочитаны или записаны) в JavaScript на стороне клиента, только на стороне сервера. Если флаг Http Only не установлен или cookie создается в (клиентском) JavaScript, cookie может быть прочитан и записан в (клиентском) JavaScript, а также на стороне сервера.
person
nikc.org
schedule
03.08.2011
Все файлы cookie являются клиентским и сервером
Нет никакой разницы. Обычный файл cookie может быть установлен на стороне сервера или на стороне клиента. «Классический» файл cookie будет отправляться обратно с каждым запросом. Файл cookie, установленный сервером, будет отправлен клиенту в ответ. Сервер отправляет cookie только тогда, когда он явно установлен или изменен, в то время как клиент отправляет cookie по каждому запросу.
Но по сути это одно и то же печенье.
Но поведение может измениться
Файл cookie в основном представляет собой пару name=value, но после значения может быть набором атрибутов, разделенных точкой с запятой, которые влияют на поведение файла cookie, если это реализовано клиентом (или сервером). Эти атрибуты могут касаться времени жизни, контекста и различных настроек безопасности.
Только HTTP (не только сервер)
Один из этих атрибутов может быть установлен сервером, чтобы указать, что это файл cookie только для HTTP. Это означает, что файл cookie по-прежнему отправляется туда и обратно, но он не будет доступен в JavaScript. Однако обратите внимание, что файл cookie все еще там! Это всего лишь встроенная защита в браузере, но если кто-то будет использовать до смешного старый браузер, такой как IE5, или какой-то специальный клиент, он действительно сможет прочитать cookie!
Кажется, что есть «серверные куки», но на самом деле их нет. Эти файлы cookie по-прежнему отправляются клиенту. На клиенте нет способа предотвратить отправку файла cookie на сервер.
Альтернативы достижению «единственности»
Если вы хотите сохранить значение только на сервере или только на клиенте, вам понадобится какое-то другое хранилище, например файл или база данных на сервере или локальное хранилище на клиенте.
person
GolezTrol
schedule
03.08.2011
привет, я новичок в этих концепциях и у меня есть некоторые сомнения. Извините, мои вопросы могут показаться глупыми, но я все равно буду их задавать. Приветствуется любая помощь - можно ли отправить файл cookie, установленный на стороне клиента, в любой домен? Я имею ввиду, разве это не угроза безопасности? Кроме того, как это работает с клиентами, не являющимися браузерами, такими как API и т. Д.?
- person Karan Chadha; 22.05.2018
Привет, @KaranChadha, если у вас есть вопрос, задайте его как формальный вопрос, используя кнопку «Задать вопрос» вверху страницы. Ветвь комментариев к вопросу семилетней давности, вероятно, не привлечет к нему должного внимания. Конечно, можно добавить ссылку на этот вопрос и ответ или даже на этот ответ. Для этого вы можете использовать кнопку «Поделиться» внизу каждой публикации.
- person GolezTrol; 22.05.2018
Это правда? Файлы cookie, созданные клиентом, не передаются. Если вы выполняете
document.cookie="foo=bar", за которым следуетfetch("/foobar", {credentials: 'include'} ), файл cookie, содержащий foo=bar, не отправляется. Просто попробовал этот код прямо на этом сайте с помощью DevTools и консоли.
- person oligofren; 17.09.2018
Да, это правда, также говорится в документации, но есть некоторые особенности, которые могут вызвать это, например, отсутствующий атрибут expires.
- person GolezTrol; 17.09.2018
Нет никакой разницы: может ли клиент перезаписать файл cookie, установленный на сервере?
- person Marinos An; 04.02.2019
@MarinosAn Да, может. Но мой ответ был немного кратким, когда дело дошло до атрибутов, которые изменяют поведение файла cookie, поэтому я немного расширил его.
- person GolezTrol; 04.02.2019
В чем разница между созданием файлов cookie на сервере и на клиенте?
Вы имеете в виду два способа настройки файлов cookie на клиенте, а именно:
- По серверу
- По клиенту (в большинстве случаев браузер)
По серверу. Заголовок ответа Set-cookie от сервера указывает клиенту установить cookie в этом конкретном домене. Реализация для фактического создания и хранения cookie находится в браузере. Для последующих запросов к тому же домену браузер автоматически устанавливает заголовок запроса Cookie для каждого запроса, тем самым позволяя серверу иметь некоторое состояние для протокола HTTP без сохранения состояния. Атрибуты файлов cookie Domain и Path используются браузером для определения, какие файлы cookie должны быть отправлены на сервер. Сервер получает только name=value пар и не более того.
По клиенту: можно создать файл cookie в браузере, используя document.cookie = cookiename=cookievalue. Однако, если сервер не намеревается отвечать на какой-либо случайный файл cookie, созданный пользователем, такой файл cookie бесполезен.
Это файлы cookie на стороне сервера и файлы cookie на стороне клиента?
Файлы cookie всегда принадлежат клиенту. Не существует файлов cookie на стороне сервера.
Есть ли способ создавать файлы cookie, которые можно читать только на сервере или на клиенте?
Поскольку чтение значений cookie осуществляется сервером и клиентом, это зависит от того, нужно ли вообще читать cookie. На стороне клиента, установив атрибут HttpOnly файла cookie, можно предотвратить чтение ваших файлов cookie сценариями (в основном Javscript), тем самым действуя как механизм защиты от кражи файлов cookie через XSS, но отправляя файл cookie только на предполагаемый сервер. .
Следовательно, в большинстве случаев, поскольку файлы cookie используются для «состояния» (памяти о прошлых пользовательских событиях), создание файлов cookie на стороне клиента не приносит особой пользы, если только кто-то не знает, какие файлы cookie использует / на которые отвечает сервер.
Ссылка: Википедия
person
KJ Sudarshan
schedule
28.10.2020
Да, вы можете создавать файлы cookie, которые могут быть прочитаны только на стороне сервера. Эти файлы cookie называются «только HTTP», как уже объяснялось в других ответах.
Нет, нет способа (я знаю) создать «куки», которые могут быть прочитаны только на стороне клиента. Файлы cookie предназначены для облегчения взаимодействия между клиентом и сервером.
НО, если вы хотите что-то ПОДОБНОЕ «файлы cookie только для клиента», есть простой ответ: используйте «Локальное хранилище».
Локальное хранилище на самом деле синтаксически проще в использовании, чем файлы cookie. Хороший простой обзор файлов cookie и локального хранилища можно найти по адресу:
Примечание: вы можете использовать файлы cookie, созданные в JavaScript, для хранения вещей, связанных с графическим интерфейсом пользователя, которые вам нужны только на стороне клиента. НО файл cookie отправляется на сервер для КАЖДОГО запроса, он становится частью заголовков http-запроса, таким образом, запрос содержит больше данных и, следовательно, медленнее отправляется.
Если на вашей странице 50 ресурсов, таких как изображения, CSS-файлы и скрипты, то cookie (обычно) отправляется с каждым запросом. Подробнее об этом см. Каждый ли веб-запрос отправляет файлы cookie браузера?
Локальное хранилище не имеет недостатков, связанных с передачей данных, оно не отправляет данные. Это здорово.
person
Panu Logic
schedule
07.11.2018
