nicht angemeldet
Hallo Michael!
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.
:) na wenigstens kann ich klar formulieren, wenn ich schon nicht mehr klar denken kann ...
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.
Das ist eine gute Idee ... ich bin vielleicht eine Schlaue ... da ich den Timestamp mit md5() codiert habe bin ich auf die Idee bis dato gar nicht gekommen.
und er wird neu registriert
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.
Da hast du Recht.
- 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?
Login gibt es hier noch nicht - der Kunde shoppt wie er will (ausser er hat schon mal bestellt und akzeptiert das seine Daten in einem Cookie gespeichert werden, dann kenne ich ihn von Anfang an). Ansonsten kenne ich den Kunden erst nachdem er beschließt, dass was er in den Warenkorb gelegt hat zu bestellen. Dann wird er neu registriert oder eben Login. Mein Problem ist also wirklich das Rumspazieren im Shop und das in den Warenkorb legen. Mehrfach-Login in diesem Sinne also - kein Ausspionieren/Beeinflussen des Warenkorbs von anderer Seite
... 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.
Na ja, das mit der IP-Adresse ist ja so eine Sache, ist ja nicht wirklich verlässlich. Noch ne blöde Frage von mir - codieren, decodieren - mit welchem "System" am Besten? md5() kann man ja nicht mehr decodieren (wenn ich nicht irre) - einen eigenen Algorithmus entwerfen oder gibt es hierzu Funktionen?
Das Hineinspringen in eine fremde Transaktion sollte schwieriger sein
als das Erraten Deines Session-ID-Algorithmus.
Ach ja - da sind wir ja schon - eigenen also. Hineinspringen wird schwieriger je mehr Infos ich vom User hineinpacken und kontrollieren kann - sehe ich das richtig nach deinen Ausführungen?
- Irgendwie das beeinflussen was in der history-Liste steht - aber
wie? (z.B. das eben diese eine Variable automatisch erneuert wird).
» 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.
Ja, hier habe ich mich auch etwas blöd ausgedrückt - ich will ihn auch nicht daran hindern zurück zu gehen. Ich dachte nur dass es eine Möglichkeit gibt, dass eben nicht meine Variable nicht fix in die History übernommen wird - ist aber nonsens. 2 fällt also aus.
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.
Mhh.... und was, wenn er dann wieder auf den Button Vorwärts klickt?
- 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 ...
Ja und das will ich vermeiden (no na ... - da schlägt der Österreicher durch :)).
Die Idee mit dem (nicht md5())-kodierten Timestamp hat mich ein ordentliches Stück weitergebracht, danke.
Nun drängt sich bei mir aber eine neue Frage auf und ich würde mich sehr über deine Meinung dazu freuen:
Ist es besser
a) Den User über SID + Timestamp durchzuführen (mit Abfrage <= bei Timestamp), in ID noch userspezifische Daten hinzuzufügen und das verbleibende Restrisiko zu schlucken (IP ist ja nicht sicher, kann also nur Daten einbinden, die auch ein anderer haben könnte)
b) Die einzelnen "abgelaufenen" Timestamps zusätzlich in der Datenbank zu speichern und so zusätzlich Abfragen/Erhöhung der Datenbankeinträge zu akzeptieren (Ladezeit, Performance?)
Danke für deine ausführliche Antwort und deine Ideen!!
lg
Sabine
Viele Grüße
Michael