Wozu eigentlich noch Sessions

G

grkpfl

Hi!

Also ich verstehe einfach nicht was für Vorteile man durch Sessions in einem simplen Login-System erzielt.

Angenommen ich habe eine PHP Seite, welche man nur mit einem gültigen Login betrachten darf. Wieso dann nicht einfach ein Cookie mit verschlüsselten Username & Passwort setzten und auf Sessions verzichten Erspart doch eine menge Arbeit.

Oder entstehen dadurch irrgendwelche Sicherheitslücken

Vielen Dank,
grkpfl
 
Naja, es kommt immer drauf anwas man machen möchte.
Du kannst ja auch auf Cookies verzichten und gleich nur .htaccess machen ;)

Ne mal im ernst. Für eine kleine Seite, auf die nur ein paar Freunde und Bekannte zugreiffen sind Cookies absolut ausreichend, da man denen sagen kann, dass Sie Cookies zulassen sollen.
Wenn die Seite aber "vernünftig" gecodet wirken soll, dann sollte man den Usern nicht "die Kekse in den Mund stopfen"...

Ich sage nicht, dass Cookies schlecht sind (was aber meine Meinung ist, weil für den User immer ein Zwang besteht - "Du willst auf meine Seite? - Aber nur wenn du diesen Keks hier schluckst"), aber wenn man sich einmal die Arbeit mit Sessions gemacht hat, geht danach die ganze Programmierarbeit danach extrem viel schneller und einfacher.
 
Ich kann jetzt grad aus einem Projekt an dem ich gerade Arbeite dazu sagen das Sessions schon große Vorteile besitzen. Klar.. bei einem einfachen Loginsystem mit 2-3 Rechtestufen würden auch Cookies reichen. bei komplexen Rechtevergabe ist es allerdings so das man über eine Session ein Objekt ablegen kann das die entsprechenden Bitmuster für den einzelnen User zurückliefert und nebenbei hat der User auch keinen Zugriff darauf... sprich.. Cookies sind nicht der richtige Ort für sicherheitsrelevante bzw sensible Daten.

MfG Dominik

P.S. mit dem eigentlichen Login hat die Session ja eh nichts zu tun da du Sessions nicht zum Autologin o.ä. verwenden kannst
=> Kombination aus Keks und Session.. wer keinen Keks will muss halt aufs Autologin verzichten
 
Sessions bieten aber auch noch mehr Vorteile:

Du kannst Daten in Sessionvariablen ablegen, die Du dann von jedem x-beliebigem Skript während dieser Session benutzen kannst.

Sinnvoll z.B., wenn Du Deinen Usern etwas mehr Komfort anbieten möchtest. Obwohl es nicht so den großen Unterschied machst, ob Du $_SESSION['variable'] oder $_COOKIE['variable'] benutzt. Allerdings beim Setzen der Variablen vielleicht (Cookies gehen nur im Header zu setzen).
Ich persönlich denke auch, dass es sicherer ist, mich um die serverseitige Speicherung selber zu kümmern als es clientseitig dem User zu überlassen...

Ist aber wohl eher bei sicherheitsrelevanten Seiten eine Überlegung...

Micha
 
Mikey hat gesagt.:
Sessions bieten aber auch noch mehr Vorteile:

Du kannst Daten in Sessionvariablen ablegen, die Du dann von jedem x-beliebigem Skript während dieser Session benutzen kannst.

Sinnvoll z.B., wenn Du Deinen Usern etwas mehr Komfort anbieten möchtest. Obwohl es nicht so den großen Unterschied machst, ob Du $_SESSION['variable'] oder $_COOKIE['variable'] benutzt. Allerdings beim Setzen der Variablen vielleicht (Cookies gehen nur im Header zu setzen).
Ich persönlich denke auch, dass es sicherer ist, mich um die serverseitige Speicherung selber zu kümmern als es clientseitig dem User zu überlassen...

Ist aber wohl eher bei sicherheitsrelevanten Seiten eine Überlegung...

