Keine HTTPS URLs in der Shopware 6.6 Administration

Mit dem Major Update von Shopware 6 wurde das darunterliegende PHP-Framework Symfony auf die Version 7 aktualisiert. Durch das Major-Upgrade auf Symfony 7 wurden einige Standard-Konfigurationen entfernt.



Fehlermeldung

Die Shopware 6.6 Administration lädt nicht und zeigt folgende Fehlermeldungen in der Entwickler-Konsole an:

Mixed Content: The page at 'https://s25741.creoline.cloud/admin#/login/' was loaded over HTTPS, 
but requested an insecure stylesheet 
'http://s25741.creoline.cloud/bundles/administration/static/css/app.css?1717772049'. 
This request has been blocked; the content must be served over HTTPS.


Das Problem entsteht, da Shopware keine Information darüber enthält, dass der Request durch einen authentifizierten Load-Balancer weitergeleitet wurde.



Lösung

In Shopware 6.6 muss zusätzlich eine framework.yaml konfiguriert werden, die die ursprüngliche TRUSTED_PROXIES Konfiguration setzt.


# config/packages/framework.yaml

framework:
    trusted_proxies: '%env(TRUSTED_PROXIES)%'


Anschließend kann in der .env.local die TRUSTED_PROXIES Konfiguration eingerichtet werden.

# .env.local

TRUSTED_PROXIES=127.0.0.1,10.20.0.0/24


Stellen Sie außerdem sicher, dass der X-Forwarded-Proto Header durch den Load Balancer an den App-Server gesendet wird.


Beispiel HaProxy

# /etc/haproxy/haproxy.cfg

backend shopware
   mode http
   # [...]

   http-request add-header X-Forwarded-Proto %[var(req.scheme)]
   # Necessary for https URL Generation

Durch die Angabe der dynamischen Variable %[var(req.scheme)] wird das HTTP-Schema aus dem ursprünglichen Request an die HaProxy-Instanz verwendet, um sicherzustellen, dass der übermittelte X-Forwarded-Proto Header dem tatsächlichen weitergeleiteten HTTP-Schema entspricht.


Beispiel NGINX

# /etc/nginx/conf.d/shopware.conf

location / {
   proxy_pass http://10.20.X.X:80;
   # [...]

   proxy_set_header X-Forwarded-Proto $scheme;
}

Durch die Angabe der dynamischen Variable $scheme wird das HTTP-Schema aus dem ursprünglichen Request an die NGINX-Instanz verwendet, um sicherzustellen, dass der übermittelte X-Forwarded-Proto Header dem tatsächlichen weitergeleiteten HTTP-Schema entspricht.



Weitere Fragen?

Für alle weiteren Fragen stehen wir Ihnen gerne jederzeit zur Verfügung.



Quellen