Andre: Verständnisproblem: Sessions

Hey,

ich hab irgendwie Probleme das mit den Sessions zu verstehen.

Ich will ein Login-System realisieren.
Ich hab ein Formular mit 2 Eingabefeldern: Name, Passwort
Diese werden mit einem POST-Request an ein Skript weitergesendet und in dem Skript vorerst mit einer MySQL Datenbank verglichen. Stimmen sie überein, wird soll eine "Session" gestartet werden und danach auf die geschützte Seite weitergeleitet werden. Und wie funktioniert jetzt dieses ganze Session System.
Kann mir das jemand erklären?

Zur Not auch Code schicken, wobei ich es ja verstehen will..

lg

Andre

  1. Hi,

    ich hab irgendwie Probleme das mit den Sessions zu verstehen.

    Sessions bestehen im wesentlichen aus zwei Bestandteilen:

    • einer eindeutigen Kennung, der Session-ID, mit der ein bestimmter Client wiedererkannt werden soll - in dem er die einmal vergebene ID beim naechsten Request wieder mitschickt
    • einem serverseitigen Datenspeicher (Datei, Datenbank, ...), in dem die Daten mit der Session-ID verknuepft sind

    Ich will ein Login-System realisieren.
    Ich hab ein Formular mit 2 Eingabefeldern: Name, Passwort
    Diese werden mit einem POST-Request an ein Skript weitergesendet und in dem Skript vorerst mit einer MySQL Datenbank verglichen. Stimmen sie überein, wird soll eine "Session" gestartet werden und danach auf die geschützte Seite weitergeleitet werden. Und wie funktioniert jetzt dieses ganze Session System.

    Na eigentlich ganz einfach:
    Du startest eine Session, und speicherst darin die Information, dass der Nutzer sich mit gueltigen Daten identifiziert hat.
    Und auf den Folgeseiten nimmst du dann die Session wieder auf, und schaust nach, ob eben diese Information drin steht.

    Siehe bspw. auch http://tut.php-quake.net/de/sessions.html oder http://php-faq.de/ch-version4_session.html

    MfG ChrisB

    --
    „This is the author's opinion, not necessarily that of Starbucks.“
  2. Hello,

    ich hab irgendwie Probleme das mit den Sessions zu verstehen.

    Eine Session ist nicht die Folge, sondern die Voraussetzung für ein "Login".
    Su solltest das daher auch entsprechend behandeln.

    Starte eine Session und schaue, wie diese funktioniert in der Verbindung Webserver-PHP-Client.
    Wie dies geht, steht im Handbuch unter http://www.php.net/manual/de/book.session.php ausführlich beschrieben. Schau dir auch die Benutzerhinweise (UCN) an. Dort findet man oft Tipps.

    Generell zum Handbuch von PHP:
    Und wenn Du es auf Deutsch einmal durchgelesen hast, versäume nicht, auch die englische Version zu studieren. Die enthält oft noch mehr Informationen, bessere Informationen, nicht so viele Fehler, wie die deutsche Übersetzung...

    Wenn Du dann die Session stabil aufgebaut bekommen hast und auch Daten sammeln konntest, dann kannst Du Dir überlegen, wie Du ein "Login" ermöglichst. Welche Zustände sollen da gepflegt werden?

    • Anmeldeberechtigung          bei jedem Request prüfen
    • Anmeldezeitpunkt             beim Anmelden eintragen
    • Rechte                       bei jedem Request prüfen,
                                     evtl. nur gezielt für die aufgerufene Ressource
    • Pausenlänge
    • maximale Einloggzeit
    • usw.

    Alle diese Daten sind Zustandsdaten der Session und gehören deshalb nicht in die Sessiondatei, sondern in die Datenbank. Dadurch sind sie jederzeit abfragbar. Die Sessiondatei gehört den Prozessdaten, die für den allgemeinen Zustand der Session irrelevant sind. Sie ist für die Administration quasi tabu, weil schwer ermittelbar und auch nicht jederzeit zugänglich.

    Liebe Grüße aus Syburg bei Dortmund

    Tom vom Berg

    --
    Nur selber lernen macht schlau
    http://bergpost.annerschbarrich.de
  3. 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

    --
    Silvesterfeuerwerk Onlineshop - selbst programmiert mit Hilfe der SelfHTML-Gemeinschaft