tinchen

Hallo,

ich bin ja nun schon eine ganze Weile dabei und habe mir nun auch einiges zum Thema durchgelesen, aber irgendwie habe ich das Gefühl, dass da irgendwo ein Denkfehler ist oder mir da noch ein paar Fragen offen geblieben sind.

Wie gesagt es geht um das Thema Sessions.

Wenn ich innerhalb eines PHP Skripts
$_SESSION['var'] = $var;
schreibe, wird dann für jeden User, der das Skript aufruft und diesen Wert in die Session schreibt ein unterschiedlicher Wert gespeichert oder muss man das in irgendeiner Form vorher festlegen? Wie geht das genau von statten? Wie kommunizieren Server und PHP genau um dem Clienten den jeweiligen Wert zum Beispiel beim Auslesen zurückzugeben? Kann man auf Daten in der Session bezüglich eines Users zugreifen, ohne dass man der User ist?

Also Fragen über Fragen. Wenn ich in diese Erklärungen zu Sessions sehen, geht da aus meiner Sicht nichts draus hervor, was meine Fragen beantwortet. Mag ja auch sein, dass ich da irgendwie zu kompliziert denke?

Viele Grüße
Tine

Mister Ad

Der_Gerhard

Hi Tinchen,

ohne Garantie für Korrektheit...

Zu jeder Session gehört eine eindeutige Session-ID. Diese wird per Cookie beim Besucher hinterlegt oder als Parameter an die URL angehängt.
Damit kannst Du verschiedene Besucher unterscheiden bzw. kriegt jeder seinen eigenen Wert zugewiesen.

Im Hintergrund werden alle Daten, die zu der Session gehören in Dateien oder in einer Datenbank gespeichert. Darum musst Du Dich normalerweise nicht kümmern. Aber am Anfang des Scripts musst Du session_start() aufrufen. Sonst kannst Du nicht drauf zugreifen.

Die Session wird dabei natürlich nur auf dem Server gespeichert, wo PHP läuft. Der Client kriegt davon nichts mit. Nur was Dein Script draus macht, kriegt der geliefert.

Damit kann man normalerweise auch nicht auf andere Sessions zugreifen.

Wenn man allerdings eine andere gültige Session-ID findet könnte man sich als anderer Besucher ausgeben. Aber an die ID muss man erstmal ran kommen.

Gruß
Gerhard

__________________
**********************************
Nein, ich bin nicht die Signatur.
Ich putze hier nur.
**********************************

Zergling-new

Eigentlich werden alle deine Fragen hier beantwortet:
http://de.php.net/manual/de/ref.session.php

nikosch

Ich finde den Verweis aufs Handbuch nicht so recht hilfreich, irgendwie wird da das Pferd von hinten aufgezäumt. Ehrlich gesagt habe ich anfangs auch etwas gebraucht, um die Session Funktionalität richtig zu kapieren. In kurzen Worten:

Da php eine serverbasierte Sprache ist und die Kommunikation mit dem Browser des Users wie für Server-Client Kommunikation üblich, für http typisch zustandslos erfolgt - was bedeutet, dass für jede Datenübertragung eine eigene Verbindung hergestellt und nach Erfolg wieder verworfen wird - kann es nicht möglich sein, eine bestimmte Information über mehrere Seitenaufrufe zu halten. Selbst wenn der Server eine ihm übersandte Menge Daten in einer Datei oder Datenbank speichert, kann er bei einer anschließend erfolgenden Anfrage auf diese Daten nicht feststellen, ob dieser Request vom selben Client oder von einem anderen her erfolgt. Die Daten müssen also mit einer eindeutigen ID verknüpft werden, die dem Server beim jeweiligen Request mit übermittelt wird (und anhand derer er den Client sozusagen wiedererkennt). Würde ein x-beliebiger anderer Client dieselbe ID bei einer Anfrage mitsenden, so erhielte er die Daten also ebenso wie der echte Gesprächspartner (Session riding).
Als gute Möglichkeit für eine Übergabe der sog. Session-ID eignet sich die Speicherung in Cookies, da der Browser die darin enthaltenen Daten ohnehin automatisch bei jedem Seitenaufruf mitsendet. Aber auch eine Übergabe per URL Parameter ist eine Möglichkeit.

