Sessions und Nutzer-Werte

Um dies dennoch zu ermöglichen, werden sog. "Sessions" (übersetzt "Sitzungen") eingesetzt, die bei jedem Aufruf an die URL angehängt werden. Eine Session ist eine lange, eindeutige, zufällige Zahl und sieht z.B. so aus: 241843576451019999416843714593.

baseportal erzeugt automatisch für jeden Aufruf eine "Session", falls keine übergeben wurde und schreibt diese in die Variable $_session. Bei angemeldeten Benutzern dient dies gleichzeitig zur Identifizierung, so dass nur beim ersten Aufruf die Anmeldung mit Name und Passwort nötig ist. Nach einer halben Stunde ohne Aktion läuft eine Session ab und die erneute Anmeldung ist nötig. baseportal merkt sich dabei die per URL oder Formular übermittelten Parameter, so dass sofort an derselben Stelle weitergearbeitet werden kann.

Auch für unangemeldete Gäste wird eine Session erzeugt, so dass man deren Aktionen auf der Webseite zuordnen kann. Wenn man dies nicht möchte, dürfen die Links einfach keine Session enthalten.

Session-Variablen

baseportal speichert beliebige Werte die zu einer "Sitzung" gehören. Diese werden im Hash %_session gehalten.

Hier ein Beispiel:

<perl>
$_session{Klicks}++;

out "Du hast $_session{Klicks} Mal geklickt. Willst Du nochmal <a href=\"baseportal.pl?htx=$htx&sid=$_session\">klicken</a>?";
</perl>

Hier wird also jeder Klick mitgezählt. Dies geschieht für den Nutzer im Hintergrund, d.h. er hat auch keine Möglichkeit den Wert zu verändern, wie dies der Fall wäre, wenn der Wert über die URL mitgegeben werden würde.

Wie man sieht sind hierbei keinerlei Befehle zum Lesen oder Speichern nötig, dies erledigt baseportal automatisch.

Komplexe Datenstrukturen mitführen

Auch beliebig komplexe Daten können mithilfe des Befehls serial in der Session mitgeführt werden:

<perl>
%hash=eval $_session{hash};

# ...

$_session{hash}=serial %hash;
</perl>

Ein klassisches Beispiel ist ein Warenkorb in einem Shop - der Nutzer streift auf den Seiten umher und legt durch Klicken Artikel in seinen Warenkorb. Die Sachen muss man nicht gleich in einer Datenbank speichern, weil er vielleicht garnicht einkauft. Aber merken muss man sich die Artilel natürlich schon - hier sind Sessions sehr gut geeignet:

<perl>
push @{$_session{Artikel}}, $Artikel if $Artikel ne "";
out "Ihr Warenkorb:".dump($_session{Artikel});
out "Artikel:<ul>";
for (qw(Brot Butter Marmelade))
{
  out "<li><a href=\"baseportal.pl?htx=$htx&sid=$_session&Artikel=$_\">$_</a><br>";
}
out "</ul>";
</perl>

Vor- und Nachteile von Session-Variablen

Session-Variablen sind für alle "flüchtigen" Daten da, die während einer "Sitzung" eines Nutzers mitgeführt werden sollen. Das kann man zwar auch alles in die URL schreiben, aber mit %_session hat man mehrere Vorteile:

• Sie sind für den Nutzer nicht sichtbar und damit auch nicht veränderbar. Es gibt Fälle in denen das Sinn macht, z.B. um einen Nutzer als "VIP-Kunden" zu kennzeichnen.
  
• Man muss die ganzen Werte nicht in jedem Link angeben, es reicht sid=$_session.
  
• Es lassen sich mit serial ganz einfach beliebig komplexe Daten mitführen:

  $_session{Komplexe_Daten}=serial \%Riesiger_Hash;
  

Es gibt allerdings auch Werte die man nicht in Session-Variablen speichern, sondern in der URL angeben sollte. Dazu gehören alle Werte die einen Zustand der Seite bestimmen und so bei der Weitergabe oder dem Speichern von Links wichtig sind. Manche Nutzer ändern diese Werte auch gern über die Adressleiste des Browsers. Beispiele sind in baseportal die "Id" eines Datensatzes der im Detail angezeigt wird oder die "range"-Angaben die den Bereich der Ausgabeliste bestimmen.