Qual é a diferença entre o cookie do servidor e o cookie do cliente?

120

Qual é a diferença entre criar cookies no servidor e no cliente? Eles são chamados de cookies do lado do servidor e cookies do lado do cliente? Existe uma maneira de criar cookies que só podem ser lidos no servidor ou no cliente?

http cookies session-cookies

— Rahul
fonte

15

Não existe 'cookie do lado do servidor' vs 'cookie do lado do cliente'. Existem apenas cookies, pares de nome / valor enviados em cabeçalhos HTTP com solicitações e respostas.

— Dan Grossman

1

Possivelmente referenciando variáveis de sessão, que mantêm dados no servidor. Normalmente, ainda há um identificador de sessão que é mantido como um cookie do lado do cliente.

— AndrewR

Com toda a probabilidade, a pergunta se refere às diferentes maneiras como os cookies são codificados no lado do servidor (ou seja, a maneira como são codificados no cabeçalho de resposta 'Cookie' e 'Set-Cookie') e no lado do cliente (ou seja, a maneira como eles está codificado no cabeçalho do pedido 'Cookie' - variável $ Path e todo esse jazz). Consulte RFC 2109

— Ophir Radnitz

146

COOKIES HTTP

Cookies são pares de chave / valor usados por sites para armazenar informações de estado no navegador. Digamos que você tenha um site (example.com), quando o navegador solicita uma página da Web, o site pode enviar cookies para armazenar informações no navegador.

Exemplo de solicitação de navegador:

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

Exemplo de resposta do servidor:

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

Aqui, dois cookies foo = 10 e bar = 20 são armazenados no navegador. O segundo expira em 30 de setembro. Em cada solicitação subsequente, o navegador enviará os cookies de volta ao servidor.

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

SESSÕES: Cookies do lado do servidor

Os cookies do lado do servidor são conhecidos como "sessões". O site, neste caso, armazena um único cookie no navegador contendo um identificador de sessão único. As informações de status (foo = 10 e bar = 20 acima) são armazenadas no servidor e o identificador de sessão é usado para corresponder a solicitação aos dados armazenados no servidor.

Exemplos de uso

Você pode usar sessões e cookies para armazenar: dados de autenticação, preferências do usuário, o conteúdo de um gráfico em um site de comércio eletrônico, etc ...

Prós e contras

Abaixo prós e contras das soluções. Estas são as primeiras que me vêm à mente, certamente existem outras.

Cookie Pros:

escalabilidade: todos os dados são armazenados no navegador para que cada solicitação possa passar por um balanceador de carga para diferentes servidores da web e você tenha todas as informações necessárias para atender à solicitação;
eles podem ser acessados via javascript no navegador;
não estando no servidor, eles sobreviverão às reinicializações do servidor;
RESTful: as solicitações não dependem do estado do servidor

Cookie Contras:

o armazenamento é limitado a 80 KB (20 cookies, 4 KB cada)
cookies seguros não são fáceis de implementar: dê uma olhada no papel Um protocolo de cookies seguros

Prós da sessão:

geralmente mais fácil de usar, em PHP provavelmente não há muita diferença.
armazenamento ilimitado

Contras da sessão:

mais difícil de escalar
no servidor web reinicia você pode perder todas as sessões ou não dependendo da implementação
não RESTful

— filippo
fonte

profissionais da sessão secure:?

— user2167582

1

por que sessões mais seguras? Se você enviar o cookie de sessão por http, ele poderá ser sequestrado. Se o site usar https, a segurança deve ser a mesma, desde que você use cookies seguros (criptografados, assinados, etc ...)

— filippo

1

Cookies contras: torna cada solicitação maior, potencialmente afetando o desempenho. Não sei os números, mas como as pessoas usam domínios sem cookies para as coisas, presumo que não seja trivial.

— maniexx

5

Resposta amplamente enganosa - as sessões não são cookies. en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#HTTP_session Você pode ter variáveis de sessão, dependendo de como o gerenciamento de sessão é implementado no servidor. Normalmente você tem um ou mais cookies que estão relacionados ao gerenciamento da sessão, mantendo o identificador da sessão. Além disso, REST e RESTful não têm nada a ver com cookies ou gerenciamento de sessão - as implementações REST e RESTful podem ter sessões e cookies.

— Zlatin Zlatev de

2

Consulte stackoverflow.com/questions/35054840/… Eu não estava dizendo que as sessões não são normalmente implementadas com cookies, mas que existem outras opções para gerenciamento de sessão, portanto, é errado falar sobre variáveis de sessão como cookies do lado do servidor. Eu também estava me referindo ao JWT quando disse no ano de 2017 no comentário acima que "implementações REST e RESTful podem ter sessões e cookies". Embora alguns puristas possam argumentar que esta não é a maneira adequada de implementar uma API REST.

— Zlatin Zlatev

57

Você provavelmente quer dizer a diferença entre cookies Http Only e sua contraparte?

