Session -> Cookie vs URL-Parameter

[Nina]

hi!
schon lange verwende ich sessions mit $_SESSION und session_start()...
eigentlich kümmert sich php ja selbst darum, ob eine session in den cookies gespeichert wird, oder ob es "nur" bei den urls angehängt wird.
nun will ich aber bei dem login formular eine option hinmachen, die wählen lässt, ob ggf. cookies und damit dauerhafte logins gemacht werden sollen. oder ob nach schließen des browser wieder alles größtenteils vergessen sein sollte, was die session betrifft, was dann durch ?PHPID=... geschehen würde.
nun fand ich leider nicht die funktion/option heraus, die php dazu anleitet, ein bestimmtes verfahren, je nach auswahl, zu verwenden.
danke für hinweise, wie die funktion heißt.

[eddi]

Hallo,

wenn Du bereits keine Ahnung hast, daß man serverseitig bestimmt Cookies ebenfalls durch Schließen des Browsers löschen kann, warum sollten sich Dein Nutzer mit der Thematik besser auskennen als der Programmierer und hier eine Auswahl treffen. Die Zeitdauer, wann Session Cookies verfallen wird durch die Direktive session.cookie_lifetime bestimmt. Diese ist defaut "0" Sekunden.

schon lange verwende ich sessions mit $_SESSION und session_start()...

Toll! Dann ist es längst Zeit sich mit den Grundlagen zu beschäftigen RFC 2109.

eigentlich kümmert sich php ja selbst darum, ob eine session in den cookies gespeichert wird, oder ob es "nur" bei den urls angehängt wird.

Auch hier ist Grundlagenforschung angesagt. PHP tut dies nur aufgrund einer Konfiguration

nun will ich aber bei dem login formular eine option hinmachen, die wählen lässt, ob ggf. cookies und damit dauerhafte logins gemacht werden sollen. oder ob nach schließen des browser wieder alles größtenteils vergessen sein sollte, was die session betrifft, was dann durch ?PHPID=... geschehen würde.

Bei begründetem Vorzug einer URL-Parameterübergabe gegenüber deaktivierbarer Cookie-Funktionalität eines Clients hoffe ich aber, Du siehst ein, daß das an und für sich Blödsinn ist.

nun fand ich leider nicht die funktion/option heraus, die php dazu anleitet, ein bestimmtes verfahren, je nach auswahl, zu verwenden.
danke für hinweise, wie die funktion heißt.

Konfigurationen PHPs lassen sich, wenn die Direktiven "PHP_INI_ALL" gesetzt sind, durch ini_set() überschreiben.

Gruß aus Berlin!
eddi

[Tom]

Hello,

Eddi hat Dir ja schon was geschrieben. Nimmst nicht übel, sondern ernst ;-))

Der Client hat üblicherweise zwei Methoden, um Requests durchzuführen

GET   Alle für den request notwendigen Paramter müssen über die URL übergeben werden

POST  Request-Parameter werden hauptsächlich im Request-Body als Datenpärchen (Name=Wert)
        übertragen

Der Request besteht aus einem

HEAD  Enthält die sogenannten "Header"
  BODY  Enthält zusätzliche Paramter, kann auch leer sein oder fehlen

Zusätzlich können im HEAD übertragen werden

COOKIES
  AUTH-CREDENTIALS

Für die Führung einer Session eignen sich besonders gut die zusätzlichen Angaben im Header. Du kannst Sessions damit auf zwei Arten aufbauen

SESSION after AUTHENTICATE          das geht z.B. mittels Basic Auth des Apachen
  SESSION before AUTHENTICATE         das geht z.B. mit Cookies

Ob der Cookie nun nur temporär vom Browser gehalten wird, und daher nur solange wieder mitgesandt wird, bis die Browser-Instanz beendet wird, oder ob Du einen (zweiten) permanenten Cookie auf dem Client speichern lässt, der dann eine Authentifikation ermöglicht, ist Geschmackssache.

Im Wesentlichen müsste das dann so aussehen

if (isset($_COOKIE['PERM_SESSION'])
  {
    session_name('PERM_SESSION');
    session_save_path(PFAD_FUER_PERMANENTE_SESSIONDATEIEN);
    session_start();
    $_SESSION += get_defaults_des_Users_aus_DB ($_COOKIE('PERM_SESSION');
  }
  else
  {
    ## benutze Standard-Session-Namen
    session_start();
  }

Und den Rest kennst Du dann ja schon.
Bei Veränderung von Defaults diese in der DB speichern (als permanenter Sessionspeicher)

Das dauerhafte Verwenden einer permantenen Sessiondatei erfordert noch Diskussion.
Die Wahrscheinlichkeit der Entführung einer solchen Datei wächst mit der Dauer der Benutztung.
Man muss also zusätzliche Maßnahmen ergreifen.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Tom]

Hello,

Hello,

Eddi hat Dir ja schon was geschrieben. Nimmst nicht übel, sondern ernst ;-))

Der Client hat üblicherweise zwei Methoden, um Requests durchzuführen

GET   Alle für den request notwendigen Paramter müssen über die URL übergeben werden

POST  Request-Parameter werden hauptsächlich im Request-Body als Datenpärchen (Name=Wert)
        übertragen

