Hallo Gambio-Profis, wir versuchen derzeit einen shop zu installieren. Hoster ist All-Inkl, ein eigenes SSL-Zertifikat ist nicht vorhanden, also wird der SSL-Proxy benutzt. Es wurde bisher nur die Gambio-Installationsroutine ausgeführt - weder CSS noch andere Anpassungen sind bisher erfolgt. Die Adresse soll lauten: www.mediaruler.de Das Problem: Mit aktiviertem SSL ist es nicht möglich, sich einzuloggen oder eine Kundenregistrierung durchzuführen, falls die subdomain 'www' verwendung findet. Es gibt zwei shops. Einmal unter der subdomain 'testshop' - hier funktioniert alles ohne Probleme. Dann unter der subdomain 'www' (hier soll der eigentliche shop hin) - hier gibt es die oben beschriebenen Probleme. Nach Aussage des All-Inkl-Support-Teams soll der Fehler nicht am SSL-Proxy liegen. Auch während der Installation wird mir der shop unter https://ssl-account.com/www.mediaruler.de als erreichbar angezeigt. Dennoch ist es mit aktiviertem SSL nicht möglich, sich einzuloggen (Folgende Fehlermeldung: >>FEHLER: Keine Übereinstimmung der eingegebenen "E-Mail-Adresse" und/oder dem "Passwort".<< ). Der Versuch, einen neuen Kunden anzulegen wird ohne Fehlermeldung mit dem Neuladen des leeren Formulars quittiert. Wenn ich den Testshop mit https aufrufe, 'bleibt' er auch auf https. Wenn ich den 'www'-Shop mit https aufrufe, 'springt' er auf normales http. Ein Abändern der 'includes/application_top.php' nach folgender Anleitung (http://all-inkl.com/wichtig/anleitungen/skripte/shops/xt-commerce-version-3.0.4/ssl-schutz-aktivieren_67.html) hat keine Abhilfe gebracht. Der shop wurde mehrfach neu installiert, die Datenbank jeweils neu angelegt, SSL ist im KAS (All-Inkl-Backend) aktiviert. Wenn SSL in den beiden configure.php-Dateien deaktiviert wird klappt alles, also schließe ich einen grundsätzlichen Fehler bei der Installation aus. Es muss irgendwie an der Kombination von SSL-Proxy und 'www'-Subdomain liegen. Weiß hier jemand Rat? Vielen Dank im Voraus. MfG
Hallo Heiko, willkommen im Forum. Da müssen mehr Dateien angepasst werden, schau mal hier: (Link nur für registrierte Nutzer sichtbar.)
Danke. Leider hat mir das (noch) nicht geholfen. Was ich versucht habe: 1.: Die Änderung aus der 'application_top.php' übertragen in die 'application_callback.php' und die 'application_export.php' (Schritt 3 der Anleitung von HolgerNils aus diesem posting http://www.gambio-forum.de/threads/12046-Proxy-SSL-bei-All-Inkl?p=93329&viewfull=1#post93329). Cache geleert - nix! --Bei einer ähnlichen Anleitung direkt von All-Inkl wurde übrigens nur die 'application_top.php' erwähnt, die anderen beiden Dateien hingegen nicht. 2.: Die 'configure.php'-Dateien so abgeändert, dass KEINE subdomain bei den HTTPS-define-Zeilen vorkommt (Schritt 2&3 der Anleitung von HolgerNils aus dem vorher genannten posting). cache geleert - nix! --Ich verstehe auch nicht ganz, wie es helfen soll, eine falsche(?) domain aufzurufen...beim testshop rufe ich an dieser Stelle ja auch gezielt die subdomain auf und alles funktioniert. Allerdings war ein Versuch OHNE subdomain beim testshop ebenso erfolgreich. Falls mir jemand das erklären kann oder einen guten Link zu diesem Thema hat, wäre ich dankbar. 3.: In folgendem posting werden Einträge erwähnt, die in der '.htaccess' "dazwischen gefunkt" haben: http://www.gambio-forum.de/threads/12046-Proxy-SSL-bei-All-Inkl?p=93351&viewfull=1#post93351. Ob diese Einträge zu viel waren oder gefehlt haben, erschließt sich mir aus dem posting nicht, also habe ich sie einfach mal hinzugefügt (nbs-shop durch mediaruler ersetzt). Cache geleert - nix! Eine Lösung des Problemes hat natürlich Vorrang, ich möchte aber auch wirklich gerne verstehen, wieso es überhaupt dazu kommt.
Könnte einer der Mods den Betreff des Threads korrigieren? Ich finde „SS-Proxy“ irgendwie … verstörend.
Oha! Ja, vielen Dank für die Korrektur. zum Thema: Im von Barbara genannten Thread empfiehlt HolgerNils(xycons.de) noch folgendem Link zu folgen: http://SHOP/login_admin.php?repair=sess_write (SHOP durch eigene Adresse ersetzen) Wenn ich das versuche kommt folgende Fehlermeldung: Report: repair-Befehl ungültig
Die Speicherung des Session-Pfades in der Datenbank gibt es seit v2.1.1.0 nicht mehr, das ist jetzt fest auf DIR_FS_CATALOG.'cache/' eingestellt. Deswegen ist dieser repair-Befehl auch nicht mehr nötig und weggefallen.
Es klappt jetzt wieder. Manchmal kann die Lösung so einfach sein. Drei Wochen habe ich daran verschwendet. Selbst ein Dipl.-Ing und erfahrener Webanwendungsprogrammierer, der sich die Sache mal für eine Stunde als Freundschaftsdienst angesehen hat, gab verzweifelt auf und sagte: "Das MUSS ein obskurer Übergabefehler zwischen der Gambio-Shopsoftware und dem SSL-Proxy sein. Die Daten werden dem Proxy noch sauber übergeben, aber vom Proxy kommt nur noch die Anfrage zurück - ohne die Daten. Ohne direkten Zugriff auf den SSL-Proxy kann ich Dir da auch nicht helfen." Tja, auf die dümmsten Fehler kommt man meist nicht. Damit Andere, denen es genauso ergeht, nicht ebenfalls Wochen auf die Lösung verschwenden müssen: Da der Shop unter der www-subdomain erreichbar sein sollte, aber nicht unter der Adresse ohne www-Präfix, hatte ich bei All-Inkl direkt im KAS eine Umleitung 301 auf die subdomain eingerichtet. Das war der Fehler. Die Hauptdomain darf weder auf serverroot verweisen, noch als 301-Umleitung konfiguriert werden. Stattdessen muss sie auf das Unterverzeichnis der gewünschten subdomain verweisen. Im entsprechenden Verzeichnis dann in die .htaccess eine entsprechende Rewrite-Rule einfügen. Ob das nun an Gambio oder am All-Inkl-SSL-Proxy liegt, vermag ich nicht zu sagen, aber es scheint wohl so, dass mein Bekannter nicht ganz Unrecht hatte. Aus welchem Grunde auch immer, jede subdomain AUßER www wird sauber verarbeitet. Wenn jedoch die subdomain www benutzt wird, schickt der SSL-Proxy seine Daten NICHT an www.DOMAIN.TDL, sondern an DOMAIN.TDL. Wenn dort nichts zu finden ist, oder eine Umleitung existiert, gelingt die Übergabe der Daten nicht. Womöglich ist dies auch das normale und gewünschte Verhalten, immerhin wurde vorher schon empfohlen, bei den DEFINE_HTTPS-Zeilen in den configure.php-Dateien das www weg zu lassen. Wenn dies so ist, wäre ich nach wie vor für einen weiterführenden Link dankbar. Sofern der support daran interessiert sein sollte, kann ich entsprechende HARs von gelungenen und misslungenen Logins (Testuser) posten. MfG
Pustekuchen Login hat jetzt mehrfach funktioniert, sowohl mit adminaccount, als mit testaccount. Jetzt geht es wieder nicht. Gleicher Fehlertext, wie zuvor. Ohne RewriteRule geht es (POST status 302), allerdings ist der shop auch ohne subdomain aufrufbar. Mit rewriteRule werden die Login-Daten nicht übergeben (POST status 301). Allerdings hat das die ersten Versuche wunderbar geklappt und plötzlich, ohne Änderungen meinerseits, nicht mehr.
Hier: (Link nur für registrierte Nutzer sichtbar.) hol dir kostenloses oder günstiges ECHTES SSL Zerti und lass dir das einrichten. Sieht eh tausendmal besser aus als über ne andere Domain SSL zu haben - Bei den Medienberichten heutzutage sind die ängstlichen dann eh gleich verwirrt und weg von der Seite da es für die so aussieht als ob jemand deine Seite geklaut hätte und nun ihre Daten klaut. Dieses Prxy SSL Zeug is schlimmer wie kein SSL für die Kunden die eh schon angst haben.