Qual è la differenza tra cookie lato server e cookie lato client?

120

Qual è la differenza tra la creazione di cookie sul server e sul client? Questi sono chiamati cookie lato server e cookie lato client? Esiste un modo per creare cookie che possono essere letti solo sul server o sul client?

http cookies session-cookies

— Rahul
fonte

15

Non esiste un "cookie lato server" rispetto a un "cookie lato client". Ci sono solo cookie, coppie nome / valore inviate nelle intestazioni HTTP con richieste e risposte.

— Dan Grossman

1

Possibilmente riferimento alle variabili di sessione, che contengono dati sul server. Di solito c'è ancora un identificatore di sessione che viene conservato come cookie lato client.

— AndrewR

Con ogni probabilità, la domanda si riferisce ai diversi modi in cui i cookie sono codificati sul lato server (cioè il modo in cui sono codificati nell'intestazione della risposta 'Cookie' e 'Set-Cookie') e sul lato client (cioè il modo in cui 're codificato nell'intestazione della richiesta "Cookie": variabile $ Path e tutto quel jazz). Vedi RFC 2109

— Ophir Radnitz

146

COOKIE HTTP

I cookie sono coppie chiave / valore utilizzate dai siti Web per memorizzare le informazioni di stato nel browser. Supponiamo che tu abbia un sito Web (esempio.com), quando il browser richiede una pagina Web, il sito Web può inviare cookie per memorizzare informazioni sul browser.

Esempio di richiesta del browser:

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

Risposta di esempio dal server:

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

Qui due cookie foo = 10 e bar = 20 vengono memorizzati nel browser. Il secondo scadrà il 30 settembre. Ad ogni successiva richiesta il browser rinvierà i cookie al server.

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

SESSIONI: Cookie lato server

I cookie lato server sono noti come "sessioni". Il sito Web in questo caso memorizza un singolo cookie sul browser contenente un identificatore di sessione univoco. Le informazioni sullo stato (foo = 10 e bar = 20 sopra) sono memorizzate sul server e l'identificatore di sessione viene utilizzato per abbinare la richiesta con i dati memorizzati sul server.

Esempi di utilizzo

Puoi utilizzare sia le sessioni che i cookie per memorizzare: i dati di autenticazione, le preferenze dell'utente, il contenuto di un grafico in un sito di e-commerce, ecc ...

Pro e contro

Di seguito pro e contro delle soluzioni. Queste sono le prime che mi vengono in mente, ce ne sono sicuramente altre.

Cookie Pro:

scalabilità: tutti i dati vengono memorizzati nel browser in modo che ogni richiesta possa passare attraverso un load balancer a diversi server web e tu abbia tutte le informazioni necessarie per evadere la richiesta;
sono accessibili tramite javascript sul browser;
non essendo sul server sopravviveranno ai riavvii del server;
RESTful: le richieste non dipendono dallo stato del server

Contro dei cookie:

lo spazio di archiviazione è limitato a 80 KB (20 cookie, 4 KB ciascuno)
i cookie sicuri non sono facili da implementare: dai un'occhiata al documento Un protocollo per i cookie sicuri

Pro della sessione:

generalmente più facile da usare, in PHP probabilmente non c'è molta differenza.
spazio di archiviazione illimitato

Contro della sessione:

più difficile da scalare
al riavvio del server web è possibile perdere tutte le sessioni o meno a seconda dell'implementazione
non riposante

— filippo
fonte

pro di sessione: secure?

— user2167582

1

perché sessioni più sicure? Se invii il cookie di sessione tramite http, può essere dirottato. Se il sito utilizza https la sicurezza dovrebbe essere la stessa a patto che si utilizzino cookies protetti (criptati, firmati, ecc ...)

— filippo

1

Contro dei cookie: ingrandisce ogni richiesta, influendo potenzialmente sulle prestazioni Non conosco i numeri, ma poiché le persone usano domini senza cookie per cose, presumo che non sia banale.

— maniexx

5

Risposta ampiamente fuorviante: le sessioni non sono cookie. en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#HTTP_session Puoi avere variabili di sessione, a seconda del modo in cui la gestione della sessione è implementata sul server. Di solito hai uno o più cookie che sono relativi alla gestione della sessione, tenendo l'identificatore di sessione. Anche REST e RESTful non hanno nulla a che fare con i cookie o la gestione della sessione: le implementazioni REST e RESTful possono avere sessioni e cookie.

— Zlatin Zlatev

2

Vedi stackoverflow.com/questions/35054840/… Non stavo dicendo che le sessioni non sono tipicamente implementate con i cookie, ma che ci sono altre opzioni per la gestione della sessione, quindi è sbagliato parlare di variabili di sessione come cookie lato server. Mi riferivo anche a JWT quando ho detto nell'anno 2017 nel commento sopra che "le implementazioni REST e RESTful possono avere sessioni e cookie". Sebbene alcuni puristi possano obiettare che questo non è il modo corretto per implementare un'API REST.

— Zlatin Zlatev

57

Probabilmente intendi la differenza tra i cookie solo Http e la loro controparte?

Solo HTTP non è possibile accedere (leggere o scrivere) in JavaScript lato client, solo lato server. Se il flag Http Only non è impostato o il cookie viene creato in JavaScript (lato client), il cookie può essere letto e scritto in JavaScript (lato client) oltre che lato server.

— nikc.org
fonte

38

Tutti i cookie sono client e server

Non c'è differenza. Un cookie normale può essere impostato lato server o lato client. Il cookie "classico" verrà restituito ad ogni richiesta. Un cookie impostato dal server verrà inviato al client in risposta. Il server invia il cookie solo quando è impostato o modificato esplicitamente, mentre il client invia il cookie ad ogni richiesta.

Ma essenzialmente è lo stesso cookie.

Ma il comportamento può cambiare

Un cookie è fondamentalmente una name=valuecoppia, ma dopo il valore può esserci un gruppo di attributi separati da punto e virgola che influenzano il comportamento del cookie se è così implementato dal client (o dal server). Questi attributi possono riguardare la durata, il contesto e varie impostazioni di sicurezza.

Solo HTTP (non è solo server)

Uno di questi attributi può essere impostato da un server per indicare che si tratta di un cookie solo HTTP. Ciò significa che il cookie viene ancora inviato avanti e indietro, ma non sarà disponibile in JavaScript. Nota, però, che il biscotto è ancora lì! È solo una protezione integrata nel browser, ma se qualcuno usasse un browser ridicolmente vecchio come IE5, o un client personalizzato, potrebbe effettivamente leggere il cookie!

Quindi sembra che ci siano "cookie del server", ma in realtà non lo sono. Quei cookie vengono comunque inviati al client. Sul client non è possibile impedire l'invio di un cookie al server.

Alternative per raggiungere l'unicità

Se si desidera memorizzare un valore solo sul server o solo sul client, è necessario un altro tipo di archiviazione, come un file o un database sul server o l'archiviazione locale sul client.

— GolezTrol
fonte

ciao, sono molto nuovo a questi concetti e ho qualche dubbio. Mi dispiace, le mie domande possono sembrare sciocche ma continuerò a chiedere. Qualsiasi aiuto, è molto apprezzato - Un cookie, che è stato impostato sul lato client, può essere inviato a qualsiasi dominio? Voglio dire, non è una minaccia alla sicurezza? Inoltre, come funziona con client non browser, come API, ecc.?

— Karan Chadha

1

Ciao @KaranChadha, se hai una domanda, ti preghiamo di farla come una domanda formale utilizzando il pulsante "Fai domanda" nella parte superiore della pagina. Un thread di commenti su una domanda vecchia di 7 anni probabilmente non attirerà la giusta attenzione su di essa. L'aggiunta di un collegamento a questa domanda e risposta, o anche a questa risposta in particolare, va bene ovviamente. Puoi usare il pulsante "condividi" in fondo a ogni post per questo.

— GolezTrol

È vero? I cookie generati dal cliente non sembrano essere trasferiti. Se si fa document.cookie="foo=bar"seguito da fetch("/foobar", {credentials: 'include'} )non viene inviato alcun cookie contenente foo=bar. Ho appena provato quel codice direttamente su questo sito usando DevTools e la console.

— oligofren

Sì, è vero, dice anche la documentazione , ma ci sono alcune specifiche che possono causare questo, come l'attributo expires mancante.

— GolezTrol

1

@MarinosAn Sì, è possibile. Ma la mia risposta è stata un po 'breve quando si trattava degli attributi che modificano il comportamento del cookie, quindi l'ho ampliata un po' ora.

— GolezTrol

4

Sì, puoi creare cookie che possono essere letti solo lato server. Questi sono chiamati cookie "Solo HTTP", come già spiegato in altre risposte
No, non c'è modo (lo so) di creare "cookies" che possono essere letti solo dal lato client. I cookie hanno lo scopo di facilitare la comunicazione client-server.
MA, se vuoi qualcosa COME "client-only-cookies" c'è una semplice risposta: usa "Local Storage".

L'archiviazione locale è in realtà sintatticamente più semplice da utilizzare rispetto ai cookie. Un buon semplice riepilogo dei cookie rispetto all'archiviazione locale può essere trovato su:

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

Un punto: potresti usare i cookie creati in JavaScript per memorizzare le cose relative alla GUI che ti servono solo sul lato client. MA il cookie viene inviato al server per OGNI richiesta effettuata, entra a far parte delle intestazioni della richiesta http facendo in modo che la richiesta contenga più dati e quindi più lenta da inviare.

Se la tua pagina ha 50 risorse come immagini, file css e script, il cookie viene (in genere) inviato con ogni richiesta. Maggiori informazioni in Ogni richiesta web invia i cookie del browser?

L'archiviazione locale non presenta questi svantaggi legati al trasferimento dei dati, non invia dati. È grande.

— Panu Logic
fonte