Micha
Dazu mal eine Frage:
Wenn cookies clientseitig sind, und sessions serverseitig.. wäre es vielleicht nicht zumindest dann auch sinnvoller wenn man z.b. bei 2000Hits am Tag das ein bisschen aufteilt um den Server zu entlasten? oder is das eher kaum bemerkbar?
Und vielleicht kennt jmd noch n gutes tut oda so, wo Session gut erklärt sind? hab mit dem Verständis so meine Probleme ! =(
 
Daensch hat gesagt.:
.. wäre es vielleicht nicht zumindest dann auch sinnvoller wenn man z.b. bei 2000Hits am Tag das ein bisschen aufteilt um den Server zu entlasten? oder is das eher kaum bemerkbar?=(
Grundsätzlich hast Du sicher recht, dass man vorher einige grundlegende Überlegungen anstellen sollte. Wenn Du z.B. seitenübergreifenden Komfort anbieten möchtest, kommst zu z.T. um Session-Variablen nicht herum. Natürlich ist alles sinnvoll, was den Server entlastet, solange es anders realisierbar ist.
Aber: Sessions funktionieren immer, Cookies könnten abgelehnt werden...

Anwendungs-Beispiel:
Ich zeige meinem Besucher dynamisch Daten aus einer Datenbank, sagen wir, Adressen. Der User kann auswählen, ob diese z.B. nach Name etc. sortiert werden, wieviele Sätze pro Seite etc. Er blättert nun durch und stoppt bei Adressen 31 bis 40.
Da er sich entschließt, zwischendurch mal auf die Kontaktseite zu wandern und eine Mail zu verschicken, kommt er irgendwann später wieder auf meine Adressseite zurück (also ohne irgendwelche Parameter).
Praktisch wäre nun doch, wenn sich der Server die o.g. Parameter gemerkt hätte, und der User sozusagen "seine alte Seite" wiederbekommt.

Dazu speichere ich diese Parameter in der Session.


Daensch hat gesagt.:
Und vielleicht kennt jmd noch n gutes tut oda so, wo Session gut erklärt sind? hab mit dem Verständis so meine Probleme ! =(
Naja, ein guter Ansatz wäre das PHP-Manual ;-) Ich will hier mal meine Vorgehensweise schildern, ohne dabei den Anspsuch zu stellen, ich hätte die Weisheit mit Löffeln gefressen und alles ist genauso und nur so wie ich es zeige, richtig. Aber es funktionert so.

Komme ich mal auf das Beispiel zurück, könnte ich Teile davon so realisieren:
PHP:
session_name ( 'MYID' ); // optional, aber dann bitte überall gleich!
session_start();
.
.
.
if ( isset ( $_GET['start'] ) 
  $_SESSION['start'] = $_GET['start'];
.
.
.
$query = sprintf ( "SELECT * FROM tabelle WHERE irgendwas LIMIT %d, %d", 
  $_SESSION['start'], $_SESSION['max'] );

Zur Erklärung:
session_start() beginnt die Session und muss in jedem PHP-Skript mehr oder weniger am Anfang stehen. Erst danach kann ich mit $_SESSION[...] auf Sessionvariablen zurückgreifen.
Da mir der von PHP vorbesetzte Namen der Session "PHPSESSID" nicht so gefällt, benutzt ich gerne meinen eigenen, dazu muss ich vor dem Session-Start session_name ( name ) aufrufen. Aber dass muss dann penibel genau auch in jedem Skript erfolgen! Sonst benutzen diese Skripte dann unterschiedliche Sessions (was u.U. an anderer Stelle gewünscht sein könnte).

Nehmen wir an, dass ich den Start-Wert mittels get übergebe. Wird ein neuer Wert übergeben, wird dieser in meiner Session gespeichert. In meiner späteren Verwendung greife ich dann ausschließlich auf diese Session-Variable zurück. Diese passt auch dann noch, wenn der User zwischendurch mal woanders war.
Oder aber, ich kann den Start-Wert in einem ganz anderen Skript überschreiben, falls gewünscht.

Klar, das hier noch einige Sachen fehlen - Gültigkeitsprüfungen und Standard-Werte. Aber das Prinzip sollte damit gezeigt sein, jetzt bist Du dran, damit herum zuexperimentieren...

Alles klar?

Micha
 
@Micha:

Ersma.. danke für die Gute Erklärung =)

Ich habe bei http://de2.php.net/manual/de/ref.session.php gelesen :
Einem Besucher wird beim Aufruf Ihrer Website eine eindeutige ID, die sogenannte Session-ID, zugeordnet. Diese wird entweder benutzerseitig in einem Cookie abgelegt oder in der URL übermittelt .
naja.. was ich meine is eigentlich, muss ich wenn ich von der Ersten Seite, wo ich meine Var festlege, und es in die 2te Seite übergebe und dort in die Session gebe, und erst in der 4ten Seite wieder nutzen möchte, nicht wieder zwischenzeitig irgendeine Abfrage kommen?

Es geht einfach nur $_SESSION('VAR')... nur wieso? =) ich versteh nicht genau wie er das behält!?
Er speichert das anscheinend in einem tmp ordner den ich festlegen kann, wenn ich das recht verstehe.. nur braucht er doch auch z.b. die IP und weitere Daten

Wollte nämlich meine Benutzerrechte irgendwie mit Sessions übergeben lassen.

Weisst du vielleicht wo ich infos über die Befehle $_POST / $_GET bekomme? Oberbegriff?

Und wieso wird in dem LOGIN SCript von tutorials.de die SESSION ID in der Datenbank gespeichert.. wenn man die später abfragt, bekomme ich infos von meinen alten Login´s (andere User getestet)

greetz
 
Zuletzt bearbeitet:
Hallo Daensch,

Du das alles völlig richtig verstanden! Der Besucher bekommt eine (eindeutige) Session-ID zugewiesen. Auf diese kannst Du mit session_id() zugreifen, z.B.:
1a795ccb911dc6930eeaa880db676878

Dazu erzeugt PHP eine temporäre Session-Datei mit Namen "sess_1a795ccb911dc6930eeaa880db676878" im temporären Verzeichnis (das Du mit phpinfo() abfragen kannst: "session.save_path = D:\PHP\sessiondata" ).

Da drin werden nun alle SESSION-Variablen abgelegt.

Damit diese ID während der ganzen Zeit bekannt ist, wird sie - wie geschrieben, im Cookie oder mit GET übergeben.
Probiere mal print_r ( $_COOKIE ); und Du bekommst:
Array
(
[PHPSESSID] => 1a795ccb911dc6930eeaa880db676878
)
Also hier wieder der Default-Name (oder der, welchen wir mit session_name(...) bestimmt haben.)
Wenn keine Cookies akzeptiert werden, wird die ID mit GET übergeben: index.php?PHPSESSID=1a795ccb911dc6930eeaa880db676878
Schau mal in so einem Fall in Deinen Browser-Quelltext. Da findest Du dann plötzlich alle Deine Links von PHP verändert:
<A HREF="neueseite.php?PHPSESSID=1a795ccb911dc6930eeaa880db676878">.... Auf gut deutsch: Du brauchst Dir überhaupt keine Gedanken über die Hintergründe machen, da kümmert sich komplett der Interpreter drum!

Somit kommt nun die (theoretische) Möglichkeit, dass sich jemand mit einer falschen ID in eine fremde Session hineinschleicht.... Vorausgesetzt, er kennt die ID ;-]

