Shopware 6 HTTPS

Shopware 6 (German) Installation / Einstieg
1

Hallo,

wenn ich in meinem Apache oder in der .htaccess die Seite auf Https umleite kommt folgender Fehler:

Shopware\Storefront\Framework\Routing\Exception\SalesChannelMappingException: Unable to find a matching sales channel for the request: http://…". Please make sure the domain mapping is correct.

at /var/www/html/vendor/shopware/storefront/Framework/Routing/RequestTransformer.php:120

at Shopware\Storefront\Framework\Routing\RequestTransformer->transform(object(Request)) (/var/www/html/vendor/shopware/core/HttpKernel.php:140)

at Shopware\Core\HttpKernel->doHandle(object(Request), 1, true) (/var/www/html/vendor/shopware/core/HttpKernel.php:77)

at Shopware\Core\HttpKernel->handle(object(Request)) (/var/www/html/public/index.php:83)

 

vielleicht kann mir jemand da weiterhelfen

vielen dank

2

Im Sales Channel bei den Domains müsstest du eine Domain mit https:// konfigurieren, dann sollte es klappen.

3

Das hatte ich bereits gemacht 

Es funktioniert leider nicht

Bei der Einstellung “Erstelle Domäne URLs” ist meine Domain mit Https und Http eingetragen

4

Ich habe 2 Testshops erstellt

Bei dem einen https://smartphone-teile.de/ werden die Bilder nicht geladen weil es Mixed Content ist

und bei shop.atalla.info lässt sich die seite gar nicht mehr laden wenn ich die .htaccess um das hier ergänze

    RewriteCond %{HTTPS} !on
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
 

5

https://symfony.com/doc/current/deployment/proxies.html

Ist wahrscheinlich ein allgemeines Symfony Problem.

Gruß Heiner

6

Das hilft mir leider nicht sonderlich weiter.

Ich verstehe auch nicht warum es nicht mehr leute betrifft.

7

Versuch doch mal:

https://symfony.com/doc/current/deployment/proxies.html#but-what-if-the-ip-of-my-reverse-proxy-changes-constantly

Also:

 Request::setTrustedProxies( ['127.0.0.1', 'REMOTE\_ADDR'], Request::HEADER\_X\_FORWARDED\_ALL ); Vor: $request = Request::createFromGlobals();

In der puplic/index.php

8

habe ich gemacht aber anscheinend wird die index.php nicht neugeladen, weil die selben Zeilen beim Fehler angezeigt werden

man kann zwar auf https://shop.atalla.info/admin#/login

aber das einloggen funktioniert nicht weil die Auth. über Http geht --> also muss es irgendwie intern konfiguriert werden. es wird immer der host ohne https genommen.

vendors-node.js?15848714151360952:1 Mixed Content: The page at ‚Shopware Administration (c) shopware AG‘ was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint ‚http://shop.atalla.info/api/oauth/token‘. This request has been blocked; the content must be served over HTTPS.

9

Guten Abend,

 

wurde das Problem inzwischen gelöst? Ich habe exakt die gleichen Probleme.

 

Dankeschön

10

nein leider nicht ich komme da überhaupt nicht weiter 

1 „Gefällt mir“
11

Falls noch jemand nach der Lösung bzw dem Grund für den Fehler sucht:

Ich hatte exakt das gleiche Problem wie der OP.

Hintergrund:
Ob das Backend HTTPS oder HTTP Anfragen an die REST-API stellt wird bestimmt durch die Initialisierung in

vendor/shopware/platform/src/Administration/Resources/views/administration/index.html.twig

Shopware.Application.start({
  apiContext: {
    host: '{{ app.request.host }}',
    port: {{ app.request.port }},
    scheme: '{{ app.request.scheme }}',
    schemeAndHttpHost: '{{ app.request.schemeAndHttpHost }}',
    uri: '{{ app.request.uri }}',
    ...

app.request  Parameter kommen von Symfony.

 

Schlussendlich war mein Problem dadurch bedingt, dass die URL-Einstellung unter Storefront > Domains  nicht die gleiche war mit der der Shop aufgerufen wurde.

Weil Shopware im Docker-Container lief und vom Host über Apache-Reverse-Proxy angesprochen wurde, konnte (und wollte) ich das Problem auf die Schnelle nicht lösen und habe Shopware auf einer separaten VM direkt, ohne Docker, installiert.

 

Ein schneller Hack für zwischendurch wäre, Schema und Host oben in der index.html.twig  hardcodiert einzutragen um sich zumindest einloggen zu können (Hier bitte sich 10+ Asterixe denken, mit vielen Gründen warum das nicht gemacht werden sollte :wink: ).

 

 

12

Vielleicht hilft auch folgendes, wenn ein Reverse-Proxy davor ist (muss ggf. an die Umgebung angepasst werden).

nginx (z.B. Location Block):
fastcgi_param HTTPS on;

apache vhost:
SetEnvIf X-Forwarded-Proto “https” HTTPS=on