nicht angemeldet
Hi Sabine,
In der Datenbank habe ich also für jeden Besucher die SessionID
und den Timestamp gespeichert, bewegt sich der User über die Links
weiter wird der Timestamp in der Datenbank aktualisiert (alter
Eintrag ist also weg).
so weit komme ich noch mit.
Die Variable Timestamp wird über den Url übergeben, wenn der User nun
aber auch back drückt oder aktualisieren hat er einen Timestamp den
es eigentlich nicht mehr gibt
... und was Du auch erkennen kannst, wenn Dein timestamp eine Kleiner-Gleich-Relation erfüllt.
und er wird neu registriert
Warum?
Du weißt, daß der Benutzer bereits angemeldet ist - durch den Inhalt
Deiner Datenbank.
Du weißt auch, daß der Benutzer einen kleineren time stamp gesendet hat
als in einem vorherigen Request, daß er also irgendwie zurück gegangen
ist.
Nun mach das Beste daraus, was die Logik Deiner Dialogführung hergibt.
Und das ist bestimmt nicht, diesen Benutzer neu anzumelden. Sowohl eine
Fehlermeldung aus auch ein vollständiges Transaktionsprotokoll (siehe
unten) dürften besser sein.
- was ich nicht möchte, da er ja erkannt bleiben soll.
Denke ich auch. Denn das Speichern der Session dürfte in meinen Augen
vor allem dazu dienen, ein Mehrfach-Login zu verhindern ... richtig?
- Nicht UPDATE sonder INSERT: Alle Daten des Users speichern
Das wäre ein Weg, das Problem zu lösen - darauf werde ich noch eingehen.
- die Abfrage würde damit nicht mehr ins Leere gehen
_Das_ sollte sie auf keinen Fall.
allerdings können hier recht schnell viele Einträge zusammenkommen
... die Du alle in Deiner Datenbank speichern mußt ...
und die Wahrscheinlichkeit, dass ein anderer auf die Userdaten kommt
wird etwas größer.
Das sollte natürlich überhaupt nicht so ohne weiteres möglich sein.
Du kannst ja in die Session-ID auch Informationen mit hinein codieren,
die aus dem Verbindungsaufbau selbst stammen - sagen wir mal: Die IP-
Adresse des Client und/oder bestimmte HTTP-Header seines Browsers) -
und dies ebenfalls beim Decodieren der ID prüfen.
Das Hineinspringen in eine fremde Transaktion sollte schwieriger sein
als das Erraten Deines Session-ID-Algorithmus.
- Irgendwie das beeinflussen was in der history-Liste steht - aber
wie? (z.B. das eben diese eine Variable automatisch erneuert wird).
Ungern. Der Benutzer wird irgendwas tun, was er glaubt, tun zu wollen.
Alles, was Du sinnvollerweise tun darfst, ist, zu erkennen, was er will
und darauf so gut wie möglich reagieren.
Wenn ein Benutzer "zurück" will, dann will er zurück - die Frage ist,
wie gut Du die Session an derjenigen Stelle, wo er nun in eine andere
Richtung abbiegen will, sinnvollerweise weiter machen kannst.
Vielleicht brauchst Du wirklich in der Datenbank ein vollständiges
Protokoll aller HTTP-Requests des Benutzers, welche Du über die
Session-ID exakt erkennen kannst - dann kannst Du beim Eintreffen
eines Requests mit einer "alten" Session-ID alle Datenbankeinträge
mit "neueren" Session-IDs verwerfen und an der entsprechenden Stelle
weiter machen.
(Eine Datenbank würde in ihrem rollback-Segment etwa dasselbe tun,
um transaktionsfähig zu sein - sie muß allerdings nicht an beliebigen
Stellen aufsetzen, sondern nur den gesamten "Film" zurück spielen
können, falls die Transaktion abgebrochen wird.)
- Bei Zurück eine automatische Meldung generieren (also wenn
Timestamp nicht stimmt, die den Benutzer darauf hinweist, dass die
Seite so nicht erreicht werden kann (meines Erachtens Gefahr der
Verärgerung der Besucher)
Immer noch besser, als wenn der Benutzer andere Daten in seiner Shop-
Transaktion verarbeitet, als er selber glaubt.
Wenn der Kunde dann wegen eines fehlerhaften Shop-Systems einen Artikel
kauft, den er eigentlich durch "zurück" doch nicht haben wollte, wirst
Du nicht glücklich sein - denn dann ist der mal Kunde gewesen ...
Viele Grüße
Michael