Gerhard: Session-Verarbeitung mit Perl

Hallo,
ich suche

  • eine einfache Beschreibung über Sinn und Zweck von Sessions
  • ein einfaches Beispiel für Sessionverarbeitung in Perl
    Ich arbeite auf einem Apache-Server.
    Mit bestem Dank
    Gerhard
  1. 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

    --
    Woran ich arbeite:
    X-Torah
       <°)))o><                      ><o(((°>o
    1. Danke Beat,
      geht es aber auch ohne Cookies?
      Gruß
      Gerhard

      1. geht es aber auch ohne Cookies?

        Klar, dann musst du aber dafür sorgen, dass die Session ID übertragen wird.

        Struppi.

      2. 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

        --
        Woran ich arbeite:
        X-Torah
           <°)))o><                      ><o(((°>o
        1. 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

          1. 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

          2. 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

            --
            Hinter den Kulissen passiert viel mehr, als man denkt, aber meistens nicht das, was man denkt.