Jaka jest różnica między plikiem cookie po stronie serwera a plikiem cookie po stronie klienta?

120

Jaka jest różnica między tworzeniem plików cookie na serwerze a na kliencie? Czy są to tak zwane pliki cookie po stronie serwera i pliki cookie po stronie klienta? Czy istnieje sposób tworzenia plików cookie, które można odczytać tylko na serwerze lub na kliencie?

http cookies session-cookies Rahul
źródło
15
Nie ma czegoś takiego jak „plik cookie po stronie serwera” czy „plik cookie po stronie klienta”. Są tylko pliki cookie, pary nazwa / wartość wysyłane w nagłówkach HTTP z żądaniami i odpowiedziami.
Dan Grossman,
1
Możliwe odniesienia do zmiennych sesji, które przechowują dane na serwerze. Zwykle nadal istnieje identyfikator sesji przechowywany jako plik cookie po stronie klienta.
AndrewR
Najprawdopodobniej pytanie to dotyczy różnych sposobów kodowania plików cookie po stronie serwera (tj. Sposobu ich kodowania w nagłówkach odpowiedzi „Cookie” i „Set-Cookie”) oraz po stronie klienta (tj. Sposobu, w jaki 'ponownie zakodowane w nagłówku żądania' Cookie '- zmienna $ Path i cały ten jazz). Zobacz RFC 2109
Ophir Radnitz,

Odpowiedzi:

146

COOKIES HTTP

Pliki cookie to pary klucz / wartość używane przez witryny internetowe do przechowywania informacji o stanie w przeglądarce. Załóżmy, że masz witrynę internetową (example.com), gdy przeglądarka żąda wyświetlenia strony internetowej, witryna może wysyłać pliki cookie do przechowywania informacji w przeglądarce.

Przykład żądania przeglądarki:

GET /index.html HTTP/1.1
Host: www.example.com

Przykładowa odpowiedź z serwera:

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

Tutaj dwa pliki cookie foo = 10 i bar = 20 są przechowywane w przeglądarce. Druga wygaśnie 30 września. Przy każdym kolejnym żądaniu przeglądarka prześle pliki cookie z powrotem na serwer.

GET /spec.html HTTP/1.1
Host: www.example.com
Cookie: foo=10; bar=20
Accept: */*

SESJE: Pliki cookie po stronie serwera

Pliki cookie po stronie serwera są nazywane „sesjami”. Witryna w tym przypadku zapisuje w przeglądarce pojedynczy plik cookie zawierający unikalny identyfikator sesji. Informacje o statusie (foo = 10 i bar = 20 powyżej) są przechowywane na serwerze, a identyfikator sesji służy do dopasowania żądania do danych przechowywanych na serwerze.

Przykłady użycia

Możesz używać zarówno sesji, jak i plików cookie do przechowywania: danych uwierzytelniających, preferencji użytkownika, zawartości wykresu w witrynie e-commerce itp.

Plusy i minusy

Poniżej wady i zalety rozwiązań. To pierwsze, które przychodzą mi do głowy, na pewno są inne.

Zalety plików cookie:

  • skalowalność: wszystkie dane są przechowywane w przeglądarce, dzięki czemu każde żądanie może przejść przez system równoważenia obciążenia do różnych serwerów internetowych, a Ty masz wszystkie informacje potrzebne do realizacji żądania;
  • można uzyskać do nich dostęp za pomocą javascript w przeglądarce;
  • nie będąc na serwerze, przetrwają restart serwera;
  • RESTful: żądania nie zależą od stanu serwera

Wady plików cookie:

Zalety sesji:

  • ogólnie łatwiejszy w użyciu, w PHP prawdopodobnie nie ma dużej różnicy.
  • nieograniczone miejsce na dane

Wady sesji:

  • trudniejsze do skalowania
  • przy ponownym uruchomieniu serwera WWW możesz stracić wszystkie sesje lub nie, w zależności od implementacji
  • nie RESTful
filippo
źródło
Plusy: sesja secure?
user2167582
1
dlaczego sesje są bezpieczniejsze? Jeśli wyślesz plik cookie sesji przez http, może zostać przejęty. Jeśli witryna korzysta z protokołu HTTPS, powinno być takie samo, o ile używasz bezpiecznych plików cookie (zaszyfrowanych, podpisanych itp.)
filippo
1
Wady plików cookie: sprawia, że ​​każde żądanie jest większe, potencjalnie wpływając na wydajność. Nie znam liczb, ale ponieważ ludzie używają domen bez plików cookie do rzeczy, zakładam, że jest to nietrywialne.
maniexx
5
W dużej mierze myląca odpowiedź - sesje nie są plikami cookie. en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#HTTP_session Możesz mieć zmienne sesji, w zależności od sposobu zarządzania sesjami na serwerze. Zwykle masz jeden lub więcej plików cookie, które są związane z zarządzaniem sesją, poprzez posiadanie identyfikatora sesji. Również REST i RESTful nie mają nic wspólnego z plikami cookie ani zarządzaniem sesjami - implementacje REST i RESTful mogą mieć sesje i pliki cookie.
Zlatin Zlatev
2
Zobacz stackoverflow.com/questions/35054840/… Nie mówiłem, że sesje nie są zazwyczaj implementowane za pomocą plików cookie, ale że istnieją inne opcje zarządzania sesjami, stąd błędem jest mówienie o zmiennych sesji jako plikach cookie po stronie serwera. Nawiązałem również do JWT, kiedy w 2017 roku w powyższym komentarzu powiedziałem, że „Implementacje REST i RESTful mogą mieć sesje i pliki cookie”. Chociaż niektórzy puryści mogą twierdzić, że nie jest to właściwy sposób implementacji REST API.
Zlatin Zlatev
57

Prawdopodobnie masz na myśli różnicę między plikami cookie Http Only a ich odpowiednikiem?

Http Only cookies nie mogą być dostępne (odczyt lub zapis) w JavaScript po stronie klienta, tylko po stronie serwera. Jeśli flaga Http Only nie jest ustawiona lub plik cookie jest tworzony w JavaScript (po stronie klienta), plik cookie może być odczytywany i zapisywany w JavaScript (po stronie klienta), a także po stronie serwera.

nikc.org
źródło
38

Wszystkie pliki cookie są klientami i serwerami

Nie ma różnicy. Zwykły plik cookie można ustawić po stronie serwera lub klienta. „Klasyczny” plik cookie zostanie odesłany z każdym żądaniem. Plik cookie ustawiony przez serwer zostanie wysłany do klienta w odpowiedzi. Serwer wysyła plik cookie tylko wtedy, gdy jest wyraźnie ustawiony lub zmieniony, podczas gdy klient wysyła plik cookie przy każdym żądaniu.

Ale zasadniczo jest to ten sam plik cookie.

Ale zachowanie może się zmienić

Plik cookie to w zasadzie name=valuepara, ale po wartości może znajdować się kilka atrybutów oddzielonych średnikiem, które wpływają na zachowanie pliku cookie, jeśli jest tak zaimplementowany przez klienta (lub serwer). Te atrybuty mogą dotyczyć czasu życia, kontekstu i różnych ustawień zabezpieczeń.

Tylko HTTP (nie dotyczy tylko serwera)

Jeden z tych atrybutów może być ustawiony przez serwer, aby wskazać, że jest to plik cookie wyłącznie HTTP. Oznacza to, że plik cookie jest nadal przesyłany tam iz powrotem, ale nie będzie dostępny w JavaScript. Zwróć jednak uwagę, że plik cookie nadal tam jest! To tylko wbudowana ochrona w przeglądarce, ale jeśli ktoś użyłby absurdalnie starej przeglądarki, takiej jak IE5, lub jakiegoś niestandardowego klienta, może faktycznie odczytać plik cookie!

Wygląda więc na to, że istnieją „pliki cookie serwera”, ale w rzeczywistości ich nie ma. Te pliki cookie są nadal wysyłane do klienta. Na kliencie nie ma sposobu, aby zapobiec wysyłaniu plików cookie na serwer.

Alternatywy dla osiągnięcia `` jedyności ''

Jeśli chcesz przechowywać wartość tylko na serwerze lub tylko na kliencie, potrzebujesz innego rodzaju magazynu, takiego jak plik lub baza danych na serwerze lub lokalny magazyn na kliencie.

GolezTrol
źródło
cześć, jestem bardzo nowy w tych koncepcjach i mam pewne wątpliwości. Przepraszam, moje pytania mogą brzmieć głupio, ale nadal będę o to pytać. Każda pomoc jest bardzo cenna - czy plik cookie, który został ustawiony po stronie klienta, może zostać wysłany do dowolnej domeny? Mam na myśli, czy to nie jest zagrożenie bezpieczeństwa? Jak to działa z klientami innymi niż przeglądarki, takimi jak interfejsy API itp.?
Karan Chadha
1
Cześć @KaranChadha, jeśli masz pytanie, zadaj je jako formalne pytanie, używając przycisku „Zadaj pytanie” u góry strony. Wątek komentarza dotyczący pytania sprzed 7 lat prawdopodobnie nie zwróci na nie odpowiedniej uwagi. Dodanie linku do tego pytania i odpowiedzi lub nawet konkretnie do tej odpowiedzi jest oczywiście w porządku. W tym celu możesz użyć przycisku „udostępnij” na dole każdego posta.
GolezTrol
Czy to prawda? Wydaje się, że pliki cookie wygenerowane przez klienta nie zostały przesłane. Wówczas, gdy document.cookie="foo=bar"następuje fetch("/foobar", {credentials: 'include'} )nie ma ciasteczka wysyłane zawierające foo=bar. Właśnie wypróbowałem ten kod bezpośrednio na tej stronie, używając DevTools i konsoli.
oligofren
Tak, to prawda, mówi również dokumentacja , ale są pewne szczegóły, które mogą to powodować, takie jak brakujący atrybut expires.
GolezTrol
1
@MarinosAn Tak, może. Ale moja odpowiedź była trochę krótka, jeśli chodzi o atrybuty, które modyfikują zachowanie pliku cookie, więc teraz trochę ją rozszerzyłem.
GolezTrol
4

  1. Tak, możesz tworzyć pliki cookie, które można odczytać tylko po stronie serwera. Są to nazywane „tylko HTTP” -cookies, jak wyjaśniono już w innych odpowiedziach

  2. Nie, nie ma sposobu (znam) na tworzenie plików „cookie”, które można odczytać tylko po stronie klienta. Pliki cookie mają na celu ułatwienie komunikacji klient-serwer.

  3. ALE, jeśli chcesz coś NAJLEPSZEGO „pliki cookie tylko klienta”, istnieje prosta odpowiedź: użyj „Pamięci lokalnej”.

Pamięć lokalna jest w rzeczywistości prostsza pod względem składni niż pliki cookie. Dobre, proste podsumowanie dotyczące plików cookie i lokalnego przechowywania można znaleźć pod adresem:

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

Wskazówka: możesz użyć plików cookie utworzonych w JavaScript do przechowywania rzeczy związanych z GUI, których potrzebujesz tylko po stronie klienta. ALE plik cookie jest wysyłany do serwera w przypadku KAŻDEGO wykonanego żądania, staje się częścią nagłówków żądania http, przez co żądanie zawiera więcej danych, a tym samym wolniej się wysyła.

Jeśli Twoja strona ma 50 zasobów, takich jak obrazy, pliki css i skrypty, plik cookie jest (zazwyczaj) wysyłany z każdym żądaniem. Więcej na ten temat w Czy każde żądanie sieciowe wysyła do przeglądarki pliki cookie?

Lokalna pamięć masowa nie ma tych wad związanych z transferem danych, nie wysyła żadnych danych. To jest wspaniałe.

Panu Logic
źródło