nicht angemeldet
History-Tracking innerhalb einer Site
Servus,
ich habe ein etwas seltsames Anliegen...
In den internen Links eines Projekts speichere ich den Link-Ursprung (um in beim Request in eine Session einzugeben und so den Weg-durch-die-Site in der Session zu tracken) sowie die Session-ID (geht nicht per Cookie weil bei mehreren geöffneten Fenstern jeweils einzelne Histories gespeichert werden müssen).
Eine URL sieht also z.B. folgendermaßen aus: login.php?refer=index.php&refername=Home&session_id=9424f4d4b7d4e7f25d47b3a414d7fef8
Schlaue User kommen jetzt immer wieder auf die Idee einzelne Seiten irgendwo zu verlinken und geben dabei natürlich die Refer-Strings sowie die Session-ID mit an. Macht zwar aufgrund von IP-Bindung in einer Session nicht soooo gefährlich, aber sehr unschön.
Gegen refer und refername habe ich ein Mittel gefunden, nämlich indem ich die Daten nach dem Request in die Session schreibe und daraufhin einen Redirect auf die echte Seite mache. Funktioniert, aber produziert natürlich doppelt so viele Page-Hits und zieht jedesmal der Overhead der Session-Verarbeitung mit. Gegen die Session-ID in der URL ist aber kein Kraut gewachsen.
Irgendwie bin ich dabei in einer Sackgasse angelangt... würde ich die Daten in einem Cookie speichern würde ich Anzeige umgehen, würde aber bei mehreren geöffneten Fenstern die komplette History durcheinanderbringen.
Folgendes wäre mir noch eingefallen, ich habe aber keine Ahnung ob das umsetzbar ist und bin auch zu doof, etwas darüber im Netz zu finden:
1. Bezug der Daten im Cookie auf eine Art "Fenster-ID". In diesem Fall müsste man per Javascript oder PHP oder wieauchimmer herausfinden ob eine Seite in "Fenster 1" oder "Fenster 2" bzw. "Tab 1" oder "Tab 2" geöffnet ist. Ich bezweifle allerdings, dass das möglich ist.
2. Speichern der History per Javascript. Allerdings habe ich keine Ahnung, ob ich Javascript-Variablen über Requests hinweg benutzen kann ohne eben Session-Daten oder Cookies zu benutzen.
3. Die Seitenstruktur insoweit ändern, dass jedes Dokument nur einen bestimmten Referer haben kann. (seeeeeehr unschön)
4. Die History rauswerfen und den User dem Back-Button überlassen (noch viel unschönerer ;))
5. verzweifeln und alles so lassen wie es ist *g*
Für Hilfe, Ideen oder Anhaltspunkte wäre ich sehr dankbar :)
Danke an alle,
Neo / Tom
-
Hi,
In den internen Links eines Projekts speichere ich den Link-Ursprung (um in beim Request in eine Session einzugeben und so den Weg-durch-die-Site in der Session zu tracken)
warum? Ist es wichtig, das so genau zu wissen? Reicht nicht die Auswertung der Logfiles, ggfls. unter Berücksichtigung der Refferrer - sofern angegeben?
Und ist Dir bewußt, daß dies mehrfache Einträge in Suchmaschinen nach sich ziehen kann und damit doppelte Inhalte?freundliche Grüße
Ingo-
warum? Ist es wichtig, das so genau zu wissen? Reicht nicht die Auswertung der Logfiles, ggfls. unter Berücksichtigung der Refferrer - sofern angegeben?
Und ist Dir bewußt, daß dies mehrfache Einträge in Suchmaschinen nach sich ziehen kann und damit doppelte Inhalte?Das ganze ist nicht für Logfiles gedacht, sondern für eine Anzeige innerhalb der Pages.
Stell es dir so vor: Es gibt z.B. eine Galerie mit verschiedenen Kategorien und meinetwegen Konzertberichte. Eine Galerie-Kategorie mit Bildern eines Konzertes wäre sowohl über den Galerie-Index als auch den entsprechenden Artikel bei den Berichten zu erreichen. Jenachdem welchemn Weg der User geht wird als Header und Footer um den Content einer der beiden Pfade angezeigt:
1. Galerie >> Konzerte >> Foobar
2. Berichte >> Foobar >> Galerie zu Foobar
In diesem Einfachen Beispiel könnte man das noch fest eincodieren, es muss aber flexibler sein (z.B. von einem Benutzerprofil einer Community kommt man über einen Freundes-Link weiter zu einem zweiten und dort wieder weiter zu einem dritten, d.h. immer tiefer in die History.
Das ganze läuft schon so, aber eben mit den beschriebenen Nachteilen, dass eben Referer sowie eine sozusagen Fenster-eindeutige Session-ID über die URLs übergeben werden müssen.Das Problem der Suchmaschinen habe ich natürlich bedacht. Bei /(bot|spider|crawler)/i wird keine Referer-Info angegeben, eine über zwei Wege erreichbare Page wird also als ein und dieselbe gesehen.
Gruß,
Neo / Tom-
Hi,
Das Problem der Suchmaschinen habe ich natürlich bedacht. Bei /(bot|spider|crawler)/i wird keine Referer-Info angegeben, eine über zwei Wege erreichbare Page wird also als ein und dieselbe gesehen.
Du weißt, daß Du nicht alle Bots erkennen kannst und gerade Google gern mal inkognitto kommt?
freundliche Grüße
Ingo-
Hallo.
Du weißt, daß Du nicht alle Bots erkennen kannst und gerade Google gern mal inkognitto kommt?
Wie sieht also deine Alternative aus?
- Statische Seiten, die dann auch doppelt vorhanden sein müssten?
- Weglassen unterschiedlicher Navigationspfade und damit Einschränkung der Handhabung für den Menschen zu Gunsten einiger Suchmaschinen?
MfG, at
-
Hi,
Wie sieht also deine Alternative aus?
Cookies und Auswertung des Referrers.
Sofern dies nicht zum Ziel führt, genaue Überprüfung des UA-Strings und Abgleich der IP mit einer Liste der bekannten Suchmaschinen.freundliche Grüße
Ingo-
Hallo.
Cookies und Auswertung des Referrers.
Sofern dies nicht zum Ziel führt, genaue Überprüfung des UA-Strings und Abgleich der IP mit einer Liste der bekannten Suchmaschinen.Also nichts verlässliches? Schade.
MfG, at
-
-
-
-
-
Was ich noch nicht ganz so verstehe, und vielleicht mal schnell rauslesen will.
Du willst die Seiten-Historie wissen, vorallem, wenn du mehrere Fenster gleichzeitig benutzt (wow, du setzt einen erfahrenen User voraus) ?
Das mitschicken der Information in einem automatisch generierten Formular wäre keine Lösung ?
OK, klappt nicht bei Links...Wie wäre es denn, wenn JS für alle Links die Infos automatisch hinzufügt.
Die Idee ist, daß nach dem Onload eine JS-Routine die eigene refer auswertet und allen Links diese Info anhängt bzw einfügt ?Sowas ähnliches mache ich nämlich auch.