Hotfix für OXID SSL-Problem

Ein Gastbeitrag von Michael Boll und Manuel Diekmann, SHOPMACHER | Ihre Filiale 3.0

Die Fakten

  • Browser: Chrome 23
  • OXID Enterprise 4.5 – 5.0.1
  • HTTPS-Ressourcen werden nicht geladen

Wo liegt das Problem?

Der Aufruf eines OXID-Shops per HTTPS zeigt zwar den Inhalt des Shops, aber das „Layout“ fehlt – das CSS wird nicht geladen – sichtbar wird lediglich eine häßliche Textwüste. Da ein gültiges SSL-Zertifikat hinterlegt ist und alle Ressourcen über die OXID eigenen Funktionen geladen werden, dürfte dies normalerweise kein Problem darstellen. Falsch gedacht! Wer einen Blick in den Quelltext wagt, wird schnell feststellen, dass die Ressourcen nicht über HTTPS, sondern über HTTP geladen werden. Dies führt dazu, dass sich Chrome – korrekterweise – weigert, die Ressourcen von einem unsicherem Ort zu laden.

Verschiedene mögliche Ursachen und erste Ansätze

Um diesem Phänomen nachzugehen, haben wir uns also zuerst wieder in Erinnerung gerufen, was dort geschieht. OXID erstellt die Ressourcen-Pfade anhand der Stamm-URL, oder alternativ anhand von Header-Informationen. Der zweite Fall ist relevant, wenn das System mit einem Loadbalancer arbeitet. So gesehen also alles korrekt; da der Aufruf korrekt über HTTPS erfolgt.

Warum werden für die Ressourcen aber trotzdem HTTP-Pfade generiert? Um einen individuellen Fehler, in Verbindung mit diesem System, auszuschließen, haben wir versucht das Problem bei anderen OXID Enterprise-Installationen nachzustellen. Zuerst bei den eigenen, anschließend auch bei anderen, bekannten OXID Enterprise-Systemen.

Der gleiche Fehler war in so gut wie jeder OXID Enterprise-Installation aufzufinden, welches über eine ähnliche Systemstruktur verfügt. Zum Zeitpunkt der Veröffentlichung ist er noch immer in vielen Shops zu finden. Das allein hätte uns natürlich nicht wirklich weitergeholfen. Da wir aber auch zwei Systeme gefunden haben, bei denen das Problem weniger gravierend und ein System bei dem das Problem überhaupt nicht auftrat, war es uns möglich erste Gemeinsamkeiten zu ermitteln.

Zur leichteren Analyse prüften wir zunächst nur Systeme, die ebenso wie unsere bei SysEleven liegen. Die Wahrscheinlichkeit, dass die grundsätzliche Systemstruktur bei diesen Systemen nahe beieinander liegt, ist relativ hoch. Diese Informationen bildeten die Grundlage für ein Gespräch mit SysEleven. Leider konnten wir auf keine, bereits bekannte, Lösung zurückgreifen. Der eine oder andere Tipp war aber sehr wertvoll. Vielen Dank für die stets schnelle Reaktion!

An dieser Stelle darf ich bemerken, dass es sich durchaus lohnt Blogs aus der OXID Szene zu lesen. Aber das dürfte vermutlich die wenigsten wirklich überraschen. Aufgrund dieser Information ergab sich ein entscheidender Unterschied zwischen den Systemen: Die nicht betroffenen Systeme, hatten den OXID Content-Cache deaktiviert.

Also ran an den OXID Content-Cache

Nach dem klar war, dass nur Systeme mit aktiviertem Content-Cache dieses Problem haben, konnten wir gezielt eine Lösung erarbeiten. Es ist mir wichtig zu sagen, dass der folgende Punkt gut bedacht sein sollte. Gerade bei größeren Systemen sollte dieser Schritt mit den betreffenden Systembetreuern, abgesprochen sein!

