В чем разница между cookie на стороне сервера и cookie на стороне клиента?

120

В чем разница между созданием файлов cookie на сервере и на клиенте? Это файлы cookie на стороне сервера и файлы cookie на стороне клиента? Есть ли способ создать файлы cookie, которые можно читать только на сервере или на клиенте?

http  cookies  session-cookies 
— Рахул
источник
15
Не существует такого понятия, как «cookie на стороне сервера» и «cookie на стороне клиента». Есть только файлы cookie, пары имя / значение, отправленные в заголовках HTTP как с запросами, так и с ответами.
— Дэн Гроссман
1
Возможно, ссылка на переменные сеанса, которые содержат данные на сервере. Обычно все еще существует идентификатор сеанса, который хранится как файл cookie на стороне клиента.
— AndrewR
По всей вероятности, вопрос относится к различным способам кодирования файлов cookie на стороне сервера (то есть способу их кодирования в заголовке ответа «Cookie» и «Set-Cookie») и на стороне клиента (т.е. способу, которым они 'перекодированы в заголовке запроса Cookie - переменная $ Path и все такое). См. RFC 2109
— Офир Радниц

Ответы:

146

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:

Плюсы сеанса:

  • вообще проще в использовании, в PHP, вероятно, нет большой разницы.
  • неограниченное хранилище

Минусы сессии:

  • сложнее масштабировать
  • при перезапуске веб-сервера вы можете потерять все сеансы или нет, в зависимости от реализации
  • не RESTful
— филиппо
источник
сессии профи: secure?
— user2167582 06
1
почему сеансы более безопасны? Если вы отправите файл cookie сеанса через http, он может быть взломан. Если сайт использует https, безопасность должна быть такой же, пока вы используете безопасные файлы cookie (зашифрованные, подписанные и т. Д.)
— Филиппо,
1
Минусы файлов cookie: увеличивает размер каждого запроса, что может повлиять на производительность. Я не знаю цифр, но поскольку люди действительно используют домены без файлов cookie для вещей, я считаю, что это нетривиально.
— maniexx
5
Ответ, в основном вводящий в заблуждение - сеансы - это не файлы cookie. en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#HTTP_session У вас могут быть переменные сеанса в зависимости от того, как управление сеансом реализовано на сервере. Обычно у вас есть один или несколько файлов cookie, которые связаны с управлением сеансом, поскольку содержат идентификатор сеанса. Также REST и RESTful не имеют ничего общего с файлами cookie или управлением сеансами - реализации REST и RESTful могут иметь сеансы и файлы cookie.
— Златиным Zlatev
2
См. Stackoverflow.com/questions/35054840/. Я не говорил, что сеансы обычно не реализуются с помощью файлов cookie, но что есть другие варианты управления сеансом, поэтому неправильно говорить о переменных сеанса как о файлах cookie на стороне сервера. Я также имел в виду JWT, когда в 2017 году в комментарии выше сказал, что «реализации REST и RESTful могут иметь сеансы и файлы cookie». Хотя некоторые пуристы могут возразить, что это неправильный способ реализации REST API.
— Златин Златев
57

Вы, наверное, имеете в виду разницу между файлами cookie Http Only и их аналогом?

Файлы cookie только Http не могут быть доступны (прочитаны или записаны) в JavaScript на стороне клиента, только на стороне сервера. Если флаг Http Only не установлен или cookie создается в (клиентском) JavaScript, cookie может быть прочитан и записан в (клиентском) JavaScript, а также на стороне сервера.

— nikc.org
источник
38

Все файлы cookie являются клиентскими и серверными

Нет никакой разницы. Обычный файл cookie может быть установлен на стороне сервера или клиента. «Классический» файл cookie будет возвращаться с каждым запросом. Файл cookie, установленный сервером, будет отправлен клиенту в ответ. Сервер отправляет cookie только тогда, когда он явно установлен или изменен, в то время как клиент отправляет cookie по каждому запросу.

Но по сути это одно и то же печенье.

Но поведение может измениться

Файл cookie - это в основном name=valueпара, но после значения может быть набор атрибутов , разделенных точкой с запятой, которые влияют на поведение файла cookie, если он так реализован клиентом (или сервером). Эти атрибуты могут касаться времени жизни, контекста и различных настроек безопасности.

Только HTTP (не только сервер)

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

Кажется, что есть «серверные куки», но на самом деле их нет. Эти файлы cookie по-прежнему отправляются клиенту. На клиенте нет способа предотвратить отправку файла cookie на сервер.

Альтернативы достижению «единственности»

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

— GolezTrol
источник
привет, я новичок в этих концепциях и у меня есть некоторые сомнения. Извините, мои вопросы могут показаться глупыми, но я все равно буду их задавать. Любая помощь приветствуется - Можно ли отправить файл cookie, установленный на стороне клиента, в любой домен? Я имею ввиду, разве это не угроза безопасности? Кроме того, как это работает с клиентами, не являющимися браузерами, такими как API и т. Д.?
— Каран Чадха
1
Привет, @KaranChadha, если у вас есть вопрос, задайте его как формальный вопрос, используя кнопку «Задать вопрос» вверху страницы. Ветвь комментариев к вопросу семилетней давности, вероятно, не привлечет к нему должного внимания. Конечно, можно добавить ссылку на этот вопрос и ответ или даже на этот ответ. Для этого вы можете использовать кнопку «Поделиться» внизу каждой публикации.
— GolezTrol
Это правда? Файлы cookie, созданные клиентом, не передаются. Если вы делаете, document.cookie="foo=bar"за которым fetch("/foobar", {credentials: 'include'} )следует, не отправляется файл cookie, содержащий foo=bar. Просто попробовал этот код прямо на этом сайте с помощью DevTools и консоли.
— oligofren
Да, это правда, говорится также в документации , но есть некоторые особенности, которые могут вызвать это, например, отсутствующий атрибут expires.
— GolezTrol
1
@MarinosAn Да, может. Но мой ответ был немного кратким, когда дело дошло до атрибутов, которые изменяют поведение файла cookie, поэтому я немного расширил его.
— GolezTrol 04
4

  1. Да, вы можете создавать файлы cookie, которые могут быть прочитаны только на стороне сервера. Эти файлы cookie называются «только HTTP», как уже объяснялось в других ответах.

  2. Нет, нет способа (я знаю) создать «куки», которые могут быть прочитаны только на стороне клиента. Файлы cookie предназначены для облегчения взаимодействия между клиентом и сервером.

  3. НО, если вы хотите что-то ПОДОБНОЕ «файлы cookie только для клиента», есть простой ответ: используйте «Локальное хранилище».

Локальное хранилище на самом деле синтаксически проще в использовании, чем файлы cookie. Хороший простой обзор файлов cookie и локального хранилища можно найти по адресу:

https://courses.cs.washington.edu/courses/cse154/12au/lectures/slides/lecture21-client-storage.shtml#slide8

Примечание: вы можете использовать файлы cookie, созданные в JavaScript, для хранения вещей, связанных с графическим интерфейсом пользователя, которые вам нужны только на стороне клиента. НО cookie отправляется на сервер для КАЖДОГО запроса, он становится частью заголовков http-запроса, таким образом, запрос содержит больше данных и, следовательно, медленнее отправляется.

Если на вашей странице 50 ресурсов, таких как изображения, CSS-файлы и скрипты, то cookie (обычно) отправляется с каждым запросом. Подробнее об этом см. Каждый ли веб-запрос отправляет файлы cookie браузера?

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

— Пану Логик
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.