Wie verwendet man Sessions sinvoll?

[Andreas-Lindig]

Hallo Forum,

Ich hätte da mal eine grundsätzliche Frage.

Kleine Vorgeschicht:
Ich baue gerade mein Projekt umständlich um, weil sich Leute - zu Recht - beklagt haben, daß ich ihren Brauser-Back-Button lahmgelegt habe und sie Seiten von diesem Projekt nicht bookmarken können.

Hintergrund:
Ich habe alle Eingabe- und Auswahl-Werte in Sessions gespeichert und habe jede Seite quasi als eigenständiges Objekt behandelt, das sich die nötigen Informationen immer aus der Session selbst besorgt (da fand ich mich ziemlich genial ;)

Nun haben die Seiten aber eben keinen eindeutigen Query-String und z.B. das Suchergebnis ist nur in Verbindung mit der Session abrufbar. Wenn jetzt jemand diese Seite bookmarkt, bekommt er beim nächsten mal die Suchergebnissse nicht mehr. Oder: in den einzelnen Trefferseiten werden die gefundenen Wörter farbig markiert - wenn ich jetzt jemandem einen Link auf diese Seite schicke, kann er die zwar mittlerweile aufrufen, aber die Treffermarkierung ist natürlich futsch.

Zurück zur Frage:
Wenn eine anständig eindeutige Seite immer den Query-String braucht, kann ich doch gleich immer alle Daten so übergeben. Wofür kann ich dann dann noch Sessions sinnvoll einsetzen?

Gruß, Andreas

[Vinzenz]

Hallo Andreas-Lindig,

Wenn eine anständig eindeutige Seite immer den Query-String braucht, kann ich doch gleich immer alle Daten so übergeben. Wofür kann ich dann dann noch Sessions sinnvoll einsetzen?

in folgendem Szenario setze ich selbst Sessions ein:

• keine HTTP-Authentifizierung möglich
• Zugangsbeschränkung erforderlich

Auf der Login-Seite erfolgt der Sessionstart,
auf allen folgenden Seiten werden entsprechende Sessionvariablen überprüft,
enthalten sie keine gültigen Werte, so erfolgt ein Redirect auf die Loginseite.

Freundliche Grüsse,

Vinzenz

[Andreas-Lindig]

Hallo Vinzenz,

also _nur_, um die Rechte des Besuchers zu überprüfen?

Gruß, Andreas

[Vinzenz]

Hallo Andreas-Lindig

also _nur_, um die Rechte des Besuchers zu überprüfen?

in meinem Fall ist nicht mehr notwendig, deswegen lasse ich es dabei.
Es war ärgerlich genug, dass keine HTTP-Authentifizierung möglich war :-(

Man könnte aber bestimmt viel mehr machen.

Freundliche Grüsse,

Vinzenz

[Harry]

Holladiewaldfee,

also _nur_, um die Rechte des Besuchers zu überprüfen?

Für jegliche Art von Benutzerdaten, die Du von einer Seite zur anderen retten mußt und die der Besucher nicht zu sehen bekommen darf oder die nicht in der URL auftauchen oder in irgendeinem clientseitigen Cache vor sich hinschimmeln dürfen (z.B. Login-Daten).

Und wenn Du dann eh schon Sessions verwendest, kannst Du unwichtigen Kram auch gleich in die Session auslagern und mußt ihn nicht in der URL mit rumschleppen.

Ciao,

Harry

[Andreas-Lindig]

Hallo Harry,

Schnee :) Skitour gefällig?
http://harry.ilo.de/projekte/berge/

da sind ja geile Fotos drauf :) darf ich davon mal eins oder zwei benutzen?

Gruß, Andreas

[Harry]

Holladiewaldfee,

http://harry.ilo.de/projekte/berge/

da sind ja geile Fotos drauf :) darf ich davon mal eins oder zwei benutzen?

Danke, Danke :) Solange es um eine nichtkommerzielle Sache geht, kannst Du sie gerne verwenden. Sag bescheid, wenn Du ein Bild in einer "vernünftigen" Auflösung haben willst - die hatten im Web keinen Platz mehr ;) Und natürlich freu ich mich zu erfahren, wo meine Bilder denn so hingekommen sind :)

