Je commence tout juste à commencer à apprendre le développement d'applications Web à l'aide de python. Je rencontre les termes «cookies» et «sessions». Je comprends les cookies en ce sens qu'ils stockent des informations dans une paire de valeurs clés sur le navigateur. Mais j'ai une petite confusion concernant les sessions, dans une session aussi nous stockons des données dans un cookie sur le navigateur de l'utilisateur.

Par exemple - je me connecte en utilisant username='rasmus'et password='default'. Dans un tel cas, les données seront publiées sur le serveur qui est censé vérifier et me connecter si authentifié. Cependant, pendant tout le processus, le serveur génère également un ID de session qui sera stocké dans un cookie sur mon navigateur. Maintenant, le serveur stocke également cet ID de session dans son système de fichiers ou sa banque de données.

Mais en se basant uniquement sur l'ID de session, comment pourrait-il connaître mon nom d'utilisateur lors de ma navigation ultérieure sur le site? Stocke-t-il les données sur le serveur en tant que dict où la clé serait un ID de session et des détails comme username, emailetc. , les valeurs?

Je suis assez confus ici. Besoin d'aide.

Parce que HTTP est sans état, afin d'associer une demande à toute autre demande, vous avez besoin d'un moyen de stocker les données utilisateur entre les demandes HTTP.

Les cookies ou les paramètres d'URL (par exemple, http://example.com/myPage?asd=lol&boo=no ) sont tous deux des moyens appropriés pour transporter des données entre 2 requêtes ou plus. Cependant, ils ne sont pas bons au cas où vous ne voudriez pas que ces données soient lisibles / modifiables côté client.

La solution consiste à stocker ce côté serveur de données, à lui attribuer un "id" et à laisser le client connaître (et renvoyer à chaque demande http) cet identifiant. Voilà, les sessions sont mises en place. Ou vous pouvez utiliser le client comme un stockage à distance pratique, mais vous crypteriez les données et garderiez le côté serveur secret.

Bien sûr, il y a d'autres aspects à considérer, comme vous ne voulez pas que les gens détournent les sessions des autres, vous voulez que les sessions ne durent pas éternellement mais expirent, etc.

Dans votre exemple spécifique, l'ID utilisateur (qui peut être un nom d'utilisateur ou un autre ID unique dans votre base de données utilisateur) est stocké dans les données de session, côté serveur, après une identification réussie. Ensuite, pour chaque demande HTTP que vous recevez du client, l'ID de session (donné par le client) vous dirigera vers les données de session correctes (stockées par le serveur) qui contiennent l'ID utilisateur authentifié - de cette façon, votre code saura quel utilisateur il parle à.

Explication simple par analogie

Imaginez que vous êtes dans une banque et que vous essayez de retirer de l'argent de votre compte. Mais c'est sombre; la banque est noire: il n'y a pas de lumière et vous ne pouvez pas voir votre main devant votre visage. Vous êtes entouré de 20 autres personnes. Ils se ressemblent tous. Et tout le monde a la même voix. Et tout le monde est un méchant potentiel. En d'autres termes, HTTP est sans état.

Cette banque est un type de banque amusant - pour les besoins de la discussion, voici comment les choses fonctionnent:

1. vous attendez en ligne (ou en ligne) et vous parlez au caissier: vous faites une demande de retrait d'argent, puis
2. vous devez attendre brièvement sur le canapé, et 20 minutes plus tard
3. vous devez aller chercher votre argent auprès du caissier.

Mais comment le caissier vous dira-t-il en dehors de tout le monde?

Le caissier ne peut pas vous voir ou vous reconnaître facilement, rappelez-vous, car les lumières sont toutes éteintes. Et si votre caissier donne votre retrait de 10 000 $ à quelqu'un d'autre - la mauvaise personne?! Il est absolument essentiel que le caissier puisse vous reconnaître comme celui qui a effectué le retrait, afin que vous puissiez obtenir l'argent (ou la ressource) que vous avez demandé.

Solution:

Lorsque vous apparaissez pour la première fois au caissier, il vous dit quelque chose en secret:

