O que são sessões? Como eles funcionam?

332

Estou apenas começando a aprender o desenvolvimento de aplicativos da web, usando python. Estou encontrando os termos 'cookies' e 'sessões'. Entendo os cookies, pois eles armazenam algumas informações em um par de valores-chave no navegador. Mas tenho um pouco de confusão em relação às sessões, em uma sessão também armazenamos dados em um cookie no navegador do usuário.

Por exemplo - eu entro usando username='rasmus'e password='default'. Nesse caso, os dados serão postados no servidor que deve verificar e me logar se autenticado. No entanto, durante todo o processo, o servidor também gera um ID de sessão que será armazenado em um cookie no meu navegador. Agora, o servidor também armazena esse ID de sessão em seu sistema de arquivos ou armazenamento de dados.

Mas, com base apenas no ID da sessão, como seria possível saber meu nome de usuário durante minha passagem subsequente pelo site? Ele armazena os dados no servidor como um ditado em que a chave seria um ID de sessão e detalhes como username, emailetc. , serão os valores?

Estou ficando bastante confuso aqui. Preciso de ajuda.

Rasmus
fonte
9
"Ele armazena os dados no servidor como um ditado em que a chave seria um ID de sessão e detalhes como nome de usuário, email etc. serão os valores?" ...sim. O 'dict' pode ser um banco de dados relacional, mas é basicamente assim que funciona.
bobince
14
Eu também queria entender as sessões da web, agora eu entendo. Acabei escrevendo meu próprio wiki se isso é de alguma ajuda: machinesaredigging.com/2013/10/29/how-does-a-web-session-work
eloone
Caso você não saiba: armazenar a senha no lado do cliente não é seguro, mesmo que a senha esteja com hash (de fato, não faz diferença. O Cracker pode inserir diretamente a senha com hash criando um cookie falso) existem maneiras melhores de armazenar o status de login.
cytsunny
1
Eu escrevi minhas próprias detalhes de nível usando o protocolo - bitspedia.com/2012/05/...
Asif Shahzad

Respostas:

400

Como o HTTP é sem estado, para associar uma solicitação a qualquer outra solicitação, você precisa de uma maneira de armazenar dados do usuário entre solicitações HTTP.