Falls Du was bestimmtes suchst schreib mir einfach 'ne eMail, dann such ich mal'n paar passende Bilder raus. Das im Web sind vielleicht 20% der Bilder, die ich auf den Touren gemacht habe - und ein paar der schönsten schlummern immer noch auf meiner Platte ... hauptsächlich weil ich noch nicht Zeit hatte, das drumherum zu basteln :(

Ciao,

Harry

[Lude]

Hi,

Hintergrund:
Ich habe alle Eingabe- und Auswahl-Werte in Sessions gespeichert und habe jede Seite quasi als eigenständiges Objekt behandelt, das sich die nötigen Informationen immer aus der Session selbst besorgt (da fand ich mich ziemlich genial ;)

ich wuerde sagen "Seiten" sind eigenstaendige Objekte. Aber was sind Sessions?

Nun haben die Seiten aber eben keinen eindeutigen Query-String und z.B. das Suchergebnis ist nur in Verbindung mit der Session abrufbar.

Und die Session ist irgendwann ausgetimt? Bitte praezisieren.

Wenn eine anständig eindeutige Seite immer den Query-String braucht, kann ich doch gleich immer alle Daten so übergeben. Wofür kann ich dann dann noch Sessions sinnvoll einsetzen?

Was ist mit "Query-String" gemeint?

Gruss,
Lude

[Peter]

Und die Session ist irgendwann ausgetimt? Bitte praezisieren.

Was ist ausgetimt? Bitte präzisieren.

[Lude]

Hi,

Und die Session ist irgendwann ausgetimt? Bitte praezisieren.

Was ist ausgetimt? Bitte präzisieren.

was ist 'was'? Bitte praezisieren.

Dulle Gruesse,
Lude

[MudGuard]

Hi,

Wenn eine anständig eindeutige Seite immer den Query-String braucht, kann ich doch gleich immer alle Daten so übergeben. Wofür kann ich dann dann noch Sessions sinnvoll einsetzen?

Theoretisch ja, praktisch gibt es da aber in real existierender Software Begrenzungen.
IE erlaubt IIRC nur bis zu 2K, Apache in der Standard-Compilierung 8K.

Sessions sind m.E. dann sinnvoll, wenn z.B. Seiten nur in bestimmter Reihenfolge aufgerufen werden dürfen (z.B. mehrteiliges Formular).
Oder wenn ein User eindeutig über mehrere Seiten hinweg wiedererkannt werden soll/muß, dieser sich aber nicht manuell einloggen soll...

Wo ich Sessions eher lästig finde, sind Informationen (z.B. erst vor kurzem erlebt, daß die FAQ einer Fluglinie nur mit gültiger Session erreicht werden konnte - man konnte also keinen direkten Link auf die Seite mit den benötigten Informationen verschicken)

cu,
Andreas

[Sven Rautenberg]

Moin!

Zurück zur Frage:
Wenn eine anständig eindeutige Seite immer den Query-String braucht, kann ich doch gleich immer alle Daten so übergeben. Wofür kann ich dann dann noch Sessions sinnvoll einsetzen?

Sessions brauchst du, um Benutzer eindeutig über verschiedene Requests hinweg identifizieren zu können.

Deshalb sind Sesssions absolut unnötig, wenn es darum geht, öffentlich und ohne Benutzer-Login eine Anzahl an HTML-Seiten zum Abruf bereitzustellen.

Und auch bei der Kombination von beidem (Useridentifikation bei diversen unterschiedlichen Seiten) ist der Teil "Ich hätte gerne Seite X, und dann Seite Y" streng zu trennen vom Authentifizierungsteil. Das ergibt sich ja einfach schon aus dem Benutzerwunsch, dass er direkt eine bestimmte Seite ansteuern will. Immer wenn so ein Wunsch geäußert wird bzw. möglich sein soll, muß die Seite durch eine eindeutige URL identifizierbar und abrufbar sein. Dabei bist du in der Wahl deiner Mittel grundsätzlich frei, es ist also kein Problem, entweder entsprechende Pfadinformationen, Dateinamen oder Parameter zu verwenden - das liegt ganz allein bei dir und daran, wie du intern die Informationen abgelegt hast.

Es ist also grundsätzlich möglich, dass es nur ein einziges Skript "/index.php" gibt, welches per Parameter zur Auslieferung aller möglichen Seiten angeregt wird (welche dann z.B. aus der Datenbank geholt werden) - wobei der Parameter beliebig sein kann, also meinetwegen auch eine codierte und nicht offensichtliche "Content-ID" abfragt - solange man mit dieser URL immer zur gewünschten Seite kommt.

Davon getrennt zu betrachten sind, wie erwähnt, gewisse zustandsabhängige Prüfungen oder auch Fortschritts-Systeme. Zustandsabhängig würde z.B. bedeuten: User eingeloggt/nicht eingeloggt. Ein schlaues System würde einem nicht eingeloggten Besucher bei Direktaufruf einer geschützten Seite statt des gewünschten Inhalts ein Login-Formular zeigen. Das Abschicken des korrekt ausgefüllten Formulars führt dann direkt zur gewünschten Seite. HTTP-Authentifizierung erlaubt sowas - ein Session-Mechanismus sollte sowas auch erlauben, es ist jedenfalls grundsätzlich kein Problem, sowas einzubauen.

Ein weiteres Beispiel für ein Fortschritts-System wäre z.B. ein Bestellvorgang. Der Kunde hat einen Warenkorb angesammelt und will den jetzt bestellen. Dazu gelangt er in mehreren Schritten zum Ziel. Zuerst: Einloggen oder neuen Account erstellen. Dann: Adressdaten eingeben und Zahlungsweise wählen. Dann: Warenkorb nochmal angucken, AGB bestätigen und bestellen. Und dann: Fertig. Wenn der Besucher irgendwann zwischendrin einen ganz anderen Link klickt (weil er noch was vergessen hat zu bestellen), und dann wieder zur Bestellung geht, soll er nicht unbedingt wieder ganz von vorn anfangen. Der erste Schritt ist beispielsweise überflüssig, weil der Benutzer schon eingeloggt ist bzw. der Account schon eingerichtet ist, sobald dieser Schritt erledigt wurde.

Andererseits kann man argumentieren, dass ein zurückkehren zu Schritt 3 (Warenkorb ansehen und bestellen), sofern man dort schon war, vielleicht nicht gewünscht ist. Auf jedenfall unerwünscht ist ein Zurückkehren zu Schritt 4, weil dann, wenn dieser Schritt erreicht wurde, die Bestellung bereits abgeschickt ist. Hier muß man lediglich verhindern, dass Mehrfachbestellungen durch Reload verhindert werden. Und mit Sessions kann man eben sehr einfach solche Zustandbeobachtungen realisieren und entsprechend reagieren.

- Sven Rautenberg