nicht angemeldet
Hallo Michael!
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?
Ja, auch - aber vor allem auch dann, wenn der Benutzer diese Informationen nicht so ohne weiteres fälschen kann (deshalb die HTTP-Header).
Ist nachvollziehbar für mich. Welche Informationen des Users machen den Sinn um ihn zu unterscheiden? Wie gesagt bei der IP kann es ja sein, dass ich den Benutzer dann nicht mehr erkennen würde obwohl es der richtige ist. Ist es sinnvoll z.B. eine Kombination aus HTTP_USER_AGENT und HTTP_ACCEPT zu nehmen? Da ja (nach meinem bisherigen Wissenstand) eben die IP unsicher ist und auch der Referrer gefaked sein kann, drängt sich für mich die Frage auf - welche Informationen soll ich nehmen, die überhaupt Sinn machen um nicht etwas zu prüfen, dass mir eigentlich nichts bringt, weil 2 von 3 die gleichen Infos schicken.
Wenn dieses Programm dann auch noch mit Deinen womöglich JavaScript enthaltenden Seiten fertig werden muß, hast Du eine nette zusätzliche Hürde aufgebaut, die nicht mit brute force, sondern nur mit eigener Arbeit zu überwinden ist.
Warum JavaScript? In welcher Form kann mir hier Javascript etwas bringen? Das verstehe ich nicht - als einziges sehe ich hier eine Möglichkeit daran Besucher mit aktiviertem und deaktiviertem Javascript zu unterscheiden? Meinst du das oder bin ich hier am falschen Dampfer?
Solange er noch nichts tut, was von dem bereits gespeicherten "Transaktions-Film" explizit abweicht, kannst Du seinen Timestamp als eine Art "Cursor" innerhalb dieses Films verwenden.
"Vor" und "Zurück" innerhalb der History verwenden jeweils nur Timestamps, die Du schon kennst.
(Das wäre aber mehr, als der Browser selbst sinnvoll unterstützen würde - der kennt nur einen einzigen "Vorwärts"-Weg.)
Ach ja - ist klar, sobald er zurück geht und auf einen Link klickt ist die Möglichkeit wieder Vorwärts zu gehen ja weg. Dann kann ich also sobald er auf einen Link klickt den "Ast" absägen ...
Ich weiß (noch) nicht, ob sich das so programmieren lässt wie ich es mir denke, aber momentan habe ich folgendes im Kopf:
Sicherer kommt mir nach wie vor die Version vor, alle Schritte mitzuprotokollieren, denn dann ist der Zugriff des Besuchers nur Ok wenn er 5 Links mit 5 Timestamps geklickt hat, wenn er auf einen dieser zurückspringt und nicht nur wenn der Timestamp kleiner als der jetzige ist.
Nun könnte ich ja in der Datenbank die Timestamps eintragen, wenn er nun auf zurück geht, habe ich den Eintrag bereits da - ich weiß also dass er in der History zurückmaschiert ist, geht er auf vorwärts springt er zu seinem nächsten Datensatz in der DB. Klickt er aber auf einen Link, kommt ein neuer, noch nicht vorhandener Timestamp in der Datenbank und ich kann alle Einträge die größer sind als der Eintrag vor dem Klick auf den Link löschen. Sehe ich das richtig? Und noch eine abschließende Frage - sehr oft habe ich auf meine Idee mit den ändernden Timestamps die Meinung gehört, dass dies nicht sinnvoll wäre, aufgrund der vielen Einträge - Erhöhung der Ladezeiten, Datenbank-Overflow. Datenbank-Overflow mache ich mir weniger sorgen, da auch ich vorhabe, Einträge nach bestimmter Zeit zu löschen (z.b. wenn letzter Timestamp der SessionID länger als 1 Stunde von now, dann delete). Wie sieht es aber mit Ladezeiten aus? Kosten mich die Abfragen ob der Timestamp bereits vorhanden ist (evt. auch in einer Cache-Tabelle) und der Eintrag von neuen Timestamps viel Zeit oder ist dies vertretbar?
Danke für deine Antworten, Michael und ich würde mich freuen, wenn du dir noch einmal die Zeit nehmen würdest, meine verbleibenden Fragen zu beantworten.
Vielen lieben Dank und schöne Grüße
Sabine
Viele Grüße
Michael