Damit erklärt sich auch Deine Frage, warum die ID zwischengespeichert wird und Du später wieder Zugriff drauf bekommst. Wenn Du session_id ( '1a795ccb911dc6930eeaa880db676878' ) benutzt, kommst Du nämlich auch wieder in diese Session (sinnvoll z.B. wenn Du weitere mit PopUps arbeitest, die auch Zugriff drauf haben müssen).

Hab mir das Login-Tutorial noch ncith angeschaut. Ich möchte mal so sagen:
Normalerweise "verfällt" die Session nach 180 Minuten ( => session_cache_expire(), siehe wie immer php_info... ), so dass Du Dich nicht drauf verlassen solltest, dass nach 10 Tagen immer noch die alten Daten existieren! Unter einer Session verstehe ich: Der Besucher kommt / springt von einer Seite zur anderen / und dann ist er wieder weg. Damit ist die Session beendet und beim nächsten Mal geht das Spiel von vorne los.

Also solltest Du für ein Login die Rechte in einer Datenbank speichern, bei erfolgreichem Login benutzt Du z.B. Parameter wie $_SESSION['USER']="Karl-Gustav" und $_SESSION['USERSTATUS'] = 255;

GET/POST ist jetzt wohl der Zeitpunkt für einen neuen Thread...
Kurz gesagt:
GET wird in der URL übergeben: seite.php?zahl=4711&zeichen=trallalla.
Das kannst Du so im A HREF verzeichnen oder in Deinen Browser eingeben (und manipulieren!)
POST kann nur in Formularen mit <FORM ACTION="POST" ...> übergeben werden. Die Daten werden im Header übertragen und bei "Seite aktualisieren" bekommst Du die berühmte Meldung "Seite kann ohne erneutes Senden der Daten nicht angezeigt werden".

POST hat den Vorteil, dass mehr Zeichen übergeben werden können und es sicherer ist. Für Dein Login-Formular mit Name/Passwort solltest Du also theor. POST nutzen.
GET ist dafür cacheable aber einfach zu manipulieren.

Die beste Referenz für PHP ist PHP selber. Am Besten lädst Du Dir von php.net das deutsche Handbuch (ich benutze das CHM-File). Dort kannst Du alles ausführlich nachschlagen. Zu Empfehlen ist auch das Kapitel über Sicherheit!

Viel Spaß...
Micha
 
Zurück