Zur endgültigen Validierung haben wir den Content-Cache deaktiviert und siehe da, das Problem war verschwunden. Auch wenn unsere Systeme durchaus ohne Content-Cache funktionieren, war dies für uns keine Alternative. Dieser Schritt löst weder das Problem, noch wollen wir auf den Content-Cache verzichten. Sicher gibt es hier sinnvolle und gute alternative Lösungen. Allerdings sind diese immer mit Kosten oder bestenfalls internen Ressourcen und Arbeitsaufwänden verbunden. Daher war ein Wechsel auch kein Thema, zumal hier wieder der erste Punkt wichtig wird: Das Problem wird dadurch nicht gelöst!

Eine einfache, modulare Lösung muss her!

Da wir jetzt wissen, dass unser Problem definitiv mit dem Content-Cache zusammenhängt, prüfen wir zunächst, wie der Content-Cache vorgeht: In unserem Fall findet sich die relevante Stelle in der /views/oxubase.php in der Funktion getViewId. Hier ist zu sehen, wie sich der für die Cache-Validierung notwendige Hash zusammensetzt. Ohne die einzelnen Bestandteile des Hashes durchzugehen, fällt eines auf: Es wird grundsätzlich, aus der config.inc.php, der Wert sShopUrl eingesetzt. Dementsprechend ist es egal, ob der Aufruf über HTTP oder HTTPS geht. Bei jedem Aufruf wird der Cache immer mit einem HTTP-Aufruf validiert. Über das Für und Wider möchte ich hier nicht weiter spekulieren. Fakt ist allerdings, dass der Content-Cache keine Unterscheidung zwischen HTTPS- und HTTP-Aufrufen macht.

Der findige OXIDianer wird jetzt sagen: „Das stimmt so nicht, im Bestellprozess funktioniert das ja auch!“ Richtig! Schauen wir uns also erneut an, wie der Hash validiert wird. Im Falle des Checkouts hat der Besucher eine Session-ID. Ist diese gesetzt, wird sie zu einem Teil des Hashes. In diesem Augenblick, wird der Hash individuell für den Benutzer und erstellt sich so den notwendigen, validen Cache-Eintrag.

Um unser Problem zu lösen, können wir uns genau an dieser Stelle einklinken. Zunächst prüfen wir, ob es sich um eine HTTPS-Verbindung handelt. Ist dies der Fall, haben wir zwei Möglichkeiten. Entweder wir passen die Shop-URL an, oder wir erweitern den Hash um einen eigenen Wert, z.B. ssl. Anschließend aktivieren wir den Content-Cache wieder

Dank dieser, zugegeben sehr kleinen, Anpassung validiert dieser zuverlässig HTTP und HTTPS Cache-Dateien.

Und damit der geneigte Leser das jetzt nicht nachbauen muss, gibt es hier das fertige Modul – powered by SHOPMACHER – kostenlos zum Download:

https://github.com/syseleven/oxid-contentcachesslfix

SHOPMACHER konzipiert, entwickelt und betreibt maßgeschneiderte eCommerce-Lösungen für Marken. Das Unternehmen bietet unabhängige eCommerce-Beratung, entwickelt Strategie, Konzeption und Wirtschaftlichkeitsrechnung für Online-Filialen und führt Marke, Absatz und Multichanneling zusammen. Die SHOPMACHER setzen eCommerce-Projekte um, sorgen auf erfolgsabhängiger Basis für kontinuierliches Wachstum und sichern einen wirtschaftlichen, flexiblen und skalierbaren. Für die jeweiligen Spezialaufgaben wie etwa Online-Payment oder Fulfillment integriert das Unternehmen Spezialisten in seine Projekte.Die Leistungsschwerpunkte der SHOPMACHER sind: ganzheitliche Beratung für Konzeption, Auf- und Ausbau von Online Filialen inklusive Aufbau der internen eCommerce-Prozesse, Auswahl, Integration und Führung aller Projektpartner und Führung der Online-Filiale. Gründer und Geschäftsführer der SHOPMACHER sind Thomas Gottheil und Marcus Diekmann.