Quelle est la différence entre un cookie côté serveur et un cookie côté client?

120

Quelle est la différence entre la création de cookies sur le serveur et sur le client? S'agit-il de cookies côté serveur et de cookies côté client? Existe-t-il un moyen de créer des cookies qui ne peuvent être lus que sur le serveur ou sur le client?

http cookies session-cookies

— Rahul
source

15

Il n'existe pas de «cookie côté serveur» ou de «cookie côté client». Il n'y a que des cookies, des paires nom / valeur envoyés dans les en-têtes HTTP avec à la fois des demandes et des réponses.

— Dan Grossman

1

Peut-être référençant des variables de session, qui contiennent des données sur le serveur. Habituellement, il existe toujours un identifiant de session qui est conservé en tant que cookie côté client.

— AndrewR

Selon toute vraisemblance, la question se réfère aux différentes façons dont les cookies sont encodés côté serveur (c'est-à-dire la façon dont ils sont encodés dans l'en-tête de réponse 'Cookie' et 'Set-Cookie') et côté client (c'est-à-dire la façon dont ils 'est encodé dans l'en-tête de requête' Cookie '- variable $ Path et tout ce jazz). Voir RFC 2109

— Ophir Radnitz

146

COOKIES HTTP

Les cookies sont des paires clé / valeur utilisées par les sites Web pour stocker des informations d'état sur le navigateur. Supposons que vous ayez un site Web (example.com), lorsque le navigateur demande une page Web, le site Web peut envoyer des cookies pour stocker des informations sur le navigateur.

Exemple de demande de navigateur:

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

Exemple de réponse du serveur:

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

Ici, deux cookies foo = 10 et bar = 20 sont stockés sur le navigateur. Le second expirera le 30 septembre. Dans chaque demande ultérieure, le navigateur renverra les cookies au serveur.

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

SESSIONS: cookies côté serveur

Les cookies côté serveur sont appelés «sessions». Dans ce cas, le site Web stocke un cookie unique sur le navigateur contenant un identifiant de session unique. Les informations d'état (foo = 10 et bar = 20 ci-dessus) sont stockées sur le serveur et l'identifiant de session est utilisé pour faire correspondre la demande avec les données stockées sur le serveur.

Exemples d'utilisation

Vous pouvez utiliser à la fois des sessions et des cookies pour stocker: les données d'authentification, les préférences de l'utilisateur, le contenu d'un graphique dans un site e-commerce, etc ...

Avantages et inconvénients

Ci-dessous les avantages et les inconvénients des solutions. Ce sont les premiers qui me viennent à l'esprit, il y en a sûrement d'autres.

Avantages des cookies:

évolutivité: toutes les données sont stockées dans le navigateur afin que chaque requête puisse passer par un équilibreur de charge vers différents serveurs Web et vous disposez de toutes les informations nécessaires pour répondre à la requête;
ils sont accessibles via javascript sur le navigateur;
n'étant pas sur le serveur, ils survivront aux redémarrages du serveur;
RESTful: les requêtes ne dépendent pas de l'état du serveur

Contre les cookies:

le stockage est limité à 80 Ko (20 cookies, 4 Ko chacun)
les cookies sécurisés ne sont pas faciles à mettre en œuvre: jetez un œil au papier Un protocole de cookies sécurisés

Avantages de la session:

généralement plus facile à utiliser, en PHP il n'y a probablement pas beaucoup de différence.
stockage illimité

Inconvénients de la session:

plus difficile à mettre à l'échelle
au redémarrage du serveur web, vous pouvez perdre toutes les sessions ou non selon l'implémentation
pas de repos

— filippo
source

pros de la session: secure?

— user2167582

1

pourquoi des sessions plus sécurisées? Si vous envoyez le cookie de session via http, il peut être détourné. Si le site utilise https, la sécurité devrait être la même tant que vous utilisez des cookies sécurisés (cryptés, signés, etc.)

— filippo

1

Contre les cookies: agrandit chaque requête, affectant potentiellement les performances. Je ne connais pas les chiffres, mais comme les gens utilisent des domaines sans cookie pour des choses, je suppose que ce n'est pas trivial.

— maniexx

5

Réponse largement trompeuse - les sessions ne sont pas des cookies. fr.wikipedia.org/wiki/Hypertext_Transfer_Protocol#HTTP_session Vous pouvez avoir des variables de session, selon la manière dont la gestion de session est implémentée sur le serveur. Vous disposez généralement d'un ou plusieurs cookies liés à la gestion de session, en tenant l'identifiant de session. De plus, REST et RESTful n'ont rien à voir avec les cookies ou la gestion de session - les implémentations REST et RESTful peuvent avoir des sessions et des cookies.

— Zlatin Zlatev

2

Voir stackoverflow.com/questions/35054840/ ... Je ne disais pas que les sessions ne sont généralement pas implémentées avec des cookies, mais qu'il existe d'autres options pour la gestion de session, il est donc faux de parler de variables de session comme des cookies côté serveur. Je faisais également référence à JWT lorsque j'ai dit en 2017 dans le commentaire ci-dessus que "les implémentations REST et RESTful peuvent avoir des sessions et des cookies". Bien que certains puristes puissent affirmer que ce n'est pas la bonne façon d'implémenter une API REST.

— Zlatin Zlatev

57

Vous voulez probablement dire la différence entre les cookies Http Only et leur homologue?

Http Seuls les cookies ne sont pas accessibles (en lecture ou en écriture) dans JavaScript côté client, uniquement côté serveur. Si l'indicateur Http Only n'est pas défini ou si le cookie est créé en JavaScript (côté client), le cookie peut être lu et écrit dans JavaScript (côté client) ainsi que côté serveur.

— nikc.org
source

38

Tous les cookies sont client et serveur

Il n'y a pas de différence. Un cookie ordinaire peut être défini côté serveur ou côté client. Le cookie «classique» sera renvoyé à chaque demande. Un cookie défini par le serveur sera envoyé au client dans une réponse. Le serveur n'envoie le cookie que lorsqu'il est explicitement défini ou modifié, tandis que le client envoie le cookie à chaque demande.

Mais c'est essentiellement le même cookie.

Mais le comportement peut changer

Un cookie est essentiellement une name=valuepaire, mais après la valeur peut être un ensemble d' attributs séparés par des points-virgules qui affectent le comportement du cookie s'il est ainsi implémenté par le client (ou serveur). Ces attributs peuvent concerner la durée de vie, le contexte et divers paramètres de sécurité.

HTTP uniquement (n'est pas uniquement serveur)

Un de ces attributs peut être défini par un serveur pour indiquer qu'il s'agit d'un cookie HTTP uniquement. Cela signifie que le cookie est toujours envoyé dans les deux sens, mais il ne sera pas disponible en JavaScript. Notez cependant que le cookie est toujours là! Ce n'est qu'une protection intégrée dans le navigateur, mais si quelqu'un utilise un navigateur ridiculement vieux comme IE5, ou un client personnalisé, il peut en fait lire le cookie!

Il semble donc qu'il existe des «cookies de serveur», mais il n'y en a pas. Ces cookies sont toujours envoyés au client. Sur le client, il n'y a aucun moyen d'empêcher un cookie d'être envoyé au serveur.

Alternatives pour atteindre la `` seule-ness ''

Si vous souhaitez stocker une valeur uniquement sur le serveur, ou uniquement sur le client, vous avez besoin d'un autre type de stockage, comme un fichier ou une base de données sur le serveur ou un stockage local sur le client.

— GolezTrol
source

salut, je suis très nouveau dans ces concepts et j'ai quelques doutes. Je suis désolé, mes questions peuvent sembler idiotes mais je continuerai de la poser. Toute aide est très appréciée - Un cookie, qui a été défini du côté client, peut-il être envoyé à n'importe quel domaine? Je veux dire, n'est-ce pas une menace pour la sécurité? En outre, comment cela fonctionne-t-il avec les clients non-navigateur, comme les API, etc.?

— Karan Chadha

1

Bonjour @KaranChadha, si vous avez une question, posez-la sous forme de question formelle en utilisant le bouton «Poser une question» en haut de la page. Un fil de commentaires sur une question vieille de 7 ans n'attirera probablement pas l'attention. Ajouter un lien vers ce Q&A, ou même vers cette réponse en particulier, est bien sûr bien. Vous pouvez utiliser le bouton «partager» au bas de chaque article pour cela.

— GolezTrol

Est-ce vrai? Les cookies générés par le client ne semblent pas être transférés. Si vous faites document.cookie="foo=bar"suivi de fetch("/foobar", {credentials: 'include'} ), aucun cookie n'est envoyé contenant foo=bar. Je viens d'essayer ce code directement sur ce site en utilisant DevTools et la console.

— oligofren

Oui, c'est vrai, dit aussi la documentation , mais il y a des détails qui peuvent causer cela, comme l'attribut d'expiration manquant.

— GolezTrol

1

@MarinosAn Oui, c'est possible. Mais ma réponse a été un peu brève en ce qui concerne les attributs qui modifient le comportement du cookie, je l'ai donc élargie un peu maintenant.

— GolezTrol

4

Oui, vous pouvez créer des cookies qui ne peuvent être lus que côté serveur. Celles-ci sont appelées cookies "HTTP uniquement", comme expliqué dans d'autres réponses déjà
Non, il n'y a aucun moyen (à ma connaissance) de créer des "cookies" qui ne peuvent être lus que côté client. Les cookies sont destinés à faciliter la communication client-serveur.
MAIS, si vous voulez quelque chose comme des "cookies clients uniquement", il y a une réponse simple: utilisez "Stockage local".

Le stockage local est en fait syntaxiquement plus simple à utiliser que les cookies. Un bon résumé simple des cookies par rapport au stockage local peut être trouvé sur:

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

Un point: vous pouvez utiliser des cookies créés en JavaScript pour stocker des éléments liés à l'interface graphique dont vous n'avez besoin que du côté client. MAIS le cookie est envoyé au serveur pour CHAQUE requête effectuée, il fait partie des en-têtes de requête http, ce qui rend la requête contenant plus de données et donc plus lente à envoyer.

Si votre page contient 50 ressources telles que des images, des fichiers css et des scripts, le cookie est (généralement) envoyé avec chaque demande. Plus d'informations à ce sujet dans Chaque requête Web envoie-t-elle des cookies du navigateur?

Le stockage local n'a pas ces inconvénients liés au transfert de données, il n'envoie aucune donnée. C'est super.

— Panu Logic
source