Http Apenas cookies não podem ser acessados (lidos ou gravados) em JavaScript do lado do cliente, apenas do lado do servidor. Se o sinalizador Http Only não estiver definido, ou o cookie for criado em (lado do cliente) JavaScript, o cookie pode ser lido e gravado em (lado do cliente) JavaScript, bem como no lado do servidor.

— nikc.org
fonte

38

Todos os cookies são cliente e servidor

Não há diferença. Um cookie regular pode ser definido no lado do servidor ou no lado do cliente. O cookie 'clássico' será enviado de volta com cada solicitação. Um cookie que é definido pelo servidor, será enviado ao cliente em uma resposta. O servidor só envia o cookie quando ele é explicitamente definido ou alterado, enquanto o cliente envia o cookie em cada solicitação.

Mas essencialmente é o mesmo cookie.

Mas, o comportamento pode mudar

Um cookie é basicamente um name=valuepar, mas após o valor pode haver um monte de atributos separados por ponto e vírgula que afetam o comportamento do cookie se for implementado pelo cliente (ou servidor). Esses atributos podem ser sobre o tempo de vida, contexto e várias configurações de segurança.

Apenas HTTP (não é apenas servidor)

Um desses atributos pode ser definido por um servidor para indicar que é um cookie somente HTTP. Isso significa que o cookie ainda é enviado e enviado, mas não estará disponível em JavaScript. Observe, porém, que o cookie ainda está lá! É apenas uma proteção embutida no navegador, mas se alguém usasse um navegador ridiculamente antigo como o IE5, ou algum cliente personalizado, eles poderiam realmente ler o cookie!

Parece que existem 'cookies do servidor', mas na verdade não existem. Esses cookies ainda são enviados ao cliente. No cliente, não há como evitar que um cookie seja enviado ao servidor.

Alternativas para alcançar 'unicidade'

Se você quiser armazenar um valor apenas no servidor ou apenas no cliente, precisará de algum outro tipo de armazenamento, como um arquivo ou banco de dados no servidor, ou Armazenamento local no cliente.

— GolezTrol
fonte

oi, sou muito novo nesses conceitos e tenho algumas dúvidas. Sinto muito, minhas perguntas podem parecer bobas, mas ainda assim vou perguntar. Qualquer ajuda, é muito apreciada - Um cookie, que foi definido no lado do cliente, pode ser enviado para qualquer domínio? Quer dizer, isso não é uma ameaça à segurança? Além disso, como funciona com clientes sem navegador, como APIs, etc.?

— Karan Chadha

1

Olá @KaranChadha, se você tiver uma pergunta, faça-a como uma pergunta formal usando o botão 'Fazer pergunta' no topo da página. Um tópico de comentário sobre uma questão de 7 anos provavelmente não chamará a atenção para ela. Adicionar um link para este Q&A, ou mesmo para esta resposta especificamente, é claro. Você pode usar o botão 'compartilhar' na parte inferior de cada postagem para isso.

— GolezTrol de

Isso é verdade? Os cookies gerados pelo cliente não parecem ser transferidos. Se fizer document.cookie="foo=bar"seguido de fetch("/foobar", {credentials: 'include'} ), nenhum cookie será enviado contendo foo=bar. Tentei esse código diretamente neste site usando DevTools e o console.

— oligofren

Sim, é verdade, diz também os documentos , mas existem alguns detalhes que podem causar isso, como a falta do atributo expires.

— GolezTrol

1

@MarinosAn Sim, pode. Mas minha resposta foi um pouco breve no que diz respeito aos atributos que modificam o comportamento do cookie, então a expandi um pouco agora.

— GolezTrol

4

Sim, você pode criar cookies que só podem ser lidos no lado do servidor. Eles são chamados de cookies "Apenas HTTP", conforme explicado em outras respostas já
Não, não há como (eu sei) criar "cookies" que possam ser lidos apenas no lado do cliente. Os cookies têm como objetivo facilitar a comunicação cliente-servidor.
MAS, se você quiser algo como "cookies somente para clientes", há uma resposta simples: Use "Armazenamento local".

O armazenamento local é sintaticamente mais simples de usar do que os cookies. Um bom resumo simples de cookies vs. armazenamento local pode ser encontrado em:

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

Um ponto: você pode usar cookies criados em JavaScript para armazenar coisas relacionadas à GUI que você só precisa no lado do cliente. MAS o cookie é enviado ao servidor para TODAS as solicitações feitas, ele se torna parte dos cabeçalhos da solicitação http, fazendo com que a solicitação contenha mais dados e, portanto, mais lento para enviar.

Se a sua página tiver 50 recursos como imagens e arquivos css e scripts, o cookie (normalmente) é enviado com cada solicitação. Mais sobre isso em Todas as solicitações da web enviam cookies do navegador?

O armazenamento local não tem essas desvantagens relacionadas à transferência de dados, ele não envia dados. Isso é ótimo.

— Panu Logic
fonte