Der Request besteht aus einem

HEAD  Enthält die sogenannten "Header"
  BODY  Enthält zusätzliche Paramter, kann auch leer sein oder fehlen

Zusätzlich können im HEAD übertragen werden

COOKIES
  AUTH-CREDENTIALS

Für die Führung einer Session eignen sich besonders gut die zusätzlichen Angaben im Header. Du kannst Sessions damit auf zwei Arten aufbauen

SESSION after AUTHENTICATE          das geht z.B. mittels Basic Auth des Apachen
  SESSION before AUTHENTICATE         das geht z.B. mit Cookies

Ob der Cookie nun nur temporär vom Browser gehalten wird, und daher nur solange wieder mitgesandt wird, bis die Browser-Instanz beendet wird, oder ob Du einen (zweiten) permanenten Cookie auf dem Client speichern lässt, der dann eine Authentifikation ermöglicht, ist Geschmackssache.

Im Wesentlichen müsste das dann so aussehen

if (isset($_COOKIE['PERM_SESSION']))

{
    session_name('PERM_SESSION');
    session_save_path(PFAD_FUER_PERMANENTE_SESSIONDATEIEN);
    session_start();

$_SESSION += get_defaults_des_Users_aus_DB ($_COOKIE['PERM_SESSION']);

}
  else
  {
    ## benutze Standard-Session-Namen
    session_start();
  }

Und den Rest kennst Du dann ja schon.
Bei Veränderung von Defaults diese in der DB speichern (als permanenter Sessionspeicher)

Das dauerhafte Verwenden einer permantenen Sessiondatei erfordert noch Diskussion.
Die Wahrscheinlichkeit der Entführung einer solchen Datei wächst mit der Dauer der Benutztung.
Man muss also zusätzliche Maßnahmen ergreifen.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[wahsaga]

hi,

nun will ich aber bei dem login formular eine option hinmachen, die wählen lässt, ob ggf. cookies und damit dauerhafte logins gemacht werden sollen.

Dabei hilft dir der Session-Cookie bzw. seine Lebenszeit aber nicht sinnvoll weiter.

Du kannst zwar, wie eddi schon beschrieb, eine Lebenszeit für den Cookie, der die Session-ID übermittelt, vorgeben, so dass er über das Schließen der Browserinstanz hinaus erhalten bleibt (bleiben sollte).

Das bringt dir aber noch nicht unbedingt viel, so lange du nicht auch die "Lebenserwartung" der Session-Dateien auf dem Server erhöhst.
Diese werden nämlich nach einer bestimmten Zeitspanne als "Garbage", Müll, betrachtet, der dann vom zufallsgesteuert angeworfenen Garbage Collector aus dem Verzeichnis für die Session-Dateien "rausgeputzt" werden darf.

Um auch das zu beeinflussen, müsste also auch noch an der Option session.gc_maxlifetime rumgeschraubt werden.

Das wiederum würde ich aber nicht empfehlen, da damit die kompletten Session-Dateien eine erheblich längere Lebensdauer bekommen - dein Verzeichnis für die Session-Dateien wird sehr viel voller werden, wenn die Dateien länger "aufbewahrt" werden.

Die besser Alternative dürfte es also sein, für einen Login über die Surf-Sitzung hinaus die zum Login benötigten Daten in einem eigenen Cookie zu speichern - also beispielsweise den Usernamen/-ID, und einen _Hash_ des Passwortes (NICHT im Klartext dort ablegen, sollte klar sein), mit dem du auf der Datenbank o.ä. überprüfen kannst, ob der Nutzer, dessen Browser dir diese Werte im Cookie gesandt hat, Login-berechtigt ist.
Du fragst also ab, ob dein Script einen solchen Cookie empfangen hat - wenn ja, und damit ein gültiger Login möglich ist, dann startest du eine neue Session, und kennzeichnest darin den Nutzer als eingeloggt.

gruß,
wahsaga

[Tom]

Hello,

Um auch das zu beeinflussen, müsste also auch noch an der Option session.gc_maxlifetime rumgeschraubt werden.

Nein. das wäre der falsche Weg.
Die Session-Dateien stellen die unterste Schicht der Session dar.
Sie dienen der unauthorized Session

Wenn man eine Authorized Session aufbauen will, muss man eine Schicht draufsetzen, und dann kommt üblicherweise die Datenbank hinzu.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[wahsaga]

hi,

Um auch das zu beeinflussen, müsste also auch noch an der Option session.gc_maxlifetime rumgeschraubt werden.

Nein.

Doch, wenn man das erreichen möchte, was ich beschrieb - dass zu einem über die Sitzung hinaus im Browser abgelegten Cookie mit der Session-ID dann auch bei späterem Aufruf die zugehörigen Session-Daten noch verfügbar sein sollen - dann müsste man auch an dieser Einstellung schrauben.
Weil sonst zwar die Session-ID länger erhalten bleibt, aber die Daten dazu zwischenzeitlich geputzt worden sein könnten.

das wäre der falsche Weg.

Dass ich dieses Vorgehen für das hier gewünschte Verhalten eines dauerhaften Logins auf Cookie-Basis ebenfalls nicht für günstig hielte, sagte ich ja.

gruß,
wahsaga