Como aplicações web tratam sessões de usuários?

No princípio da Internet, os sites apenas serviam conteúdos estáticos aos usuários, contendo informações que eram difundidas para todos os usuários, sem levar em consideração em quem, o por quê, e o motivo de estarem ali vendo determinada informação.

Mas tudo começou a mudar com sites e páginas dinâmicas, e principalmente pelo primordial recurso que fez a Internet ser o que ela é hoje: Sessão de usuário.

Vamos entender um pouco mais sobre o que é e como aplicações Web gerenciam sessões de usuário, em um contexto generalizado, para simples entendimento.

Quando uma aplicação Web é acessada, não importa a tecnologia utilizada, por padrão, todas elas respondem a uma requisição de um navegador, e entregam um determinado conteúdo, seja estático, ou dinâmico.

O conteúdo estático, é aquele que não é modificado para os usuários, ao menos, com frequência, ou por usuário, como por exemplo, arquivos de javascript, arquivos de estilos (css), imagens, fotos, ícones, vídeos, e aplicativos específicos (applets, calculadoras, calendários, flash, etc).

Já o conteúdo dinâmico, ele tem a característica de ser processado durante o momento que o usuário faz a requisição. Um site que você entra em determinada página, e a cada vez que você acessa, o conteúdo está diferente; não porque foi atualizado por alguém, mas porque houve um processamento no mesmo momento da solicitação.

Nos primórdios das páginas dinâmicas, era bem comum você entrar em um site com uma cor azul, e de forma aleatória, entrar com um layout diferente, ou regionalizado aparecendo outros itens, ou até mesmo detectar se o usuário está no Brasil ou fora, e direcionar para a versão em outros idiomas.

Mas páginas dinâmicas não seriam tão proveitosas, quanto a principal invenção da Internet: A sessão de usuário.

O que é sessão de usuário? Nada mais é que a identificação de uma determinada requisição, e a alocação de variáveis para aquela primeira requisição, identificando o sequenciamento da continuidade de acessos daquela requisição inicial, podendo ser uma pessoa ou um robô.

Um navegador web, ao ser utilizado por um usuário, uma pessoa, como por exemplo, ao acessar o site do Google, o usuário digita "www.google.com", o navegador ficará na responsabilidade de realizar a requisição, e como ele faz esta requisição?

1. Primeiro ele resolve o texto "www.google.com" nos servidores de resolução de nomes de domínio, retornando um endereço IP, e então abre conexão TCP ao destino deste endereço, e envia a solicitação:

GET / HTTP/1.1

Host: www.google.com

Com isto, o servidor web ficará responsável em responder com o conteúdo, não importa se seja estático ou dinâmico, isto depende de sua tecnologia, mas irá responder, de fato, conforme o padrão da Web, que seria algo do tipo:

200 Ok

Content-Type: text/html

Content-Lenght: 9

Olá mundo

E o usuário irá visualizar o "Olá mundo" no navegador. Mas neste exemplo, o servidor web, não criou uma sessão de usuário, ou seja, entregou o conteúdo, sem poder rastrear ações futuras. Agora repare o que acontece a seguir:

GET / HTTP/1.1

Host: www.google.com

Com isto, o servidor web ficará responsável em responder com o conteúdo, não importa se seja estático ou dinâmico, isto depende de sua tecnologia, mas irá responder, de fato, conforme o padrão da Web, que seria algo do tipo:

200 Ok

Content-Type: text/html

Content-Lenght: 9

Set-Cookie: abcdefg

Olá mundo

Neste momento, o servidor web entregou um cookie para que seja salvo no navegador, e este servidor web armazenou este cookie em uma nova área na memória RAM no servidor, para guardar informações da aplicação para este usuário. Então todas as próximas solicitações do navegador ao mesmo endereço, serão formadas com um cookie.

GET / HTTP/1.1

Host: www.google.com

Cookie: abcdefg

E então o servidor web recebendo este cookie, pode personalizar o acesso, entregando um novo conteúdo. A área de memória RAM reservada por este espaço limitada por este cookie, pode ser utilizada para variáveis, que tem seus valores dinâmicos.

