Session-Verarbeitung mit Perl
Gerhard
- perl
Hallo,
ich suche
ich suche
- eine einfache Beschreibung über Sinn und Zweck von Sessions
Der Sinn und Zweck einer Session ist, eine möglichst eindeutige User-Agent Identifizierung zu ermöglichen, um damit innerhalb eines verbindungslosen Protokolls (http) einen zustandsbezogenen Datenaustausch zu erlauben.
- ein einfaches Beispiel für Sessionverarbeitung in Perl
Es gibt mehrere Techniken.
Die wohl einfachste verwendet das CGI Modul und Cookies.
Beispiele im Netz gibt's genug wie dieses.
http://habett.com/perl/apasessen.html
mfg Beat
Danke Beat,
geht es aber auch ohne Cookies?
Gruß
Gerhard
geht es aber auch ohne Cookies?
Klar, dann musst du aber dafür sorgen, dass die Session ID übertragen wird.
Struppi.
geht es aber auch ohne Cookies?
Zunächst musst du die Unterschiede erkennen:
Browser senden alle Cookies per Request an die angegebene Domain, ergo die Session-ID.
Wenn aber eine Session-ID in einem Formular oder Link gespeichert wird, dann wird die Session-ID nur übertragen, wenn dieses Element auch aktiviert wird.
Cookie Sessions machen es schwerer, dass man mit dem selben Agent mehrere Sessions haben kann. Cookie Sessions sind aber in einem gewissen Sinne sauberer, da nie die Gefahr besteht, dass eine aktive Session-ID aus einer Seite in einem Forum wie diesem gepostet wird, und dann Gäste plötzlich die Session erben.
Dagegen braucht es bei Session-IDs in Urls einige Sicherheitsmassnahmen.
Ich selbst verwende Sessions ohne Cookies, weil ich gerne mit parallelen Sessions arbeite. Das bedingt aber auf der anderen Seite einige Vorsicht.
a) Eine Session ist durch One-Time-Session IDs definiert. Eine verbrauchte Session wird nicht gelöscht, sondern bemakelt. Wird eine solche ID nochmals verlangt, wird die ganze User-Session gekillt.
Die ID setzt sich zusammen aus statischerTeil-oneTimeTeil.
Der statische teil wird durch das Login erzeugt, der oneTime-Teil wird mit jedem Request erneuert.
b) In die ID Prüfung wird zusätzlich ein IP/16 check einbezogen.
Man könnte durch eine Kombination von Url-Session-IDs mit einem anderen Cookie gespeicherten Identifikatoren diese marginale Unsicherheit gänzlich ausräumen.
Die Session-Id unterliegt einer Lifetime. Anders als bei Cookies ist es nicht die Session als ganzes, welche eine bestimmte zeit gültig ist, sondern jeweils die zuletzt angeforderte Session-ID.
Bei mir können registrierte User die Dauer dieser Lifetime anpassen.
Der Nachteil davon ist, dass bei mir die eingeloggten User kein Page Reload oder history back mit anschliessender Linkauslösung verwenden können, ohne dass die Session bricht.
Bezüglich Robots weiss ich nicht zu sagen, was besser ist. Ich deaktiviere für Bots Links mit Session-ID.
Auf jeden Fall soll eine Sessin ID so aufgebaut sein, dass sie möglichen Kollisionen widersteht.
Summarisch:
Braucht man nicht mehrere parallele Sessions, so sind Cookies besser.
Jedoch bin ich überzeugt, dass man auch mit Cookies parallele Sessions in Grenzen einrichten kann.
mfg Beat
Danke für die ausführliche Antwort.
Für mich ist da aber vieles noch unverständlich.
Ich versuche mal das von Dir angegebene Beispiel zum Laufen zu bringen.
Der zweite Schritt wäre dann die Umgehung der Cookies.
Wenn ich Dich und Struppi richtig verstanden habe, muss ich dann die Session-ID in einem Formular (als hidden-field) übergeben?
Danke
Gerhard
Ich versuche mal das von Dir angegebene Beispiel zum Laufen zu bringen.
Ich würde da mal weiter suchen. Ich bin nicht überzeugt von dem selbst verlinkten Beispiel.
Dort werden Sessions auf dem Server in mehreren separaten Files verwaltet, und ich bezweifle, dass so was sinnvoll ist.
Der zweite Schritt wäre dann die Umgehung der Cookies.
Wenn ich Dich und Struppi richtig verstanden habe, muss ich dann die Session-ID in einem Formular (als hidden-field) übergeben?
Ja.
mfg Beat
Wenn ich Dich und Struppi richtig verstanden habe, muss ich dann die Session-ID in einem Formular (als hidden-field) übergeben?
Nein, Du kannst auch die Session-ID an jeden Link anhängen und auswerten, ganz ohne Formular.
Siechfred