Quelles sont les sessions? Comment travaillent-ils?


333

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.


9
"Est-ce qu'il stocke les données sur le serveur comme un dict où la clé serait un identifiant de session et des détails comme le nom d'utilisateur, l'e-mail, etc., seraient les valeurs?" ...Oui. Le «dict» pourrait être une base de données relationnelle, mais c'est essentiellement ainsi que cela fonctionne.
bobince

14
Je voulais aussi comprendre les sessions Web, maintenant je comprends. J'ai fini par écrire mon propre wiki si cela peut vous être utile: machinesaredigging.com/2013/10/29/how-does-a-web-session-work
eloone

Si vous ne savez pas: stocker le mot de passe côté client n'est pas sûr, même si le mot de passe est haché (cela ne fait aucune différence, en fait. Cracker peut directement saisir le mot de passe haché en créant un faux cookie). sont de meilleurs moyens de stocker l'état de connexion.
cytsunny

1
J'ai écrit moi-même en utilisant les détails du niveau du protocole - bitspedia.com/2012/05/…
Asif Shahzad

Réponses:


400

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


3
"vous ne voulez pas que ces données soient conservées côté client". Pourquoi pas? Si vous utilisez une cryptographie puissante, vous pouvez laisser le client conserver les données de session cryptées et stockées dans un cookie. Cela simplifie considérablement la mise à l'échelle sur plusieurs nœuds car les serveurs n'ont pas besoin de «se souvenir» de quoi que ce soit.
Matt Harrison

5
@MattHarrison comment décrypteriez-vous les données sans "vous souvenir de rien" côté serveur? J'ai essayé d'élargir ce sujet dans ma réponse de toute façon.
Luke404

2
@MattHarrison gardez à l'esprit que le stockage de nombreuses données côté utilisateur augmentera votre trafic.
nitsas

5
Un tiers ne pourrait-il pas agir en tant qu'utilisateur s'il pouvait intercepter la clé de session de l'utilisateur? En supposant que le site n'utilise pas HTTPS, il semble qu'un tiers puisse se faire passer pour l'utilisateur avec une clé de session même si la clé est cryptée. Le serveur le décrypterait.
user137717

2
@ user137717 oui c'est une possibilité si vous autorisez l'accès à la session à "chacun qui présente l'identifiant de session correct". Il existe un certain nombre de restrictions que vous pouvez mettre en place, l'une des plus simples et des plus courantes consiste à stocker l'adresse IP du client dans la session: si un client d'une autre IP présente le même identifiant de session, vous le marquez comme falsifié et supprimez la session.
Luke404

110

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:

Sessions expliquées via Picture


9
Aimez cette explication - dans votre analogie, comment empêcheriez-vous d'autres personnes d'écouter et d'entendre également le mot de passe secret que le caissier vous dit? En d'autres termes, si le session_id est volé, ne serait-il pas possible que quelqu'un imite vos informations d'identification?
wmock

Le détournement de session @wmock est certainement un problème: vérifiez cela! owasp.org/index.php/Session_hijacking_attack
BKSpurgeon

2
bel exemple !! il doit être partagé avec des esprits avides en quête d'apprentissage!
Victor

dans votre analogie, GNASHEU329est le mot de passe utilisateur, qui génère un jeton d'authentification qui expire jusqu'à un certain moment; M. Banks peut alors utiliser le jeton d'authentification pour effectuer plusieurs retraits successifs sans avoir à répéter son mot de passe au caissier?
Daniel Lizik

@DanielLizik vous êtes def. comprendre le concept! Mais je ne connais pas suffisamment les flux de travail basés sur des jetons pour vous donner une réponse intelligente. Le principe général est que le serveur doit être en mesure d'identifier d'une manière ou d'une autre qui est la personne qui fait la demande.
BKSpurgeon

39

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


Je sais que sur les serveurs IIS que j'utilise, je peux obtenir le nom d'utilisateur à partir d'un en-tête USER_NAME, mais cela peut être spécifique à IIS.
Tim Rourke

Que signifie le REFERRER ici?
Gab 是 好人

@Gab 是 好人 REFERRER signifie généralement une chaîne arbitraire que le client envoie dans l'en-tête de requête HTTP "Referer". Il doit contenir l'URL de la ressource qui, vous le savez, a référé le client à la ressource actuelle.
Luke404

Merci, ça devrait , donc pas forcément. donc je pense que les gens utilisent souvent cet en-tête avec une sémantique différente de celle suggérée dans le RFC, non?
Gab 是 好人

D'abord, vous avez écrit Like cookies, this usually doesn't get sent in the URL anymoreet ensuite Session variables are like cookies - they're name-value pairs sent along with a request for a page. Que se passe-t-il exactement? Est-il envoyé lors de votre prochaine demande?
KPMG

19

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.


1
Pouvez-vous mettre un peu plus de lumière à ce sujet - "Maintenant, pour chaque identifiant de session, le serveur conserve une 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."? Quelles informations client spécifiques le serveur stocke-t-il?
realPK

Pouvez-vous mettre un peu plus de lumière à ce sujet - "Maintenant, pour chaque identifiant de session, le serveur conserve une 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."? Quelles informations client spécifiques le serveur stocke-t-il?
Gab 是 好人

Même question que ci-dessus aussi, il serait utile que vous répondiez.
Suraj Jain

4

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.