Jump to content
xt:Commerce Community Forum

https Domain != http Domain


jue

Recommended Posts

Hallo, wieder mal eine Frage zur SSL Proxy Problematik:

Ich habe schon alle Vorschläge, die ich hier im Forum gefunden habe, ausprobiert und trotzdem funktioniert der Shop nicht richtig.

Angenommen:

Der Kunde legt einen Artikel in den Warenkorb (NONSSL)

und geht dann zur Kasse (SSL).

Dann wird der Warenkorb als leer angezeigt, weil die https-domain

ein neues Cookie mit einer neuen Sessionid (=xtcsid ) gesetzt hat.

Das cookie der http-domain mit der ersten session-id kann nicht gelesen werden.

(Mit Sessionweitergabe in der URL funktioniert es, ich möchte aber Cookies verwenden.)

Wie kann ich die sessionid des http-cookies in die des https-cookies übernehmen, damit der Kunde immer identifizierbar bleibt?

NONSSL z.B. http://www.domain.de

SSL z.B. https://sslserver.de/www.domain.de

Es muss doch eine gute Lösung für ssl-Proxies geben..........

Link to comment
Share on other sites

Wie kann man ein für beide (http und https- Domain) gültiges cookie setzen?

Ich tippe mal auf gar nicht. Die Session (und damit die ID) ist immer an den Server gebunden, der sie anlegt. Ich gehe mal davon aus, dass Du an den SSL-Proxy nicht rankommst und demzufolge auch nicht an dessen Cookie-Handling. Recht ungewöhnlich ist aber, dass Dein SSL-Proxy eine eigene Session startet...

Ebenso ungewöhnlich ist es aber, dass - wie Du gesagt hst - bei anderen das Ganze wohl toll funktioniert. Eventuell haben die die ID ja alle an die URL gehängt...

Du kannst versuchen, im Admin im Punkt Sessions "Checken der SSL Session ID" und/oder "Session erneuern" auf FALSE zu setzen, was aber wiederum den Shop an sich unsicherer macht und u.U. (je nach Provider) dazu führt, dass man sich nicht mehr einloggen kann oder gleich eine leere Seite bekommt...

Die einfachste und für den Kunden transparenteste Lösung wäre wohl, dass Du Dir ein eigenes Zertifikat für Deinen Server anschaffst (bei einigen Hostern bei Paketen der 10-20 Euro/Monat-Klasse im Preis mit drin) und damit den Proxy überflüssig machst.

Cheers,

IaN

Link to comment
Share on other sites

Hallo John,

unten habe ich mal die Möglichkeiten der php.ini in Bezug auf Cookies angehängt. Meintest du das mit Cookiehandling?

Die Angaben beziehen sich dann aber nur auf die Http Domain, oder wird das dann auch für die https-proxy-Domain übernommen?

Kann das am Speicherort der Seesionid liegen, dass der https proxy nicht rankommt und eine eigene Session startet?

Fragen über Fragen..........

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

session.save_handler

Der Name der Prozedur, die benutzt wird, um die Daten zu speichern und zurückzuholen, die mit der Session in Verbindung stehen

session.save_path

Definiert das Argument, das an die Speicherprozedur übergeben wird. Wenn Sie die standardmäßige files Prozedur wählen, ist das der Pfad, unter dem die Dateien erzeugt werden. Für diese Anweisung gibt es ein optionales Argument N, das die Anzahl der Verzeichnisebenen bestimmt, über die Ihre Session-Dateien verteilt werden. Wird sie zum Beispiel auf '5;/tmp' gesetzt, kann das das Anlegen einer Session-Datei und Speicherstelle wie /tmp/4/b/1/e/3/sess_4b1e384ad74619bd212e236e52a5a174If bewirken. Um N verwenden zu können, müssen Sie alle diese Verzeichnisse vorher anlegen. Beachten Sie, dass die automatische 'Müllentsorgung' (garbage collection) nicht durchgeführt wird, wenn N verwendet wird und größer 0 ist.

session.use_cookies

Durch die Aktivierung dieser Checkbox geben Sie an, dass ein Modul Cookies verwenden soll, um die Session-ID clientseitig zu speichern

session.name

Spezifiziert den Namen der Session, der als Cookie-Name verwendet wird

session.auto_start

Setzt, ob das Session-Modul zu Beginn einer Anfrage automatisch eine Session startet

session.cookie_lifetime

Geben Sie hier bitte die Lebensdauer von Cookies in Sekunden an, welche an den Browser geschickt werden soll. Die Angabe des Wertes "0" bedeutet hierbei "Bis der Browser geschlossen wird"

session.cookie_path

Geben Sie hier den Pfad zu dem Verzeichnis an, in welchem die Session-Cookies gesetzt werden sollen

session.cookie_domain

Hier können Sie definieren, unter welcher Domain das Session-Cookie gesetzt werden soll. Bitte beachten Sie, dass an dieser Stelle keine Subdomains angegeben werden dürfen, des weiteren muss die Eingabe ohne die Angabe "http://" erfolgen

