SSL mit CE 4.9.6

Mein Shop läuft mit PayPal Plugin und SSL Zertifikat schon seit eniger Zeit. Bestellungen kommen rein. Soweit so gut.

Jetzt ist mir aufgefallen, dass die Shopseite unformatiert aussieht, sobald man sich anmeldet und der Warenkorb angezeigt wird, d.h. Oxid schaltet auf SSL um.

Unter Windows im Internet Explorer bekomme ich eine Meldung, dass Teile der Seite z.B. Bilder via HTTP zugreifen und man kann einstellen, dass diese unsicheren Elemente trotzdem angezeigt werden, dann ist alles gut.

Mit einem Mac und Safari ist die Seite unformatiert, man bekommt keine Fehlermeldung. Alles funktioniert, sieht aber fürchterlich aus. Mit Firefox bekommt man eine Fehlermeldung im Schloss-Symbol der URL Zeile ein Ausrufezeichen und wenn man darauf klickt, wird angezeigt, dass die Verbindung nicht sicher ist weil Teile der Seite mit http statt https zugreifen. Das kann man dann temporär ignorieren lasen und die Seite wird korrekt angezeigt.

Ich dachte zuerst, es liegt an meiner Seite und habe einen ganz frischen Oxid Shop CE 4.9.6 aufgesetzt und der Fehler ist da genau so präsent. Ich kann wegen PayPal leider auf SSL nicht komplett verzichten.

Wie bekommt man das in den Griff? Ich möchte nicht, dass meine Kunden Fehlermeldungen sehen, nur weil alle Browser-Hersteller immer mehr Dinge blockieren.

Wie muss ich Oxid anpassen, damit ich keine Fehler sehe?

Eigentlich muss man im original OXID nichts anpassen, all diese Fehler deuten auf … äähh wie sage ich das denn jetzt… einen unerfahrenen Programmierer bzw allgemein eine Person ohne Fachkenntnisse, die Anpassungen an Shop-Templates durchgeführt hat.
Wobei es nicht zwingen die Templates betrifft, sondern auch von einem Modul kommen kann.

Und an deiner Stelle würde ich nicht irgendwas anpassen, um keine Fehler zu sehen, sondern die Fehler beheben.
Aber ohne einen Link zum Shop ist es unmöglich zu sagen, was genau schief läuft.

Ich habe ja auch gedacht, es liegt irgendwie an meinem Shop, es hat aber mal einwandfrei funktioniert, ohne dass am Shop ausser den Updates was geändert wurde. Ich benutze auch nur das originale Azur Template.

Ich habe daher einen neuen Shop aufgesetzt:

https://www.jsjs.de

Die config ist so definiert:

$this->sShopURL = 'http://www.jsjs.de'; // eShop base url, required
$this->sSSLShopURL  = 'https://www.jsjs.de';   // eShop SSL 

Ich würde mich auch nicht als unerfahren bezeichnen, ich arbeite seit 2012 mit Oxid.

Wenn man statt https nur http benutzt, ist alles in Ordnung.

Irgendeine idee?

Und dieses Zertifikat hat schon mal funktioniert?

Wenn Du unter https://www.whynopadlock.com/index.html mal dein SSL Zertifikat prüfst, siehst Du, dass es wohl nicht ganz in Ordnung ist. Vielleicht wurde die Config am Server oder das Zertifikat geändert.

Ich würde eher aufs SSL Zertifiakt als Fehlerquelle tippen.

Das mit der www.jsjs.de ist ein selbst signiertes Zertifikat, hat aber früher trotzdem funktioniert. Das ist ja auch nur der Testshop. Der richtige Shop hat auch ein richtiges Zertifikat:

https://www.spice-cafe.de/

Hier ist mir dieses Verhalten ja aufgefallen. Und der hat ein richtiges gekauftes Zertifikat.

Den anderen Shop habe ich nur gemacht, um Fehler an der programmierung auszuschließen.

Kann es sein, dass dein Zertifikat auf https://jsjs.de ausgetsellt ist?
Das ist nämlich ein Unterschied.

Nachtrag: Ah, ok…die Information hat gefehlt;-)

Dann weiß ich leider auch nicht weiter.