Supondo que internamente neste servidor web, haja uma aplicação que faça a criação de uma variável "contador", que faça o cálculo de "contador = contador + 1", somando a cada acesso, e que toda a vez que haja um contador maior que 1, apareça após o "Olá mundo", o texto ", você visitou por X vezes!", teremos a seguinte resposta:

200 Ok

Content-Type: text/html

Content-Lenght: 36

Olá mundo, você visitou por 2 vezes!

Repare que não houve uma entrega de um novo "set-cookie", pois a sessão já foi determinada. Repare interações a seguir:

GET / HTTP/1.1

Host: www.google.com

Cookie: abcdefg

200 Ok

Content-Type: text/html

Content-Lenght: 36

Olá mundo, você visitou por 3 vezes!

GET / HTTP/1.1

Host: www.google.com

Cookie: abcdefg

200 Ok

Content-Type: text/html

Content-Lenght: 36

Olá mundo, você visitou por 4 vezes!

E consecutivamente, até, se não houver controle, estourar a variável, gerando um stack overflow, que é um incremento acima do permitido. Um inteiro comum, na maioria das linguagens de programação, só pode ser notado até 65535. Isto pode variar conforme a linguagem de programação.

Em qualquer tipo de tecnologia, determinar uma sessão de usuário é determinístico para conseguir criar aplicações web, de qualquer tipo.

Sem uma sessão de usuário, é impossível conseguir determinar um fluxo a este usuário.

Na Europa, os sites precisam explicitamente avisar os usuários que os sites possuem cookies para rastrear o usuário, e, fez, essencialmente, que todos os sites tenham este aviso, pois atualmente, todos os sites, são aplicações web robustas, que precisam ter uma sessão de usuário, mesmo que este não esteja efetivamente "logado".

Isto porque a forma que as aplicações web são constituídas, em seus primórdios, fizeram que sessão fosse algo padrão, e tecnologias como ASP e ASP.Net, por exemplo, criam sessão ao usuário, mesmo que o servidor apenas tenha um arquivo estático com a extensão ".asp" ou ".aspx". Só o fato deste arquivo ser processado por um handler, ou um processador que irá interpretar o arquivo, por padrão, antes mesmo de começar a interpretar, ele já entrega este cookie ao usuário.

Muita das vezes, é impossível desativar a entrega do cookie de sessão de uma determinada tecnologia para que não seja possível rastrear este usuário, ao menos, se for somente arquivo estático.

Porém, atualmente, até mesmo um arquivo estático pode ser uma aplicação, que passa por um handler para processar a requisição.

Um handler nada mais é que algo que encontra-se entre o "get", e o "200" do servidor web, podendo modificar e/ou alterar o conteúdo da resposta.

No PHP quando se é instalado no servidor IIS, o handler é configurado para todos os arquivos com a extensão ".php", e então quando a aplicação do servidor web recebe uma requisição com um pedido a um arquivo com esta extensão, passa os dados deste arquivo ao handler e a saída dos dados é enviada ao usuário final.

Isto também é igual para ASP, ASP.Net, Java, e etc.

No caso do Java, a situação é um pouco diferente quanto ao handler, pois é chamado de Servlet, e cuida de tudo que chega a este, não só determinados arquivos ou extensões. Até mesmo arquivos estáticos podem ser servidos por Servlets, que estão ali para escrever o conteúdo de uma imagem dinâmica, por exemplo.

Aplicações em Java, podem fazer uso de sessão ou não, mas não é possível usar variáveis de sessão, sem determinar a sessão do usuário, ou seja, sem alocar um espaço na memória RAM da aplicação para salvar estas variáveis. Sem fazer isto, o que é alterado em sessão, é perdido a cada nova requisição.

Aplicações em geral, em qualquer linguagem, não importa qual seja, precisa fazer o enlaçamento entre o cookie entregue ao usuário final, e uma área de memória, a diferença é que podem ser feitos de outras formas, ou o padrão pode ser ignorado, sem fins de uso.

Aplicações que precisam funcionar ao usuário final, e não podem ter uso de cookies, por qualquer tipo de lei, podem fazer uso de um método (que existe no ASP.Net por padrão, se desativar cookies) que é o uso de colocar a sessão do usuário na URL, e então, todos os links que a pessoa clicar, terá esta mesma URL contendo esta sessão. Esta forma é a mais simples de rastrear sem cookies, mas também insegura, pois fica facilmente exposto a informação na URL.

