Hinter Reverse-Proxy: SW6 generiert falsche URLs(?)

Shopware 6 (German) Administration
1

Hi,

ich - beruflicher Vollzeit-Linux-Admin - habe hier von einer Agentur einen Shopware 6 System aufgesetzt bekommen, dass unter einer eigenständigen Domain sauber funktioniert.

Hinter einem Reverse-Proxy(derzeit Apache, mit NGINX aber gleiches Phänomen) funktioniert der Shop aber nicht.

Alle identifizierenden Angaben sind verfremdet. Die Doppelslashes in den URLs habe ich weggelassen, weil mir als neuer Nutzer nicht erlaubt wird, mehr als 2 Links zu posten.

Der Shop soll in die folgende Webseite eingebunden werden:

https:www.gartenzwerge.de/shop

Das ist das Apache-Konfigurationsfragment bzgl. der RevProxy-Konfiguration:

        SSLProxyEngine On
        <Location /shop/>
                ProxyPass             https:shop.gartenzwerge.de
                ProxyPassReverse      https:shop.gartenzwerge.de
        </Location>

Wenn ich jetzt den Shop via Browser(oder Kommandozeile via wget) aufrufe, dann bekomme ich so etwas wie eine Index-Seite, bei der aber alle Inhaltselemente ohne den Teilpfad /shop/ generiert wurden.

Beispiel:
https:www.gartenzwerge.de/media/03/17/23/1650983199/gartenzwerge-logo-weiss.png

Richtig wäre:
https:www.gartenzwerge.de/shop/media/03/17/23/1650983199/gartenzwerge-logo-weiss.png

Letztere Grafik ist so korrekt abrufbar über den Reverse-Proxy. Erstere natürlich nicht, weil nur /shop/.* an das Shopware-System weitergeleitet wird.

Der Channel, bzw. die Basis-URL ist eingestellt auf: https:www.gartenzwerge.de/shop.

Wir (der Agenturmitarbeiter und ich) haben testweise auch schon mal die Basis-URL auf dem Shopware-System auf https:shop.gartenzwerge.de/shop/ umgestellt und entsprechend das Apache-ProxyPass auf „https:shop.gartenzwerge.de/shop/“. Gleiches Phänomen. Das „/shop“ ist nicht in den generierten Links enthalten. Wenn ich https:shop.gartenzwerge.de/shop/ direkt aufrufe funktioniert der Shop.

Für mich sieht das nach einem Fehler in der Shopware-Konfiguration aus. Oder habe ich an der Reverse-Proxy-Konfiguration etwas falsch gemacht? Was könnte das sein?

Gibt es irgendwo noch weitere Hilfreiche Hinweise für den Betrieb von Shopware hinter einem Reverse-Proxy?

Nachtrag: Das hier: How to Configure Symfony to Work behind a Load Balancer or a Reverse Proxy (Symfony Docs) werde ich wohl noch konfigurieren müssen, aber wenn ich das richtig verstanden habe, geht das nur um das Logging. Oder stört das auch bei der Authentifizierung(weil alle remote ips ja nun der Proxy sind)?

2

Grundsätzlich mal zu der Aufgabe, die der Kunde von mir wünscht, dass sie umgesetzt wird:

Der Shop soll von allen URLs aus Gründen der Suchmaschinenoptimierung(SEO) nur unter der Hauptdomain(www.gartenzwerge.de) referenziert werden.

Die den Shop betreuende Agentur hat mittlerweile eine Erklärung für das Verhalten, welche ich hier samt Workaround wiedergeben möchte. Da mir die Shopware Terminologie nicht klar bekannt ist, verwende ich nur die Begriffe, so wie sie mir genannt wurden. Falls jemand die korrekten Begriffe dazu kennt, kann er sie gerne ergänzen.

Erklärung des Verhaltens von Shopware

Shopware kennt auf der einen Seite seine Sales-Channels, eine Basis-URL des Shops, und auf der anderen Seite das Backend, auf der die Shopwareinstanz an sich läuft. Der Grossteil der Inhaltselmente wird nun über die URL des Sales-Channels geladen. Ein Teil wird aber auch über die Backend-URL geladen.

