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.

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.

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ã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.

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.

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.