Ich fange gerade an, die Entwicklung von Webanwendungen mit Python zu lernen. Ich stoße auf die Begriffe "Cookies" und "Sitzungen". Ich verstehe Cookies darin, dass sie einige Informationen in einem Schlüsselwertpaar im Browser speichern. Aber ich habe ein wenig Verwirrung in Bezug auf Sitzungen. Auch in einer Sitzung speichern wir Daten in einem Cookie im Browser des Benutzers.

Zum Beispiel - ich melde mich mit username='rasmus'und an password='default'. In diesem Fall werden die Daten an den Server gesendet, der mich bei Authentifizierung überprüfen und anmelden soll. Während des gesamten Vorgangs generiert der Server jedoch auch eine Sitzungs-ID, die in einem Cookie in meinem Browser gespeichert wird. Jetzt speichert der Server diese Sitzungs-ID auch in seinem Dateisystem oder Datenspeicher.

Aber wie kann es nur anhand der Sitzungs-ID meinen Benutzernamen bei meinem anschließenden Durchlaufen der Site erkennen? Ist sie speichert die Daten auf dem Server als dict , wo der Schlüssel eine Session - ID und Details werden möchte username, emailusw. die Werte sein?

Ich bin hier ziemlich verwirrt. Brauchen Sie Hilfe.

Da HTTP zustandslos ist, benötigen Sie eine Möglichkeit zum Speichern von Benutzerdaten zwischen HTTP-Anforderungen, um eine Anforderung einer anderen Anforderung zuzuordnen.

