Entenda de vez Sessions e Cookies

Olá pessoal, tudo bem com vocês ?! Espero que sim !

Acredito que você desenvolvedor use demais sessions e cookies, porém, não faz nem ideia como eles funcionam por debaixo dos panos. Já que eles são um pouco parecidos em sua essência, é de suma IMPORTÂNCIA você saber como funciona cada um para poder saber qual usar em determinadas situações.

Vamos deixar de blá blá blá e vamos ao que interessa.

Porque esses trecos existem?

Você já deve tá careca de saber que o protocolo HTTP é stateless, ou seja, ele não guarda o estado/conexão. Toda vez que for solicitada uma página no servidor web sempre será feita uma nova requisição e uma nova resposta, sendo elas independentes uma da outra e com um determinado tempo de vida.

Em resumo: o servidor Web não consegue identificar se duas requisições vieram de um mesmo navegador.

Por isso que existem os Cookies e Sessions!

Antes de começar

Antes de iniciar a falar de um ou de outro, já vou logo adiantando que ambos exercem a mesma tarefa de armazenar dados/informações de sua página web e “transitar” essas informações entre browser e servidor. Cada um possui suas peculiaridades que o torna melhor em determinados cenários.

IMPORTANTE: vou utilizar o navegador Google Chrome nos exemplos deste post. Caso você queira usar outro navegador não tem problema, o processo é muito semelhante.

Cookies

Também chamado de HTTP Cookies, são informações armazenadas diretamente no lado cliente, no nosso caso, no nosso tão lindo e maravilhoso navegador. Você pode acessar e até modificar facilmente os cookies do seu navegador.

1. Abra o seu Google Chrome;
2. Vá no menu, aqueles três pontinhos que fica localizado no lado superior direito;
3. Selecione a opção Mais Ferramentas;
4. Por fim, selecione a opção Ferramentas do Desenvolvedor;
5. Clique na Guia Application;

DICA: você pode abrir rapidamente as Ferramentas do Desenvolvedor do Google Chrome pelo atalho CTRL + SHIFT+ I

Se você seguiu os passos direitinho, deve abrir na parte inferior do seu navegador uma janelinha como essa abaixo:

Você pode perceber que dentro da seção Storage tem um item chamado Cookies, como ilustra na imagem abaixo.

Você pode acessar os cookies de QUALQUER site. Para esse exemplo, acessei o site do Yii Academy (você pode fazer o mesmo se quiser =D).

Clique na setinha ao lado do ícone do biscoitinho mordido para mostrar todos os cookies que esse site está utilizando, e você terá uma lista parecida com essa:

Como você deve ter percebido, nessa lista temos cookies do Yii Academy, Google, Facebook e dentre outros. Os cookies são segmentados por domínio, ou seja, cada domínio terá seus cookies totalmente independentes.

Vamos abrir os cookies do domínio http://www.yiiacademy.com.br e ver o que tem lá:

Nesse momento você consegue ver uma série de informações que um cookie pode ter, mas, quero que você nesse momento se atente as colunas destacadas na imagem abaixo:

Name: é o nome, identificador ou chave do cookie. Caso você precise alterar algo nesse cookie ou até mesmo recuperar informações dele, você deve utilizar o name para “pegá-lo”.

Value: uma string que representa o valor do cookie. Percebam que por medidas de segurança os valores de todos os cookies estão criptografados. Posteriormente vou dizer o porque disso, por enquanto só entenda que isso é o valor dele.

Expires / Max Age: essa coluna representa o “tempo de vida” do cookie. Isso mesmo! Perceba que o primeiro cookie da lista (o __cfduid) vai “morrer” no dia e hora 2019-09-25T00:35:29.254Z, para os que não estão acostumados com esse formato: 25/09/2019 às 00:35:29

IMPORTANTE: de acordo com a RFC 2109 você só pode ter no máximo 50 cookies por domínio, cada um no tamanho máximo de 4096 bytes.

Algumas versões de browsers dão suporte a tamanhos maiores que esse, mas, não é muito bom fugir disso por questões de segurança e performance.

Nesse link você pode consultar os limites de valores de cookies: http://browsercookielimits.squawky.net

Por mais que você feche o navegador e até desligue o seu computador, os cookies ficarão armazenados no seu navegador. Ele só será removido nas seguintes situações:

• Se o tempo de vida dele for atingido;
• Se você for lá nas ferramentas de desenvolvedor e remover manualmente;
• Se você desinstalar o seu navegador;
• Se você formatar seu computador;
• Se sua máquina explodir e coisas parecidas rsrsrs;

Toda as vezes que o site for acessado, os cookies deste domínio irão também nos cabeçalhos da requisição HTTP;

Como falei anteriormente esses cookies podem ser facilmente manipulados. Posso muito bem dá 2 cliques no value e alterar o valor de um determinado cookie, veja abaixo:

Isso torna o uso de cookies inseguro. Mas se você utilizar as estratégias corretas de criptografia, como foi utilizado nesses exemplos, poderá usá-lo sem medo.

Enviado Cookies para Servidor Web

Agora que você já aprendeu como visualizar os cookies, viu as informações que compõem um cookie e até já alterou o valor de um cookie, vamos entender como esses dados são enviados para o servidor web.

Como mencionei no início do post, os cookies são chamados de HTTP Cookies. Isso porque os cookies são transitados entre browser e servidor web pelo nosso lindo protocolo HTTP, tornando-o multiplataforma e independente de linguagem de programação.

Ainda com as Ferramentas de Desenvolvedor do Google Chrome aberto, vá na guia Network, clique na linha que contém o endereço do nosso blog www.yiiacademy.com.br e localize painel do lado direito os cabeçalhos da Requisição HTTP (Request Headers):