Keine Ahnung, warum der Shop die Stylsheets und Bilder nicht über HTTPS lädt. Das kann wirklich viele Ursachen haben.

Ich habe eine Lösung gefunden. Auch die Prüfseite https://www.whynopadlock.com/check.php findet jetzt keine Fehler mehr.

In der config.inc habe ich folgende Änderung gemacht:

    $this->sShopURL = 'https://www.spice-cafe.de'; // eShop base url, required
    $this->sSSLShopURL = 'https://www.spice-cafe.de'; // eShop SSL url, optional
    $this->sAdminSSLURL = null;  // eShop Admin SSL url, optional

Dadurch wird OXID gezwungen, immer im SSL zu arbeiten, auch bei Bildern, die früher ursächlich mal ohne SSL geladen wurden. Auch der Admin-Bereich funktioniert mit SSL auf diese Weise, trotz der null-Anweisung, die auch so sein muss, sonst funktioniert der Admin-Bereich gar nicht mehr, weil es eine rekursive Umleitungs-Schleife gibt, sobald man den Admin-Bereicht versucht aufzurufen.

Es ist dabei auch egal, ob der Benutzer mit http oder https den Shop oder Admin Bereich aufruft. Es erfolgt immer ein automatischer Wechsel zu https.

Ist das ein bekanntes Problem?

Hallo,

bei deiner Vorgehensweise leitest du permanent auf https um, was auch bei Google Folgen haben wird!

https://www.spice-cafe.de
http://www.spice-cafe.de

sind für Google 2 unterschiedliche Seiten!

was aber kein Problem ist, solange beide Properties in den webmaster tool registriert sind. Oder man könnte auch die Adressänderung durchführen.
https://support.google.com/webmasters/answer/6033049

Aber habe keine Ahnung, ob es nötig ist oder nicht, hat bei mir nie geklappt.

Ich habe gerade gesehen, selbst ich habe meinen Shop mit der falschen Domain verlinkt. :frowning:

Ich würde beim Standard bleiben und den Fehler suchen.

Frohe Weihnachten!

google hat ja angekündigt. dass vollständig verschlüsselte Seiten im Ranking ein bisschen bevorzugt werden.
Und wenn der Shop keine Performance Probleme im vollständig verschlüsseltem Modus aufweist, sehe ich das eigentlich als einen Gewinn.

Die Seite ist bei mir ja mit http und https völlig identisch. D.h. wenn google eine von beiden Seiten findet spielt das gar keine Rolle, es wird immer https aufgerufen, sobald man einen http Link auf meine Seite aufruft. Ich werde mal die Suchergebnisse im Auge behalten. Immer noch besser als verstümmelte Seiten beim Bezahlvorgang, das geht gar nicht.

Seltsam dass sonst noch Niemand genau das Problem hatte oder es nicht gemerkt hat.

du hast uns ja gar keine Möglichkeit gegeben das Problem anzuschauen…

Dein Shop (jsjs) erkennt nicht dass SSL verwendet wird. Schau mal nach ob in $_SERVER[“HTTPS”] was drinsteht bei SSL.

der “jsjs.de” ist nur eine Testseite, der eigentliche Shop ist “www.spice-cafe.de”. Die Seite wird grade gesichert und ab Morgen wieder verfügbar. Mit der “jsjs.de” habe ich nur bewiesen, dass der fehler auch bei einer frisch und neu aufgesetzten Seite genau so passiert wie bei meinem “alten” Shop, detr ja schon dutzende Male aktualisiert wurde.

[QUOTE=j.s.com;176797]der “jsjs.de” ist nur eine Testseite[/QUOTE]
Ist mir klar. ich dachte du willst vielleicht die Ursache herausfinden.

Ich habe für die jsjs.de kein Zertifikat und da der Shop problemlos läuft geh ich da auch nicht mehr ran, der muss ja online sein. Wäre interessant zu wissen, ob noch wer dasselbe Problem hat, da es sich ja so schön mit einem neu aufgesetzten Shop reproduzieren lässt. Ich dachte eher an ein Sicherheitsproblem bei den neuen Browser-Versionen. Das wird ja immer restriktiver.

Was das Problem wahrscheinlich ist und wie man herausfinden kann ob es daran liegt hab ich ja schon geschrieben.