Sessions sind also sozusagen ein abstraktes Speicherkonzept, das anhand einer ID-Übermittlung funktioniert. Alle gewünschten vorzuhaltenenn Inhalte müssen über Ihren Variablennamen registriert werden (das ist auch über den Zugriff auf die superglobale $_SESSION möglich). Dem Session Mechanismus wird also mitgeteilt, welche Daten er am Scriptende speichern soll. Bei Scriptaufruf werden alle im zugehörigen Speicherplatz enthaltenen Daten unter dem dort hinterlegten Schlüssel als gleichnamige Variable bereitgestellt.

Das war so einigermaßen das Wesentliche.

PsychoEagle

Ich hatte mal das Problem bei ner Seite, dass Google die Seite mit der Session ID aufgelistet hatte, und jeder der über Google kam, war als ein bestimmter Kunde eingeloggt. Das war nicht so toll.

Also Sessions kann man "klauen" wenn man eine gültige ID besitzt, und wenn bei deinem Webspace / Server die Session nicht ablaufen kann, kann das ein großes Sicherheitsrisiko sein.

Deshalb ist es auch immer recht sinnvoll, sich auszuloggen (mit logout)

Grüße
Da Psy

__________________
"Weaseling out of things is important to learn. It's what separates us from the animals ... except the weasel." (Homer J. Simpson)

tinchen

Demnach ist also die Session in gewisser Weise an Cookie oder URL Parameter gebunden. Der Cookie wird also mit dem Namen PHPSESSID, sofern nicht anders angegeben gespeichert. Wenn ich das nun richtig verstanden habe ist das Anhängen des URL Parameters zum Beispiel als sid etc. optional. Heißt also auch, dass wenn clientseitig keine Cookies gesetzt werden können - warum auch immer - die Session nicht mehr richtig funktioniert?

Wenn man nun hinginge und die Session ID datenbankseitig speichere und einen Timestamp vergebe, wann die Session beendet werden soll (was auch serverseitig geht) um dann nach Ablauf der Zeit eine bestimmte Session eines Users zu löschen, habe ich in der Doku immer noch keinen Ansatz gefunden wie oder ob das überhaupt geht. Also kann man per PHP auf eine bestimmten SessionEintrag mit der ID xyz zugreifen und diese löschen/beenden etc.

Zudem stelle ich mir die Frage, ob die Arbeit einer Session nicht auch in gewisser Weise von einem Objekt übernommer werden kann. Dieses Objekt kann ja auch über einen Laufzeitkarakter verfügen und steht dem User zum Beispiel nach einer Anmeldung in bestimmter Weise zur Verfügung. Das so zu händeln ist sicherlich nicht immer sinnvoll aber doch möglich. So könnte man das Ganze noch mit Cookie und Datenbank aufbessern.

Um über so etwas nachdenken zu können, muss man aber erst einmal verstehen, wie die Session überhaupt tickt. Wenn ich dann in der Doku lese:
>>Einem Besucher wird beim Aufruf Ihrer Website eine eindeutige ID, die sogenannte Session-ID, zugeordnet.<<
stellte sich mir sofort die Frage wie. Ist ja gut, dass Session Cookies automatisch geschrieben werden, aber es könnte ja genauso sein, dass man sich um eine solche Verwaltung noch selbst kümmern muss. Wenn man es weiß, dann ist es sicherlich jedem klar, aber wenn nicht, empfinde ich das nicht als sehr eindeutig. Da möchte ich an vielen Stellen ständig fragen: Wie? Automatisch? Geht das auch anders?

Vielen Dank für eure Antworten.
Grüße
Tine

nikosch