Note que TODOS os cookies do domínio yiiacademy.com.br estão sendo enviados no cabeçalho da Requisição HTTP:

Cookie: __cfduid=d27fa8bcf38ca6f31548b088fc218942f1537841436; _ga=GA1.3.1388725536.1537841437; _gid=GA1.3.428962202.1537841437; _gat=1

Cada cookie é um par de chave/valor, separados por um “ ;” (espaço + ponto-vírgula);

IMPORTANTE: como você deve saber, o protocolo HTTP envia informações em texto puro para seu destino, portanto, os cookies são enviados também em texto puro seguindo as convenções do protocolo HTTP. Não irei me aprofundar nisso para não perder o foco.

Quando utilizarei um Cookie?

Um exemplo bastante utilizado hoje em dia é aquela opção Lembrar-me nesse PC, Lembrar-me e textos como esse naqueles formulários de login por aí. Esse recurso que esses formulários usam, nada mais é do que um token de autenticação que é guardado em um cookie para que você não precise toda vez que entrar no sistema informar suas credenciais.

Vou te mostrar como isso funciona no GitLab! Vou abrir aqui a página de Login do GitLab já com as Ferramentas de Desenvolvedor aberta. Por haver muitos cookies, note que eu filtrei apenas os cookies que tenha no nome do domínio “gitlab”.

Vou inserir minhas credenciais e marcar o checkbox Remember me, para que toda vez que eu entrar no gitlab já “cair logado”:

Veja que depois de logado no gitlab apareceu um novo cookie chamado “remember_user_token” com um token bem ilegível para nós no seu valor e que se expira em 2018-10-09T20:22:30.530Z.

Toda vez que eu entrar na página de login do Gitlab vai acontecer o seguinte processo:

• O navegador vai enviar esse token de autenticação via HTTP para o servidor WEB;
  
  
• A aplicação (Java, PHP, Ruby, JS e etc) vai validar esse token para saber se EU sou EU mesmo;
  
  
• Vai me autenticar no sistema do GitLab;
  
  
• Vai “responder” para o navegador dizendo que EU sou EU mesmo criando um cookie de sessão chamado “_gitlab_session” (já já iremos falar sobre esse camadada);
  
  
• E por fim, vai me redirecionar para página principal e restrita do GitLab;

Aqui eu te mostro como o Cookie de Sessão é criado. Perceba que essa informação é vista no Response Headers (Cabeçalhos de Resposta), porque o nosso é servidor web é quem “pede” para que seja criado um cookie com as devidas informações.

Sessions

As sessões são praticamente a mesma coisa do cookie, só que armazenado no lado servidor. Então, imagina este mesmo cenário que foi abordado nos cookies, só que feito no lado servidor.

Como visto no exemplo do gitlab, as sessões andam de mãos dadas com cookies. Eles armazenam dados sensíveis (ou não) no lado servidor enquanto no lado cliente (navegador) armazena somente um identificador da sessão.

Quando submetemos o formulário de login do GitLab ocorre o seguinte processo:

Detalhando o que a imagem acima ilustra:

• O navegador vai enviar os dados de login e senha para o servidor Web;
  
  
• A aplicação (Java, PHP, Ruby, JS e etc) vai validar esses dados enviados pelo cliente (Navegador);
  
  
• O GitLab vai consultar da base de dados deles se o meu login e senha estão corretos;
  
  
• Depois de verificado meus dados, serão feitas algumas validações adicionais, como por exemplo: se sou um usuário ativo, se uso plano pago, se estou devendo e etc;
  
  
• Será feita a autenticação de fato no lado servidor e será criado um arquivo de sessão no servidor web, que nada mais é do que um arquivo texto com um nome/chave/identificador. Neste caso chama-se _gitlab_session;
  
  
• O servidor web vai “responder” solicitando que seja criado um cookie de sessão com o mesmo identificador da sessão “_gitlab_session”, como visto anteriormente;
  
  
• E por fim, vai me redirecionar para página principal e restrita do GitLab;

Quando você tentar novamente acessar a mesma página de login, ou até mesmo um página restrita do gitlab, veja o processo que irá acontecer por debaixo dos panos:

Detalhando o que a imagem acima ilustra:

• O navegador vai enviar agora o Cookie de Sessão, ao invés dos dados de login e senha;
  
  
• A aplicação vai detectar que existe um cookie de sessão sendo enviado e que “dá match” com o arquivo de sessão no nosso servidor;
  
  
• Sabendo que “deu match” anteriormente, sua aplicação sabe que eu sou eu mesmo e me autentica pulando tooooooooodddoooss aqueles outros passos que são bem mais custosos para o servidor;

O Cookie de Sessão _gitlab_session é o grande protagonista dessa comunicação! Toda vez que o gitlab receber esse cookie de sessão, ele vai poder recuperar facilmente e rapidamente meus dados como: nome, email, avatar, senha, grupo de acesso e etc, e não vai precisar fazer todo aquele processo novamente.

Dica boa e Barata!

Quando construímos uma aplicação que possua uma autenticação até podemos permitir que algumas informações sejam armazenadas em um cookie, porém, dados mais “sensíveis” como login, e-mail e senha são mais seguros e recomendados a serem guardadas em sessões. NÃO É SEGURO que esse tipo de informação fique “transitando” na Web.

E aí, conseguiram entender agora como funcionam esses 2 trecos? Te ajudei a compreender como funciona por debaixo dos panos? Espero que sim!

Se você acha que eu devo fazer um vídeo com esse assunto como complemento e mais exemplos sobre cookies e session, deixa no comentário!

Um forte abraço!