Cookies ou parâmetros de URL (por exemplo, como http://example.com/myPage?asd=lol&boo=no ) são maneiras adequadas de transportar dados entre 2 ou mais solicitações. No entanto, eles não são bons caso você não queira que esses dados sejam legíveis / editáveis ​​no lado do cliente.

A solução é armazenar esse lado do servidor de dados, fornecer um "ID" e informar ao cliente apenas (e repassar a cada solicitação http) esse ID. Lá vai você, sessões implementadas. Ou você pode usar o cliente como um armazenamento remoto conveniente, mas criptografará os dados e manterá o servidor secreto.

É claro que há outros aspectos a serem considerados, como você não quer que as pessoas sequestrem as sessões de outras pessoas, que você não durará para sempre, mas expirará, e assim por diante.

No seu exemplo específico, o ID do usuário (pode ser o nome de usuário ou outro ID exclusivo no banco de dados do usuário) é armazenado nos dados da sessão, no servidor, após uma identificação bem-sucedida. Então, para cada solicitação HTTP que você obtiver do cliente, o ID da sessão (fornecido pelo cliente) apontará para os dados corretos da sessão (armazenados pelo servidor) que contêm o ID do usuário autenticado - para que seu código saiba qual usuário ele está conversando com.

Luke404
fonte
3
"você não quer que esses dados sejam mantidos no lado do cliente". Por que não? Se você usar criptografia robusta, poderá deixar o cliente manter os dados da sessão criptografados e armazenados em um cookie. Isso simplifica bastante o dimensionamento para vários nós, pois os servidores não precisam "lembrar" nada.
Matt Harrison
5
@ MattHarrison, como você descriptografaria os dados sem "lembrar de nada" no lado do servidor? Eu tentei expandir este tópico na minha resposta de qualquer maneira.
Luke404
2
O @MattHarrison lembre-se de que armazenar muitos dados no lado do usuário aumentará seu tráfego.
Nitsas
5
Um terceiro não seria capaz de agir como usuário se pudesse interceptar a chave de sessão do usuário? Supondo que o site não use HTTPS, parece que terceiros podem se disfarçar de usuário com uma chave de sessão, mesmo que a chave esteja criptografada. O servidor apenas descriptografaria.
User137717
2
@ user137717 sim, essa é uma possibilidade se você permitir o acesso à sessão literalmente "todos que apresentarem o ID da sessão correto". Há várias restrições que você pode aplicar, uma das mais fáceis e mais comuns é armazenar o IP do cliente na sessão: se um cliente de outro IP apresentar o mesmo ID de sessão, você marcará como forjado e excluirá a sessão.
precisa saber é o seguinte
110

Explicação simples por analogia

Imagine que você está em um banco, tentando tirar algum dinheiro da sua conta. Mas está escuro; o banco está totalmente escuro: não há luz e você não pode ver sua mão na frente do seu rosto. Você está cercado por outras 20 pessoas. Todos eles parecem iguais. E todo mundo tem a mesma voz. E todo mundo é um potencial bandido. Em outras palavras, o HTTP é sem estado.

Este banco é um tipo engraçado de banco - por uma questão de argumento, veja como as coisas funcionam:

  1. você espera na fila (ou on-line) e conversa com o caixa: solicita a retirada de dinheiro e depois
  2. você tem que esperar brevemente no sofá e 20 minutos depois
  3. você precisa ir e coletar seu dinheiro junto ao caixa.

Mas como o caixa o diferencia de todos os outros?

O caixa não pode vê-lo ou reconhecê-lo facilmente, lembre-se, porque as luzes estão apagadas. E se o seu caixa der o seu saque de US $ 10.000 a outra pessoa - a pessoa errada ?! É absolutamente vital que o caixa possa reconhecê-lo como quem fez a retirada, para que você possa obter o dinheiro (ou recurso) que pediu.

Solução:

Quando você aparece pela primeira vez no caixa, ele ou ela lhe diz algo em segredo:

"Sempre que estiver falando comigo", diz o caixa, "você deve primeiro se identificar como GNASHEU329 - assim sei que é você".

Ninguém mais sabe a senha secreta.

Exemplo de como saquei dinheiro:

Então eu decido ir e relaxar por 20 minutos e depois vou ao caixa e digo "Gostaria de receber minha retirada"

O caixa me pergunta: "quem é você ??!"

"Sou eu, senhor George Banks!"

"Prove!"

E então eu digo a eles minha senha: GNASHEU329

"Certamente, Sr. Banks!"

É basicamente assim que uma sessão funciona. Ele permite que alguém seja identificado de maneira única em um mar de milhões de pessoas. Você precisa se identificar toda vez que lida com o caixa.

Se você tiver alguma dúvida ou não estiver claro - envie um comentário e tentarei esclarecê-lo.

Explicação por meio de imagens:

Sessões explicadas via Figura

BKSpurgeon
fonte
9
Adoro esta explicação - em sua analogia, como você impediria que outras pessoas espiassem e também ouvissem a senha secreta que o caixa lhe diz? Em outras palavras, se o session_id for roubado, não seria possível alguém imitar suas credenciais?
Wmock 15/04
O sequestro de sessão @wmock é certamente um problema: confira isso! owasp.org/index.php/Session_hijacking_attack
BKSpurgeon
2
exemplo adorável !! deve ser compartilhado com mentes ansiosas que procuram aprender!
Victor Victor
na sua analogia, GNASHEU329é a senha do usuário, que gera um token de autenticação que expira até um determinado período; O Sr. Banks pode usar o token de autenticação para fazer várias retiradas sucessivas sem precisar fornecer repetidamente sua senha ao caixa.
Daniel Lizik 9/03
@DanielLizik você está def. Compreendendo o conceito! Mas não tenho conhecimento suficiente sobre fluxos de trabalho baseados em token para fornecer uma resposta inteligente. O princípio geral é que o servidor precisa ser capaz de identificar de alguma forma quem é a pessoa que está fazendo a solicitação.
BKSpurgeon 9/03
39

"Sessão" é o termo usado para se referir ao tempo de um usuário navegando em um site. Ele serve para representar o tempo entre a primeira chegada a uma página no site e até o momento em que eles param de usá-lo. Na prática, é impossível saber quando o usuário termina o site. Na maioria dos servidores, existe um tempo limite que termina automaticamente uma sessão, a menos que outra página seja solicitada pelo mesmo usuário.

A primeira vez que um usuário conecta algum tipo de ID de sessão é criado (como isso depende do software do servidor da Web e do tipo de autenticação / login que você está usando no site). Como os cookies, isso geralmente não é mais enviado no URL porque é um problema de segurança. Em vez disso, é armazenado junto com várias outras coisas que, coletivamente, também são chamadas de sessão. As variáveis ​​de sessão são como cookies - são pares nome-valor enviados junto com uma solicitação de uma página e retornados com a página do servidor - mas seus nomes são definidos em um padrão da web.

Algumas variáveis ​​de sessão são passadas como cabeçalhos HTTP . Eles são passados ​​para trás e para trás nos bastidores de todas as páginas pesquisadas, para que não apareçam no navegador e digam a todos algo privado. Entre eles estão o USER_AGENT, ou o tipo de navegador que solicita a página, o REFERRER ou a página que está vinculada à página que está sendo solicitada, etc. Mas os padrões estão muito bem documentados.

Espero que ajude.

Tim Rourke
fonte
Eu sei que nos servidores IIS que uso, posso obter o nome de usuário de um cabeçalho USER_NAME, mas isso pode ser específico do IIS.
Tim Rourke
O que o REFERRER significa aqui?
Gab是好人
@Gab 好人 好人 REFERRER geralmente significa uma string arbitrária que o cliente envia no cabeçalho da solicitação HTTP "Referer". Ele deve conter a URL do recurso que, você sabe, encaminhou o cliente ao recurso atual.
precisa saber é o seguinte
Obrigado, deveria , então não necessariamente. então eu acho que as pessoas costumam usar esse cabeçalho com semântica diferente da sugerida na RFC, certo?
Gab是好人
Primeiro você escreveu Like cookies, this usually doesn't get sent in the URL anymoree depois Session variables are like cookies - they're name-value pairs sent along with a request for a page. O que acontece exatamente? É enviado com a próxima vez que você faz algum pedido?
KPMG
19

HTTP é um protocolo de conexão sem estado, ou seja, o servidor não pode diferenciar entre conexões diferentes de usuários diferentes.

Daí vem o cookie, uma vez que um cliente se conecta pela primeira vez a um servidor, o servidor gera um novo ID de sessão, que posteriormente será enviado ao cliente como valor do cookie. E a partir de agora, esse ID de sessão identificará a conexão do cliente, pois em cada solicitação HTTP, ele verá o ID da sessão apropriado nos cookies.

Agora, para cada ID de sessão, o servidor mantém alguma estrutura de dados, o que lhe permite armazenar dados específicos do usuário; essa estrutura de dados pode ser chamada abstratamente de sessão.

Artem Barger
fonte
1
Você pode colocar um pouco mais de luz sobre isso - "Agora, para cada ID de sessão, o servidor mantém alguma estrutura de dados, o que lhe permite armazenar dados específicos do usuário; essa estrutura de dados pode ser chamada abstratamente de sessão". Quais informações específicas do cliente o servidor armazena?
realPK 27/02
Você pode colocar um pouco mais de luz sobre isso - "Agora, para cada ID de sessão, o servidor mantém alguma estrutura de dados, o que lhe permite armazenar dados específicos do usuário; essa estrutura de dados pode ser chamada abstratamente de sessão". Quais informações específicas do cliente o servidor armazena?
Gab是好人
A mesma pergunta acima também, seria útil se você responder.
Suraj Jain
4

Pense no HTTP como uma pessoa (A) com PERDA DE MEMÓRIA A CURTO PRAZO e esqueça todas as pessoas assim que ela desaparecer.

Agora, para lembrar pessoas diferentes, A tira uma foto dessa pessoa e a guarda. A foto de cada pessoa tem um número de identificação. Quando essa pessoa aparece novamente, ela informa seu número de identificação para A e A encontra sua foto pelo número de identificação. E pronto !!, A sabe quem é essa pessoa.

O mesmo acontece com o HTTP. Está sofrendo de PERDA DE MEMÓRIA A CURTO PRAZO. Ele usa Sessões para registrar tudo o que você fez enquanto usava um site e, em seguida, quando você volta, identifica você com a ajuda de Cookies (o cookie é como um token). A imagem é a sessão aqui e o ID é o cookie aqui.

Luv33preet
fonte