"Chaque fois que vous me parlez", dit le caissier, "vous devez d'abord vous identifier comme GNASHEU329 - de cette façon, je sais que c'est vous".

Personne d'autre ne connaît le mot de passe secret.

Exemple de retrait d'argent:

Alors je décide d'aller et de me détendre pendant 20 minutes, puis plus tard, je vais chez le caissier et je dis "Je voudrais récupérer mon retrait"

Le caissier me demande: "qui êtes-vous ??!"

"C'est moi, M. George Banks!"

"Prouve le!"

Et puis je leur dis mon mot de passe: GNASHEU329

"Certainement M. Banks!"

Voilà comment fonctionne une session. Il permet d'être identifié de manière unique dans une mer de millions de personnes. Vous devez vous identifier chaque fois que vous traitez avec le caissier.

Si vous avez des questions ou n'êtes pas clair - veuillez poster un commentaire et je vais essayer de le clarifier pour vous.

Explication via les images:

«Session» est le terme utilisé pour désigner le temps d'un utilisateur parcourant un site Web. Il est censé représenter le temps entre leur première arrivée sur une page du site et le moment où ils cessent d'utiliser le site. En pratique, il est impossible de savoir quand l'utilisateur en a fini avec le site. Dans la plupart des serveurs, il existe un délai qui met automatiquement fin à une session, sauf si une autre page est demandée par le même utilisateur.

La première fois qu'un utilisateur se connecte, une sorte d'ID de session est créée (la façon dont cela se fait dépend du logiciel du serveur Web et du type d'authentification / connexion que vous utilisez sur le site). Comme les cookies, cela n'est généralement plus envoyé dans l'URL car c'est un problème de sécurité. Au lieu de cela, il est stocké avec un tas d'autres choses qui, collectivement, sont également appelées la session. Les variables de session sont comme des cookies - ce sont des paires nom-valeur envoyées avec une demande de page et renvoyées avec la page du serveur - mais leurs noms sont définis dans une norme Web.

Certaines variables de session sont passées en tant qu'en- têtes HTTP . Ils sont passés dans les deux sens dans les coulisses de chaque page afin de ne pas apparaître dans le navigateur et de dire à tout le monde quelque chose qui peut être privé. Parmi eux se trouvent USER_AGENT, ou le type de navigateur qui demande la page, le REFERRER ou la page qui a lié à la page demandée, etc. Certains logiciels de serveur Web ajoutent leurs propres en-têtes ou transfèrent des données de session supplémentaires spécifiques au logiciel serveur. Mais les standards sont assez bien documentés.

J'espère que cela pourra aider.

HTTP est un protocole de connexion sans état, c'est-à-dire que le serveur ne peut pas différencier les différentes connexions des différents utilisateurs.

D'où vient le cookie, une fois qu'un client se connecte pour la première fois à un serveur, le serveur génère un nouvel identifiant de session, qui sera ensuite envoyé au client en tant que valeur de cookie. Et à partir de maintenant, cet ID de session identifiera cette connexion client, car dans chaque demande HTTP, il verra l'ID de session approprié dans les cookies.

Désormais, pour chaque identifiant de session, le serveur conserve une certaine structure de données, ce qui lui permet de stocker des données spécifiques à l'utilisateur, cette structure de données que vous pouvez appeler de manière abstraite session.

Considérez HTTP comme une personne (A) qui a une PERTE DE MÉMOIRE À COURT TERME et oublie chaque personne dès qu'elle disparaît.

Maintenant, pour se souvenir de différentes personnes, A prend une photo de cette personne et la garde. La photo de chaque personne a un numéro d'identification. Lorsque cette personne revient en vue, cette personne dit que c'est son numéro d'identification à A et A trouve sa photo par numéro d'identification. Et le tour est joué !!, A sait qui est cette personne.

C'est la même chose avec HTTP. Il souffre d'une PERTE DE MÉMOIRE À COURT TERME. Il utilise des sessions pour enregistrer tout ce que vous avez fait en utilisant un site Web, puis, lorsque vous revenez, il vous identifie à l'aide de cookies (le cookie est comme un jeton). L'image est la session ici, et l'ID est le cookie ici.