Cookies oder URL-Parameter (z. B. http://example.com/myPage?asd=lol&boo=no ) sind beide geeignete Methoden zum Transportieren von Daten zwischen zwei oder mehr Anforderungen. Sie sind jedoch nicht gut, wenn Sie nicht möchten, dass diese Daten auf der Clientseite lesbar / bearbeitbar sind.

Die Lösung besteht darin, diese Datenserverseite zu speichern, ihr eine "ID" zu geben und dem Client nur diese ID mitzuteilen (und bei jeder http-Anforderung zurückzugeben). Los geht's, Sitzungen implementiert. Sie können den Client auch als praktischen Remotespeicher verwenden, die Daten jedoch verschlüsseln und die geheime Serverseite beibehalten.

Natürlich müssen noch andere Aspekte berücksichtigt werden, z. B. nicht, dass Personen die Sitzungen anderer entführen, dass Sitzungen nicht ewig dauern, sondern ablaufen und so weiter.

In Ihrem speziellen Beispiel wird die Benutzer-ID (möglicherweise ein Benutzername oder eine andere eindeutige ID in Ihrer Benutzerdatenbank) nach erfolgreicher Identifizierung serverseitig in den Sitzungsdaten gespeichert. Bei jeder HTTP-Anforderung, die Sie vom Client erhalten, verweist die Sitzungs-ID (vom Client angegeben) auf die richtigen Sitzungsdaten (vom Server gespeichert), die die authentifizierte Benutzer-ID enthalten. Auf diese Weise weiß Ihr Code, welcher Benutzer sie hat spricht mit.

Einfache Erklärung in Analogie

Stellen Sie sich vor, Sie sind in einer Bank und versuchen, etwas Geld von Ihrem Konto abzuheben. Aber es ist dunkel; Die Bank ist pechschwarz: Es gibt kein Licht und Sie können Ihre Hand nicht vor Ihrem Gesicht sehen. Sie sind von weiteren 20 Personen umgeben. Alle sehen gleich aus. Und jeder hat die gleiche Stimme. Und jeder ist ein potentieller Bösewicht. Mit anderen Worten, HTTP ist zustandslos.

Diese Bank ist eine lustige Art von Bank - aus Gründen der Argumentation funktionieren die Dinge folgendermaßen:

1. Sie warten in der Schlange (oder online) und sprechen mit dem Kassierer: Sie beantragen, Geld abzuheben, und dann
2. Sie müssen kurz auf dem Sofa und 20 Minuten später warten
3. Sie müssen gehen und tatsächlich Ihr Geld vom Kassierer abholen.

Aber wie wird der Kassierer Sie von allen anderen unterscheiden?

Der Kassierer kann Sie nicht sehen oder erkennen, denken Sie daran, weil alle Lichter ausgehen. Was ist, wenn Ihr Kassierer Ihre 10.000-Dollar-Auszahlung an eine andere Person weitergibt - an die falsche Person?! Es ist absolut wichtig, dass der Kassierer Sie als denjenigen erkennt, der die Auszahlung vorgenommen hat, damit Sie das Geld (oder die Ressource) erhalten, nach dem Sie gefragt haben.

Lösung:

Wenn Sie dem Kassierer zum ersten Mal erscheinen, sagt er oder sie Ihnen etwas im Verborgenen:

"Wann immer Sie mit mir sprechen", sagt der Kassierer, "sollten Sie sich zuerst als GNASHEU329 identifizieren - auf diese Weise weiß ich, dass Sie es sind".

Niemand sonst kennt den geheimen Passcode.

Beispiel, wie ich Bargeld abgehoben habe:

Also entscheide ich mich, 20 Minuten lang zu entspannen und dann später zum Kassierer zu gehen und zu sagen: "Ich möchte meine Auszahlung abholen."

Der Kassierer fragt mich: "Wer bist du ?!"

"Ich bin es, Mr. George Banks!"

"Beweise es!"

Und dann sage ich ihnen meinen Passcode: GNASHEU329

"Sicherlich Mr. Banks!"

So funktioniert eine Sitzung im Grunde. Es ermöglicht die eindeutige Identifizierung in einem Meer von Millionen von Menschen. Sie müssen sich jedes Mal identifizieren, wenn Sie mit dem Kassierer zu tun haben.

Wenn Sie Fragen haben oder unklar sind - schreiben Sie bitte einen Kommentar und ich werde versuchen, ihn für Sie zu klären.

Erklärung über Bilder:

"Sitzung" bezeichnet die Zeit eines Benutzers beim Surfen auf einer Website. Es soll die Zeit zwischen dem ersten Aufrufen einer Seite auf der Website bis zu dem Zeitpunkt darstellen, an dem sie die Website nicht mehr nutzen. In der Praxis ist es unmöglich zu wissen, wann der Benutzer mit der Site fertig ist. Auf den meisten Servern gibt es eine Zeitüberschreitung, die eine Sitzung automatisch beendet, es sei denn, derselbe Benutzer fordert eine andere Seite an.

Wenn ein Benutzer zum ersten Mal eine Verbindung herstellt, wird eine Sitzungs-ID erstellt (wie dies erfolgt, hängt von der Webserver-Software und der Art der Authentifizierung / Anmeldung ab, die Sie auf der Site verwenden). Wie bei Cookies wird dies normalerweise nicht mehr in der URL gesendet, da es sich um ein Sicherheitsproblem handelt. Stattdessen wird es zusammen mit einer Reihe anderer Dinge gespeichert, die zusammen auch als Sitzung bezeichnet werden. Sitzungsvariablen sind wie Cookies - sie sind Name-Wert-Paare, die zusammen mit einer Anforderung für eine Seite gesendet und mit der Seite vom Server zurückgegeben werden - aber ihre Namen sind in einem Webstandard definiert.

Einige Sitzungsvariablen werden als HTTP-Header übergeben . Sie werden hinter den Kulissen jeder Seite hin und her geleitet, damit sie nicht im Browser angezeigt werden und jedem etwas mitteilen, das möglicherweise privat ist. Dazu gehören das USER_AGENT oder der Browsertyp, der die Seite anfordert, der REFERRER oder die Seite, die mit der angeforderten Seite verknüpft ist usw. Einige Webserver-Software fügt ihre eigenen Header hinzu oder überträgt zusätzliche Sitzungsdaten, die für die Serversoftware spezifisch sind. Aber die Standard sind ziemlich gut dokumentiert.

Ich hoffe, das hilft.

HTTP ist ein zustandsloses Verbindungsprotokoll, dh der Server kann nicht zwischen verschiedenen Verbindungen verschiedener Benutzer unterscheiden.

Wenn ein Client zum ersten Mal eine Verbindung zu einem Server herstellt, generiert der Server eine neue Sitzungs-ID, die später als Cookie-Wert an den Client gesendet wird. Von nun an identifiziert diese Sitzungs-ID diese Client-Verbindung, da in jeder HTTP-Anforderung die entsprechende Sitzungs-ID in Cookies angezeigt wird.

Jetzt behält der Server für jede Sitzungs-ID eine Datenstruktur bei, die es ihm ermöglicht, benutzerspezifische Daten zu speichern. Diese Datenstruktur können Sie abstrakt als Sitzung bezeichnen.

Stellen Sie sich HTTP als eine Person (A) vor, die einen KURZFRISTIGEN SPEICHERVERLUST hat und jede Person vergisst, sobald diese Person außer Sichtweite gerät.

Um sich an verschiedene Personen zu erinnern, macht A ein Foto von dieser Person und bewahrt es auf. Das Bild jeder Person hat eine ID-Nummer. Wenn diese Person wieder in Sicht kommt, teilt diese Person A ihre ID-Nummer mit und A findet ihr Bild anhand der ID-Nummer. Und voila !!, A weiß, wer diese Person ist.

Gleiches gilt für HTTP. Es leidet unter KURZFRISTIGEM SPEICHERVERLUST. Es verwendet Sitzungen, um alles aufzuzeichnen, was Sie während der Nutzung einer Website getan haben, und identifiziert Sie dann, wenn Sie wiederkommen, mithilfe von Cookies (Cookie ist wie ein Token). Bild ist die Sitzung hier und ID ist das Cookie hier.