zu 1/ Sessions beschränken sich nicht auf Cookies. Du kannst stets auch mit URL oder POST Parametern arbeiten. Wie oben beschrieben mußt Du dem Server nur quasi per ID mitteilen, welche Session er "raussuchen" soll.
Das Problem bei GET Parametern ist eben das von PsychoEagle beschriebene: SessionIDs finden sich in Logfiles, Cachespeichern, Googlelinks und werden für Phishing Attacken benutzt.

zu 2/ Standardmäßig verwalten die Session Funktionen die Daten in Dateien im Filesystem. Um mit Sessions in der DB zu arbeiten, werden mit session_set_save_handler () die Zugriffsfunktionen überschrieben (neu gesetzt).

zu 3/ Denk nochmal drüber nach. Sobald das Objekt sich irgendein Datum merken soll, muss wieder serialisiert werden oder über einen sonstigen Mechanismus der Datensatz an den entspr. User gebunden werden. IP's sind dafür ungeeignet und Cookies nur wenn der Browser sie speichert. Zudem kann es auch gewünscht sein, dass Daten nicht veränderbar sind (was in einem Cookie ohne weiteres möglich wäre) und deshalb auf dem Server gespeichert werden müssen.

zu 4/ Man kann es etwa so runterbrechen: session_start () sagt dem System, du möchtest die Session Funktionalität nutzen. Wurde beim entspr. Request ein Parameter übermittelt, der dem Setting für den Identifier entspricht, wird dieser als vorhandene Session interpretiert, ob nun schon Daten hinterlegt sind oder nicht. Ansonsten wird ein neuer leerer Datensatz erstellt und unter der ID füür die Folgeaufrufe gespeichert. (Genau gesagt werden Session Daten erst mit dem Eintrag des ersten Wertes physisch gespeichert). Wie gesagt, ich finde das Manual machnmal auch etwas mager. Aber zu diesen Mechanismen findest Du auch andere Quellen im Netz.

zu 5/ Gerne.

Zergling-new

Cookie und URL sind nur die Träger des Schlüssel, aber ja.

Nicht optional, sondern vielmehr alternativ. Wenn das Cookie-Setzen nicht klappt, dann passiert es eben per URL-Rewrite, auch das wird automatisch durchgeführt, siehe "url_rewriter.tags". Allerdings vertrau ich der Technik nicht so ganz. Deaktivier hier mal Cookies im Forum, es wird dann zwar eine Session-ID per URL übergeben, es funktioniert aber trotzdem nicht.

Probleme gibts mit der URL-übergebenen ID, wenn du Links mit JavaScript erzeugst, da musst die Session-ID samt Schlüssel und Wert selbst dranhängen.

Auf den Garbage-Collector kannst du dich nicht verlassen.
http://de.php.net/session_destroy
macht auch nicht immer das was es soll, manchmal kann man sich ausloggen und mit History-Back doch wieder zurück und ist immernoch (oder wieder?) eingeloggt.

Mit
http://de.php.net/manual/de/function...ve-handler.php
kannst du dir eben einen eigenen Handler schreiben, ist nicht einmal schwierig. Das Löschen musst du jedoch manuell per Timestamp-Vergleich durchführen. Heißt: Speicher bei jeder Verwendung den Timestamp in die Session; Prüf jetzt vor jeder Verwendung der Session, ob der Timestamp + Zeit seither <= erlaubte Idle-Zeit ist. Wenn nicht, ausloggen!


Wozu, ich meine es geht garnicht einfacher als bisher, du kannst ja sogar session.auto_start auf 1 stellen, dann kannst du sofort auf $_SESSION zugreifen, weniger Code geht nicht. Alles was du jetzt noch an Code oder Objekten dazubläßt, wird dir das Handling nur verkomplizieren.

Und wie gesagt, das Session-Handling über eine Datenbank kannst du mit dem Session-Save-Handler ja selbst erstellen. Aber verwende den session_set_save_handler() und versuch nicht das Session-Handling mit eigenen Objekten nachzubauen.


Du hast die Session-Seite nicht durchgelesen oder? Am Ende ist ein Beispiel, einfach mal testen und anwenden, sonst machen die Fragen nach dem Eingemachten noch nicht wirklich Sinn