nicht angemeldet
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
"Habe den Mut, dich deines eigenen Verstandes zu bedienen!" (Immanuel Kant)