Ssl-proxy Und Session-cookies

[msslovi0]

Gestern war der Googlebot zu Besuch und hat ein komisches Verhalten an den Tag gelegt: Obwohl SEF-URLs ebenso wie das Verhundertn von Sessions für bekannte Spider aktiv sind hat er die URLs normal gecrawlt (wo auch immer er die Links dafür her hatte) und ist lustig mit einer natürlich laufend wechselnden Session-ID durch die Seiten gepflügt, wovon ihn auch ein Disallow: / ?XTCsid in der robots.txt nicht abgehalten hat (ich hab das jetzt mal noch um ein Disallow: / &XTCsid ergänzt, weil die Session-ID nicht der erste Paramter war, glaube aber nicht so ganz an den Erfolg des ganzen, zumal ja, wenn überhaupt Session-IDs angehangen werden, auch diese SEF sein sollten).

Ich hab ein bisschen gewühlt, aber zu der Sache mit den SEF-URLs nichts gefunden. Für die Session-IDs wird von offizieller Stelle empfohlen, SESSION_FORCE_COOKIE_USE auf True zu setzen, was ich auch gemacht habe. Spontanes rumklicken, ob das auch funktioniert wie gedacht, hat keine Auffälligkeiten gezeigt.

Heute morgen hatte ich dann eine Mail von einer Kundin im Postfach, die zurecht moniert hat, dass sie, sobald sie auschecken will, keine Artikel mehr im Warenkorb hat, obwohl die vorher drin waren. Ich konnte das auch reproduzieren und wollte die Änderung mit den Cookies zunächst mal rückgängig machen, um zu sehen, ob das der Grund ist, bin auch in den Admin-Bereich gekommen, bei jedem weiteren Klick aber sofort wieder rausgeflogen. Ich hab dann den Wert über MySQL direkt wieder auf False gesetzt und seitdem funktioniert wieder alles.

Hat schonmal jemand anderes mit der Cookie-Benutzung und SSL-Proxies ähnliches beobachtet?

Ich 'helfe' mir jetzt so, dass ich in xtc_href_link.inc.php bereits bei der ersten if-Bedingung auch noch darauf prüfe, ob truncate_session_id gesetzt ist oder nicht, wodurch dann erst $sid garnicht gesetzt wird, anstatt das nachträglich wieder auf NULL zu setzen. Mal schauen, ob es was bringt...

Matt

[msslovi0]

Danke. Ich schau mir das mal an. Allerdings haben wir keine Herstellerlinks und auch keine gleichzeitig angezeigten Produkte. Es würde aber auch erklären, warum Google eine Session-ID bekommt. Denn wenn die Links nicht SEF sind werden sie folglich nicht durch xtc_href_link() generiert und dadurch findet dann auch kein Spidercheck statt.

[msslovi0]

Stimmt, die waren in der Tat noch falsch (und die Hersteller haben sogar immer die Session-ID bekommen, weil ich das so aus dem Manufacturer-Dropdown kopiert habe). Damit dürfte das Geheimnis gelüftet sein. Hätte mir eigentlich gestern schon auffallen müssen, das neben der SID auch immer eine filter_id übergeben wurde...
Danke fürs Augenöffnen.

Bleibt noch die Frage Cookies vs. SSL-Proxy.

[MrEdge]

Zum SSL-Proxy könnte ich mir vorstellen dass dein Provider die Set-Cookie handler im HTTP Request nicht umschreibt, bei Apache siehe dazu http://httpd.apache.org/docs/2.2/mod/mod_proxy.html (http://anonym.to/?http://httpd.apache.org/docs/2.2/mod/mod_proxy.html) vor allem die Direktiven ProxyPassReverseCookieDomain und ProxyPassReverseCookiePath

Eventuell kannst du diesbezüglich mal bei deinem Provider nachfragen, ob das Cookie-rewriting generell aktiviert ist bzw es möglich ist das für dich zu aktivieren.

[swgreed]

''>ZITAT</div>Bleibt noch die Frage Cookies vs. SSL-Proxy.[/b]

Gibts hierzu schon was neues? Habe das gleiche Phänomen wie Matt...