Mailinglisten-Archive |
Hallo Lutz, hallo Liste, > Die Browserkennung steht ja in der Umgebungsvariablen > HTTP_USER_AGENT, die ich schon mehrfach erwaehnte. Hierueber > kannst Du, sofern sie sich zu erkennen geben, Suchmaschinen > eindeutig identifizieren. Entsprechende Listen mit den > HTTP_USER_AGENT-Angaben der Suchmaschinen findest Du im Internet. Danke, das ist alles bekannt. ;-) > Wie gesagt, koenntest Du damit ja dann auch die Session fuer > Suchmaschinen unterdruecken (das war mein Loesungsvorschlag 2). Jein. Gerade hier ist es so, dass wir 1. erkennen möchten, wenn eine Suchmaschiene überhaupt die Seite betritt (siehe unten, betrifft aber nicht mein Problem :-)) und 2. dann auch noch wissen möchten, wie weit die Suchmaschine überhaupt in die Seite eingetaucht ist. Wir analysieren in diesem Falle nämlich nicht nur die Session selbst, sondern auch jeden Seitenaufruf. Die Unmengen an Daten werden regelmäßig gesichert und dann aus dem Workflow entfernt, so dass es hier nicht zu arg großen Belastungen kommen kann. > Ansonsten reicht die Browserkennung aus meiner Sicht auf > keinen Fall alleine zur Identifizierung aus. Meine ich auch. Von daher werden wir wahrscheinlich den unwahrscheinlichen Sonderfall einfach ignorieren und einfach akzeprieren, dass Benutzer, bei denen setcookie() == true was aber diese Werte dann doch nicht zur Verfügung stehen schlichtweg Geistersitzungen erzeugen. Wir werden beobachten, wie oft sowas vorkommt und dann zu einem späteren Zeitpunkt noch mal darauf reagieren. > Ausserdem: Aendert sich die IP-Adresse des Besuchers waehrend > der Session (Stichwort dynamische IP-Vergabe), dann kriegst > Du u.U. auch ein Problem, die Session ueberhaupt wiederzufinden. > Siehe AOL. *gmpf*. Ich sehe zwar ein, dass AOL seine Kunden mit diesem Mechanismus schützen möchte, aber für seriöse Serveranbieter ist das ein Graus! > Viele Gruesse > > Lutz > Schöne Grüße und danke für Deine Überlegungen... ;-) Tim
php::bar PHP Wiki - Listenarchive