hi,
Wo die Session-ID ueberall angehaengt wird, ist von der Konfiguration abhaengig (vor allem vom Wert der Direktive url_rewriter.tags).
Das hatte ich schon geprüft, bei mir (1und1) wird die SID nur an Interne Links weiter gereicht, also keine Links, die mit http:// beginnen.
Angehaengt wird sie bei aktiviertem use_trans_sid natuerlich automatisch beim ersten Start der Session - da kann PHP schliesslich noch nicht wissen, ob der Client Cookies akzeptieren wird.
Das hatte ich nicht gewusst ; beim Versuch die Seite über validator.w3.org zu validieren ist mir das aufgefallen, da wurde immer ein <input type="hidden">
Feld bemängelt, dass die SID automatisch generiert hatte.
Wenn du bspw. ein Bild von meiner Seite auf deiner eingebunden hast, dann ist die Wahrscheinlichkeit gross, dass die aktuell vom Nutzer aufgerufene Adresse deiner Seite, http://example.com/blubb.php?session_id=123456...789, als Referrer an meinen Server uebertragen wird. Wenn ich das jetzt zeitnah auswerten wuerde, koennte ich damit die Session deines Nutzers "stehlen".
Danke für diesen Hinweis, diesen Punkt hatte ich nie so recht verstanden.
Also kein wirklich wichtiges Feature - wenn es mangels Cookie-Akzeptanz nicht funktionieren wuerde, waere das auch kein unbedingter Beinbruch.
Das habe ich jetzt auch wieder deaktiviert, einen großen nutzen hat der Styleswitch ja nicht wirklich.
Na ja, wenn ein SuMa-Bot vorbeikommt, und sich dabei die Links mit Session-ID anschaut und indiziert, ist das natuerlich auch bloed.
Das hatte ich Gestern in meinen Logs gesehen und die use_trans_sid wieder abgeschaltet, ich hab mir so viel Mühe gegeben, meine URI sauber zu halten, dass sollen sie auch bleiben.
Deshalb versuchen manche Leute, Bot-Requests zu identifizieren, und bei solchen dann gar keine Session zu starten.
Das wäre eine Option, so wie es aussieht, kann ich ja session.use_trans_sid auch zur Laufzeit des Scriptes starten.
Danke für die Hilfe.
holla holla