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

Quelle est la différence entre la création de cookies sur le serveur et sur le client? Sont ces appelé serveur de cookies côté client et côté des cookies? Est-il un moyen de créer des cookies qui ne peuvent être lus sur le serveur ou sur le client?

  • Il n'y a pas une telle chose comme "côté serveur cookie' vs 'côté client cookie". Il y a seulement des cookies, des paires nom/valeur envoyée dans les en-têtes HTTP, avec à la fois les demandes et les réponses.
  • Éventuellement référencement des variables de Session, qui contiennent des données sur le serveur. Habituellement, il ya toujours un identifiant de session qui est tenu comme un cookie.
  • En toute probabilité, la question se réfère aux différentes façons de les cookies sont codées sur le côté serveur (c'est à dire la façon dont ils sont codés dans le "Cookie" et "Set-Cookie" en-tête de réponse) et sur le côté client (c'est à dire la façon dont ils sont codés dans le "Cookie" en-tête de requête - variable $Path et tout ce jazz). Voir RFC 2109
InformationsquelleAutor Rahul | 2011-08-03
  1. 128

    COOKIES HTTP

    Les Cookies sont des paires clé/valeur utilisés par les sites web de stocker des informations d'état sur le navigateur.
    Disons que vous avez 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.

    Navigateur demande exemple:

    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 témoins foo=10 et bar=20 sont stockés sur le navigateur. Le second viendra à échéance le 30 septembre.
    À chaque demande ultérieure, le navigateur va envoyer les cookies sur le serveur.

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

    SESSIONS: côté Serveur cookies

    Côté serveur cookies sont connus comme des "sessions". Le site web, dans ce cas, les magasins un seul cookie sur le navigateur contenant un Identifiant de Session unique. Les informations d'état (foo=10 et bar=20 ci-dessus) sont stockés sur le serveur et l'Identifiant de Session est utilisé pour faire correspondre la demande avec les données stockées sur le serveur.

    Des exemples de l'utilisation de la

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

    Avantages et les Inconvénients

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

    Cookie Pour:

    • évolutivité: toutes les données sont stockées dans le navigateur de sorte que chaque demande peut passer par un équilibrage de charge pour les différents serveurs web et vous avez toutes les informations nécessaires pour exécuter la demande;
    • ils peuvent être consultés via le javascript sur le navigateur;
    • de ne pas être sur le serveur, ils survivront redémarrage du serveur;
    • Reposante: les demandes ne dépend pas de l'état du serveur

    Cookie Contre:

    Session Pour:

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

    Session Inconvénients:

    • plus difficile à l'échelle
    • sur le web redémarrage du serveur, vous pouvez perdre toutes les sessions ou non en fonction de la mise en œuvre
    • pas Reposante
    • session pour: secure?
    • pourquoi des séances plus sécurisé? Si vous envoyer le cookie de session sur http, il peut être détourné. Si le site utilise le protocole https de la sécurité devrait être la même aussi longtemps que vous utilisez secure cookies (chiffré, signé, etc...)
    • Les Cookies inconvénients: fait de chaque demande de plus grand, qui pourrait affecter les performances. Je ne connais pas les chiffres mais puisque les gens utilisent cookieless domaines de choses je suppose que c'est non trivial.
    • Largement trompeuse réponse - les séances ne sont pas les cookies. en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#HTTP_session Vous pouvez avoir des variables de session, en fonction du mode de gestion de session est mise en œuvre sur le serveur. Généralement, vous avez un ou plusieurs cookies qui sont liées à la gestion de session, par la tenue de l'identifiant de session. Aussi le REPOS et le repos, n'ont rien à voir avec les cookies de session ou de la gestion de REPOS et le repos, les implémentations peuvent avoir des sessions et des cookies.
    • ça dépend... Si le backend (par exemple, l'article de service) doit faire une demande à disons que l'utilisateur du service, qui stocke tous les cours de la session-id, puis ce sera la cause de la performance et l'évolutivité des problèmes. Mais si les cookies, les sessions ne sont pas stockées n'importe où sur l'arrière-plan, mais seulement le secret de l'algorithme de signature, puis l'article-service peut dire "oui, cher client, le cookie vous est donné par l'utilisateur du service est légitime" et de répondre immédiatement sans faire une demande à l'utilisateur de service
    • merci pour la nécromancie. Cependant à quoi vous faites allusion sont la première et la troisième partie des cookies. Et représentant un tiers de cookie (un à partir de ce que vous appelez un utilisateur de service) en tant que première partie de cookies (un cookie provenant de ce que vous appelez l'article de service). En tout cas, mon intervention est liée au fait que les variables de session qui ont peu à voir avec les cookies, vous pouvez avoir des variables de session tant que vous êtes en mesure d'identifier la session. Aussi ce que vous suggérez a le potentiel de détournement de session de la vulnérabilité.
    • dans mon expérience, les variables de session sont mis en œuvre en utilisant une certaine forme d'un id de session cookie la plupart du temps (PHP, Java, .NET), une autre option que j'ai vu, c'est l'ajout de l'id de session dans l'Url, mais cette approche a aussi le détournement de session risques. Les url peuvent être copiés et collés, lire à partir d'un malveillant js script, etc... Pour faire des cookies sécurisé, vous devez toujours utiliser le protocole https et définir httpOnly et de sécuriser les drapeaux afin de les rendre illisibles js. BTW, il existe d'autres moyens de mettre en œuvre des séances?
    • ce que je faisais référence est essentiellement, JWT. Vous pouvez l'avoir à l'intérieur d'un en-tête d'Autorisation ou à l'intérieur d'un Cookie un. L'Utilisateur du Service peut ainsi être une ressource externe/fournisseur comme le Serveur d'Autorisation dans OAuth2. Le cookie est utilisé par le site web seulement pour économiser de l'état sur une actualisation. Vous pourriez aussi bien utiliser localstorage pour que (rappelez-vous, même si le JWT n'a pas été supprimé, le jeton expirera et sera inutile après un certain temps)
    • Voir stackoverflow.com/questions/35054840/... je n'étais pas dire que les sessions ne sont pas généralement mis en œuvre avec les cookies, mais qu'il existe d'autres options pour la gestion des sessions, par conséquent, il est erroné de parler de variables de session côté serveur cookies. Je faisait aussi référence à JWT quand je l'ai dit dans l'année 2017 dans le commentaire ci-dessus "le REPOS et le repos, les implémentations peuvent avoir des sessions et des cookies". Bien que certains puristes pourraient faire valoir que ce n'est pas la bonne façon de mettre en œuvre une API REST.

    InformationsquelleAutor filippo
  2. 52

    Tu veux sans doute dire la différence entre Seulement les cookies Http et leur contre-partie?

    Http Uniquement les cookies ne sont pas accessibles (lu ou écrit) dans le côté client en JavaScript, uniquement côté serveur. Si le Http Seule option n'est pas activée, ou le cookie est créé dans (côté client) de JavaScript, les cookies peuvent être lues et écrites dans (côté client) du JavaScript côté serveur.

    InformationsquelleAutor nikc.org
  3. 29

    Tous les cookies sont client et serveur

    Il n'y a pas de différence. Régulièrement un cookie peut être réglé côté serveur ou côté client. Le "classique" cookie sera envoyé avec chaque demande. Un cookie est défini par le serveur, sera envoyé au client, dans une réponse. Le serveur n'envoie le cookie lorsqu'il est explicitement défini ou modifié, alors que le client envoie le cookie sur chaque demande.

    Mais essentiellement, c'est le même cookie.

    Mais, le comportement peut changer

    Un cookie est fondamentalement un name=value paire, mais après la valeur peut être un tas de semi-colon séparés attributs qui affectent le comportement du témoin si il est donc mis en œuvre par le client (ou le serveur).
    Ces attributs peuvent être de durée de vie, le contexte et les divers paramètres de sécurité.

    HTTP seule (n'est pas serveur uniquement)

    L'un de ces attributs peuvent être définis par un serveur pour indiquer que c'est un cookie HTTP uniquement. Cela signifie que le cookie est envoyé en arrière et en avant, mais il ne sera pas disponible en JavaScript. Notez, cependant, que le cookie est toujours là! C'est seulement un construit dans la protection dans le navigateur, mais si quelqu'un serait d'utiliser un ridiculement vieux navigateur comme IE5, ou certains client personnalisé, ils peuvent lire le cookie!

    De sorte qu'il semble comme il y a des "cookies de serveur", mais il n'existe pas réellement. Ces cookies sont toujours envoyé au client. Sur le client, il n'existe aucun moyen pour empêcher un témoin d'être envoyé au serveur.

    Solutions pour atteindre " seulement-ness

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

    • salut, je suis très nouveau à ces concepts et d'avoir quelques doutes. Je suis désolé, mes questions peuvent paraître idiot mais je vais quand même demander. Toute aide est très appréciée - un témoin Peut, qui a été mis sur le côté client, être envoyé à n'importe quel domaine ? Je veux dire, n'est-ce pas une menace pour la sécurité? Aussi, comment ça fonctionne avec les clients de navigateur, comme Api, etc?
    • Salut @KaranChadha , si vous avez une question, merci de la poser comme une question à l'aide de la "Poser une Question" bouton en haut de la page. Un commentaire sur un fil de 7 ans la question ne sera probablement pas tirer la bonne quantité d'attention à elle. Ajout d'un lien vers ce Q&A, ou même pour cette réponse plus précisément, fin de cours. Vous pouvez utiliser le bouton 'partager' au bas de chaque post pour que.
    • Est-ce vrai? Généré par un Client cookies ne semblent pas être transférés. Si document.cookie="foo=bar" suivie parfetch("/foobar", {credentials: 'include'} ) il n'y a pas de cookie envoyé contenant foo=bar. Juste essayé ce code directement sur ce site en utilisant DevTools et la console.
    • Oui c'est vrai, dit aussi les docs, mais il ya quelques détails qui peut en être la cause, comme le manque expire attribut.
    • "Il n'y a pas de différence" : Peut-client de remplacer un serveur de cookie ensemble?
    • Oui, il peut. Mais ma réponse était un peu bref quand il est venu pour les attributs de modifier le comportement du témoin, alors j'ai élargi un peu maintenant.

    InformationsquelleAutor GolezTrol
  4. 3

    1. Oui, vous pouvez créer des cookies qui peuvent être lus uniquement sur le côté serveur. Ces derniers sont appelés "HTTP Uniquement" des cookies, comme expliqué dans d'autres réponses déjà

    2. Non, il n'existe aucun moyen (que je connais) pour créer des "cookies" qui peut être lu que sur le côté client. Les Cookies sont destinées à faciliter la communication client-serveur.

    3. MAIS, si vous voulez quelque chose COMME "client seulement-cookies" il y a une réponse simple: Utiliser le "Stockage Local".

    Local de Stockage est en fait la syntaxe est plus simple à utiliser que les cookies. Un bon résumé simple de cookies vs local de stockage peut être trouvé à:

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

    Un point: Vous pouvez utiliser les cookies créés en JavaScript pour stocker GUI de choses se rapportant à vous seulement besoin sur le côté client. MAIS le cookie est envoyé au serveur pour CHAQUE demande, il devient une partie de la http-en-têtes de demande donc de faire la demande de contenir plus de données et donc plus lent à envoyer.

    Si votre page a 50 ressources comme des images et la css de fichiers et les scripts alors le cookie est (généralement) envoyé avec chaque demande. En savoir plus sur ce en Est-ce que chaque requête web envoyer les cookies de votre navigateur?

    Stockage Local ne dispose pas de ces données-transfert des inconvénients, il n'envoie pas de données. Il est grand.

    InformationsquelleAutor Panu Logic