Vejamos a seguir como o servidor web faz este controle:

GET / HTTP/1.1
Host: www.google.com
200 Ok
Content-Type: text/html
Location: www.google.com/abcdef/


GET /abcdef/ HTTP/1.1
Host: www.google.com
200 Ok
Content-Type: text/html
Content-Lenght: 9
Olá mundo

GET /abcdef/ HTTP/1.1
Host: www.google.com
200 Ok
Content-Type: text/html
Content-Lenght: 36
Olá mundo, você visitou por 2 vezes!

Aqui está uma forma clássica de conseguir rastrear o usuário, sem uso de cookies. Do lado do servidor Web, sempre é tratado da mesma forma, gerando um "abcdef" único, para cada nova requisição, sem duplicar, e não pode duplicar jamais.

A área de memória, para vários tipos de tecnologia, por padrão, ficam presas a um processo específico, um executável, que é cuidado e tratado pelo handler ou servlet, que são os responsáveis em gerar o cookie ou código para rastrear usuário, e criar o espaço na memória RAM para aquele cookie.

Os robôs na internet também podem ter sessão de usuário, e em geral, os robôs, não armazenam a variável de sessão ou cookie que o navegador pede, então sempre que um robô acessa, e acessa novamente, é criado no lado da aplicação, novos cookies, e novas áreas e espaços na memória RAM.

Um robô mau intencionado, pode acessar mais de 50 mil vezes um site, e lotar a memória RAM com acessos não identificados, como exemplo, acessando sem entregar o "cookie", ou sem redirecionar para a URL contendo um código de sessão. A aplicação, como no caso, iriam abrir 50 mil espaços na memória RAM para tal, consumindo memória demasiada, dependendo do que este handler precise salvar a este usuário.

Aplicações corporativas, como Java EE, utilizam muitos objetos em memória, geralmente requisições de serviços, contratos, tabelas virtuais, todas armazenadas em objetos de sessão, e consomem geralmente muita memória para cada usuário.

A sessão tratada até aqui, não diz respeito se o usuário está "logado", ou "autenticado", mas somente do princípio da sessão, de como ela é tratada e gerada como base para construir aplicações web.

A autenticação nada mais é, que salvar uma variável de sessão na memória RAM, identificando se o usuário está autorizado ou não a acessar esta aplicação, e como no exemplo dos contadores, a aplicação faz sempre o check se o usuário precisa se autenticar ou não, direcionando para a tela de login.

Autenticar um usuário, nada mais é que aproveitar a sessão de usuário e salvar mais uma variável, entre várias que já podem existir, ou não.

É com base no princípio de sessão, é que você pode sair comprando produtos em lojas virtuais, colocando produtos no carrinho, e só após clicar em "comprar", você realiza o cadastro de fato no site.

Você não precisa estar autenticado ou logado no site, para conseguir escolher seus produtos, na realidade, você já está dentro de uma sessão de usuário desde a visualização da homepage do site.

Alguns programadores em início de carreira, confundem muito esta informação de "sessão de usuário" em "autenticação do usuário", e são coisas distintas, pois a sessão é a identificação primária de uma requisição e a alocação das variáveis em memória, e a autenticação, é a manipulação destas variáveis dentro de uma sessão existente.

É comum encontrar programadores que utilizem linguagens de programação tentando autenticar usuários, e não conseguem fazer isto pois a sessão de usuário não foi criada, bem comum em linguagens como PHP, que exigem um código específico para que o handler inicie o mecanismo de sessão para poder salvar variáveis, ou então, estes dados são perdidos.

Isto geralmente é visto como problema, pois linguagens mais primitivas, tratam a sessão de usuário de forma transparente, e quando utiliza a autenticação, a sessão já está lá pronta para uso.

Linguagens como Python, Java, PHP, e semelhantes, precisam notar especificamente o uso da sessão incorporada na tecnologia. Isto porque, há frameworks que podem prover outras formas de sessão do usuário, diferente do padrão, conforme regra de negócio, ou leis governamentais específicas.