Laut der Agentur, kann dieses Verhalten nicht geändert werden.

Für mich als Admin denke ich mir, dass das eigentlich nicht sein kann. D. h. hier existiert eine Wissenslücke seitens der Agentur, die den Shop aufgesetzt hat oder aber das ist korrekt und es gibt tatsächlich keine Möglichkeit einen komplett sauber getrennten Reverse-Proxy Betrieb mit Shopware 6 zu konfigurieren. Das wäre für mich ein echter Qualitätsmangel/Bug in der Software. Ich tendiere zu ersterem.

Die folgenden Variablen setze ich für die weitere Ausführungen:

  • Reverseproxy: https:www.gartenzwerge.de
  • Sales-Channel-URL: https:www.gartenzwerge.de/shop
  • Shop-Backend-URL: https:shop.gartenzwerge.de

Mögliche Workarounds

1. Zusätzliche Proxy-Weiterleitungen für die Links ins Backend

Alle Anfänge der URLs in den Links, die an den Shop gehen sollen und fälschlicherweise auf den Reverseproxy zeigen werden am Reverseproxy per „ProxyPassReverse“ an das Backend weitergeleitet. Das wäre hier aktuell folgendes Muster:

^/(sitemap|recovery|js|fonts|css|thumbnail|media|theme|bundles)

Die ReverseProxyKonfiguration des Apache wäre hier:

ProxyPreserveHost On
SSLProxyEngine On
<LocationMatch "/(sitemap|recovery|js|fonts|css|thumbnail|media|theme|bundles)"> 
                ProxyPass             https:shop.gartenzwerge.de
                ProxyPassReverse      https:shop.gartenzwerge.de
                # ich vermute hier muss noch ein zusätzlicher Channel im Shopware eingetragen werden: 
                # https:www.gartenzwerge.de (Den Channel gibt's aktuell ja nur mit dem Pfad /shop hinten dran
</LocationMatch>
<Location /shop>
                ProxyPass             https:shop.gartenzwerge.de/shop
                ProxyPassReverse      https:shop.gartenzwerge.de/shop
</Location>

Problematisch ist dabei, dass es dabei keine Kollisionen in der Verwendung mit der auf dem ReverseProxy betriebenen Webseite geben darf, sonst funktioniert diese natürlich nicht mehr korrekt.

Wir haben diese Variante gewählt, weil es glücklicherweise keine Kollisionen in der Verwendung mit der auf dem ReverseProxy betriebenen Webseite gibt.

2. Einbinden von externen Resourcen

Der Reverse-Proxy könnte unter einer einem anderen VHost als Reverse-Proxy eingetragen werden. Also genau wie im ersten Beitrag gesetzt. Man beachte dass hier kein ProxyPreserveHost gesetzt ist.

        <Location /shop/>
                ProxyPass             https:shop.gartenzwerge.de
                ProxyPassReverse      https:shop.gartenzwerge.de
        </Location>

Das hat zur Folge, dass externe Resourcen eingebunden werden Dementsprechend muss ein CORS-Header gesetzt werden, der die Verwendung von Elementen über den externen Host shop.gartenzwerge.de erlaubt. Ansonsten blockiert der Browser wegen Same-Origin-Policy diese Resourcen. Bei uns erfüllt das nicht die Aufgabenstellung.

3. Umschreiben des Inhaltes der Webseiten

Sowohl NGINX als auch Apache bieten die Möglichkeit den Inhalt der Webseiten umzuschreiben. So wäre es möglich, die Links in der gewünschten Weise anzupassen, bevor diese an den Client ausgeliefert werden.

Problem dabei ist u. a. dass Webserver die Requests mittlerweile per default komprimieren. D. h. man müsste die Komprimierung hier ausschalten. Vielleicht mag es eine gute Variante geben, dies zu tun. Z. B. ausschalten der Komprimierung im Shopserver und einschalten der Komprimierung nur im Reverse-Proxy. Das scheint mir aber insgesamt schon etwas komplexer zu sein.

1 „Gefällt mir“