Hallo,
bei Verständnisproblemen helfen oft sehr einfache Beispiele.
Stell dir vor, du hast eine Internetseite mit einem Bereich, der nur per Login erreichbar sein soll. Dieser Bereich verfügt über mehrere Unterseiten, die nur von eingeloggten Benutzern aufgerufen werden dürfen. Nennen wir diese Seiten "geschützte Seiten".
Diese "geschützte Seiten" können - wie bei Webseiten üblich - über die Adressleiste des Browser aufgerufen werden. Bei so einem Aufruf, muss also erkannt werden, ob der Benutzer berechtigt ist, die Seite aufzurufen oder nicht.
Ohne Session könntest du einfach bei jedem Aufruf einer geschützten Seite ein Loginformular stellen, das vom Benutzer ausgefüllt werden muss. Bei hunderten "geschützter Seiten" dürfte das sehr unpraktisch werden. Besser wäre, sich nur einmal einloggen zu müssen und dann alle "geschützten Seiten" anwählen zu dürfen.
Die Webseite muss sich merken, dass sich der Benutzer schon angemeldet hat und ihm wann immer gewünscht, weitere "geschützte Seiten" ohne zusätzlichen Login ausliefern. Dafür werden Sessions benutzt.
Eine Session löst das so:
- Der Benutzer gibt sein Login und Passwort ein.
- Auf dem Webserver wird geprüft, ob die Loginkombination korrekt ist, z.B. werden die Eingaben mit Werten verglichen, die in einer Datenbank stehen. Dort steht in der Regel auch eine Identifiktationsnummer für den Benutzer drin, die für die weitere Erkennung des Benutzers genutzt werden kann.
- Stimmen die Daten, dann legt der Webserver bzw. das verwendete Skript für den Benutzer eine Session an. Die Session ist eine Textdatei auf dem Webserver. Sie bekommt eine Session-Id zugewiesen, eine kryptische Zahlen/Buchstabenkombination, die einmalig ist und wegen ihrer Kryptik nicht von Dritten "erraten" werden kann. In die Session-Datei legt der Webserver z.B. die Identifiktationsnummer des Benutzers ab.
- Erst wenn der Webserver all das getan hat, schickt er dem Benutzer die angeforderte "geschützte Seite" zu seinem Browser (vielleicht zusammen mit einem "Login erfolgreich"). Außerdem schickt er auch die kryptische Session-Id zusammen mit der geschützten Seite.
- Will der Benutzer die nächste geschützte Seite sehen, wird bei der Anforderung immer die Session-Id zurück an den Webserver mitgeschickt.
- Die Anforderung landet wieder beim Webserver, der nun entscheiden muss, ob der Benutzer bereits angemeldet war oder nicht.
- Er empfängt die Session-Id und vergleicht sie mit den Session-Dateien, die gerade bei ihm aktiv sind. Findet er die richtige Datei für den Benutzer, weiß er dass für ihn eine Session existiert und er eingeloggt ist. In der Datei steht sogar die Identifiktationsnummer des Benutzers drin, so dass das bearbeitende Skript eine Datenbankabfrage nach dem Namen des Benutzers starten kann und mit der Auslieferung der nächsten "geschützten Seite" auch eine persönliche Anrede mit schicken kann.
Die Session kann neben Ids auch alle möglichen anderen Daten beinhalten, ganz wie der Webentwickler es braucht. Man kann seine Skripte so anlegen, dass die bloße Existenz einer Session, als Loginbeweis gilt, oder aber man vermerkt den Login nochmal extra in der Session, z.B. mit dem Login-Datum (wofür auch immer). Oder es gibt Abstufungen bei den Berechtigungen, welche Seiten angesehen werden dürfen, und welche nicht. Dann kann in der Session auch eine Gruppen-ID mit abgelegt werden, anhand der unterschieden werden kann, welche Inhalte angezeigt werden.
Wenn viele Benutzer gleichzeitig die Webseite besuchen, dann erhält jeder von ihnen eine eigene Session und jeder kann individuell erkannt und behandelt werden.
Viele Grüße aus Berlin
Max Smily