session.gc_maxlifetime

Definiert die Anzahl der Sekunden, nach denen Daten als "Müll" ("garbage") betrachtet und entsorgt werden sollen

Link to comment
Share on other sites

Wie kann ich die sessionid des http-cookies in die des https-cookies übernehmen, damit der Kunde immer identifizierbar bleibt?

Die Angaben beziehen sich dann aber nur auf die Http Domain, oder wird das dann auch für die https-proxy-Domain übernommen?

Also nochmal: Ein Cookie ist immer an den Server gebunden, der ihn ausstellt. Nur der ausstellende Server kann seine eigenen Cookies lesen. Wenn Dein SSL-Proxy (https-Server) also einen eigenen Session-Cookie setzt, kommst Du da mit Deinem http-Server nicht ran.

Darf man fragen bei welchem Hoster Du bist?

Link to comment
Share on other sites

Die sessionid Übergabe funktioniert beim Anhängen an die URL einwandfrei.

Die HTTPS Seite liest die Sessionid aus und kann sie verwenden.

Warum kann dann die ausgelesene sessionid nicht ins HTTPS-Cookie

geschrieben werden?

Wo findet das Erzeugen und Auslesen der sessionid in XTComm. statt?

??

Link to comment
Share on other sites

Die sessionid Übergabe funktioniert beim Anhängen an die URL einwandfrei.

Die HTTPS Seite liest die Sessionid aus und kann sie verwenden.

Wenn die ID an der URL hängt, wird sie ja auch nicht in irgendwelchen Cookies gespeichert - dafür ist die Funktion ja da, dass das ganze dann auch ohne Cookies funktioniert... ;)

Warum kann dann die ausgelesene sessionid nicht ins HTTPS-Cookie

geschrieben werden?

Wenn Du nicht an den https-Proxy rankommst, weil der z.B. deinem Hoster gehört, kannst Du auch nichts an dessen Cookies drehen.

Speicherst Du die Sessions an sich in der Datenbank? (siehe configure.php)

Wo findet das Erzeugen und Auslesen der sessionid in XTComm. statt?

Habe gerade kein xt:C hier zur Hand, aber im Ordner inc/ oder includes/ oder includes/classes müsste irgendwo eine Datei sessions.php oder xtc_session.inc.php oder so ähnlich vorhanden sein.

Link to comment
Share on other sites

Wenn Du nicht an den https-Proxy rankommst, weil der z.B. deinem Hoster gehört, kannst Du auch nichts an dessen Cookies drehen.

Aber ich müßte doch die schon erzeugte und bekannte Sessionid an das

neue Cookie des Proxy übergeben können, die includes/classes/sessions.php

gibt doch auch dafür Daten weiter, oder?

( Allerdings kann ich nur Variablen für Domainname Cookiename Gültigkeit etc finden, keine für eine ID......)

PS

Ich habe beides probiert: Session in einem Ordner und auch in der Datenbank. Eigentlich kein Unterschied.

Link to comment
Share on other sites

So, da bin ich wieder! Sorry, war unterwegs ;)

Die Sessionid (XTCsid) müsste doch leicht beim Übergang auf https weitergegeben werden können.........

Nochmal: An den Proxy Deines Providers und an dessen Session-ID kommst Du nicht ran!

Wenn Du von deinserver.de zu irgendeinsslserver.de/deinserver wechselst, *muss* IMHO die Session-ID per GET übertragen werden, damit der Shop sie dann weiterverwenden kann. Das hat mit den Cookies des Proxys eigentlich gar nix zu tun, das regelt der Shop selbst - eigentlich...

Hier mal was aus dem Supportforum von osC:

For example, the force cookie usage implementation will work for the following servers:

http://www.domain-one.com

https://www.domain-one.com, or https://ssl.domain-one.com

but not for the following servers:

http://www.domain-one.com

https://ssl.hosting_provider.com/domain-one/

The ssl.hosting_provider.com example is using a shared SSL certificate used for secure transactions. This can easily be fixed to work with the force cookie usage implementation by purchasing and installing a dedicated SSL certificate for the domain-one.com domain.

It is possible to bypass the cookie check by appending the session ID to the url when the client moves from HTTP to HTTPS state, or from HTTPS to HTTP state; however the main goal this implementation is trying to achieve is to not place the session ID on the url at all which would occur if the clients browser had cookies disabled.

A simple case of this implementation failing where different HTTP and HTTPS domains are used is when the client first visits the online store (cookie is set for HTTP domain) and clicks on the secure Login link (cookie is set for the HTTPS domain).

As cookies cannot be read on the same request made when they are set for the first time, the Login page cannot access the HTTPS domain cookie as it has just been set, and it can also not read the HTTP domain cookie as it is another domain.

Den ganzen Thread findest Du, wenn Du bei Gurgel folgendes suchst:

"SSL und Force Cookie Problem, SID-Übergabe beim Log-IN"

Cheers,

IaN

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
  • Create New...