it-swarm.com.de

So fügen Sie der Htaccess-Datei "RewriteRule" mit _route _ = $ 1 die Option "https erzwingen" hinzu

Ich habe die Unterstützung für eine Opencart 1.5-Site geerbt, für die SSL aktiviert sein muss.

Ich habe die config.php -Dateien in / und admin/ bearbeitet und das Hinzufügen von https:// zur URL funktioniert im Browser und Links werden mit HTTPS generiert.

Unabhängig von der Methode einer .htaccess -Umleitung, die ich versuche, wird die Site jedoch nicht geladen.

Das Folgende ist in der .htaccess -Datei und ich vermute, dass das Problem mit der letzten Zeile hier mit route zusammenhängt, die ich vorher nicht gesehen habe .

RewriteBase /
RewriteRule ^sitemap.xml$ index.php?route=feed/google_sitemap [L]
RewriteRule ^googlebase.xml$ index.php?route=feed/google_base [L]
RewriteRule ^download/(.*) /index.php?route=error/not_found [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !.*\.(ico|gif|jpg|jpeg|png|js|css)
RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA]

Irgendwelche Vorschläge, wie ich HTTPS zu dieser RewriteRule hinzufügen kann?

Info hinzugefügt ...

Ich habe zum Beispiel verschiedene Ergänzungen in der Datei .htaccess ausprobiert

RewriteCond %{HTTPS} off
RewriteRule  ^(.*)$ https://%{HTTP_Host}/$1 [R=301,L,NE]

Wenn ich das nach der vorhandenen Umleitung hinzufüge, scheint es keinen Effekt zu haben.

Wenn ich es kurz nach dem RewriteBase / hinzufüge, gibt mir Firefox die Nachricht:

Die Seite wird nicht richtig umgeleitet

Im Firefox-Debugger heißt es

about: neterror? e = redirectLoop & u = https% 3A // www.example.com/& c = ....

Auf der Registerkarte Netzwerk werden 21 Anforderungen mit dem Status 301 angezeigt

SSL wird vom Hosting-Unternehmen verwaltet, aber ohne die neue Umleitung auszuführen, führt das Hinzufügen von s zur Adresse zu einer funktionsfähigen SSL-Site.

4
Andrew Real

Wenn ich das nach der vorhandenen Umleitung hinzufüge, scheint es keinen Effekt zu haben.

Ja, das ist richtig. mod_rewrite-Direktiven werden (in jedem gegebenen Kontext) von oben nach unten ausgeführt. Die vorhandenen Anweisungen implementieren ein Muster vom Typ Front-Controller und schreiben folglich die meisten Anforderungen an index.php um. Wenn die Anforderung umgeschrieben wird, werden nachfolgende Anweisungen (dh Ihre Weiterleitung) einfach nie verarbeitet. (Ändern Sie jedoch Ihre Anforderung in etwas wie /foo/bar.css - unabhängig davon, ob diese Datei vorhanden ist oder nicht - und die Umleitung sollte trotzdem ausgelöst werden.)

Wenn ich es erst hinzufüge, nachdem RewriteBase/Firefox mir die Nachricht gegeben hat:

Ja, die HTTP-zu-HTTPS-Umleitung sollte ganz oben in Ihrer Datei stehen. Nach der RewriteBase Direktive ist ein logischer Ort, um es zu setzen.

Die Seite wird nicht richtig umgeleitet

Mit anderen Worten, Sie sehen eine Umleitungsschleife. Mit der Anweisung, die Sie angegeben haben und die HTTPSServervariable verwendet, impliziert dieser Fehler, dass Ihr Host SSL mit einer Art Front-End-Proxy und Datenverkehr vom Front-End-Proxy implementiert hat Bei Ihrer Site handelt es sich wahrscheinlich um normales HTTP (dh unverschlüsselt).

Sie müssen mit Ihrem Webhost klären, dass dies der Fall ist, und er sollte Ihnen genau mitteilen können, welche Direktiven Sie verwenden sollten. Dies kann spezifisch für Ihre Serverkonfiguration sein.

Einige Hosts setzen eine Variable HTTPSenvironment ​​(ja, gleicher Name, aber unterschiedliche Variable), wenn die Anforderung über HTTPS eingeht. Der Zugriff erfolgt wie %{ENV:HTTPS} (im Gegensatz zu %{HTTPS}). Dies ist einigermaßen üblich, aber serverspezifisch.

Ein Standard-Proxyserver setzt den HTTP-Anforderungsheader X-Forwarded-Proto in der weitergeleiteten Anforderung an Ihren Anwendungsserver. Daher können Sie die erforderliche HTTP-zu-HTTPS-Umleitung mit der folgenden Methode durchführen:

RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*) https://www.example.com/$1 [R=301,L,NE]

Sie müssen jedoch mit Ihrem Webhost klären, dass SSL tatsächlich so implementiert ist, bevor Sie so etwas in der Produktion verwenden. Befindet sich Ihre Site nicht hinter einem (SSL-) Proxyserver, kann jemand eine böswillige Anfrage erstellen und verhindern, dass die Site zu HTTPS umgeleitet wird.

Da Sie mit 301 (permanenten) Weiterleitungen in Konflikt geraten, müssen Sie vor dem Testen den Browser-Cache leeren.


Nebenbei: Nur ein paar zusätzliche Kommentare zu folgendem .htaccess Code ...

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !.*\.(ico|gif|jpg|jpeg|png|js|css)
RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA]

Ich habe diesen Code in Bezug auf OpenCart oft wiederholt gesehen (in der Tat scheint er Teil der offiziellen Distribution zu sein), aber es kommt mir ein bisschen seltsam/rätselhaft vor:

  1. Das Vorhandensein der Anweisung 3rd RewriteCond, die nach REQUEST_URI prüft, verhindert, dass Anforderungen, die .ico oder .gif usw. enthalten (dh normalerweise "statische Ressourcen"), weitergeleitet werden Opencart. Da diese Prüfung jedoch nach den ersten beiden Bedingungen angezeigt wird, die bereits auf vorhandene Dateien/Verzeichnisse prüfen, wird geprüft, ob Anforderungen an "statische Ressourcen" vorhanden sind, die nicht tatsächlich echten Dateien zugeordnet sind. Ist das ein Sicherheitsmerkmal?

    Eine Überprüfung dieser Art wird normalerweise implementiert, um die Effizienz zu verbessern, da Dateisystemüberprüfungen "teuer" sind. Aber um das zu tun, sollte es als separate Regel implementiert werden vor dem Front-Controller. Dies hätte den gleichen "Sicherheits" (?) - Vorteil wie oben, jedoch mit verbesserter Effizienz.

    Mit anderen Worten, entfernen Sie diese RewriteCond Direktive und verwenden Sie stattdessen etwas wie das folgende vor dem Front-Controller (obwohl der Regex immer noch nach einem String-Ende-Anker bittet, dh $ am Ende des regulären Ausdrucks, andernfalls stimmt er mit .css (zum Beispiel) irgendwo in der URL überein - vielleicht ist das die Absicht, aber es ist auch weniger effizient):

    RewriteRule \.(ico|gif|jpg|jpeg|png|js|css) - [L]
    
  2. Das RewriteRulepattern^([^?]*)looks wie ein Anfängerfehler. Auf den ersten Blick könnte es aussehen so, als würde versucht, alles in der URL zu erfassen, bis auf die Abfragezeichenfolge (die mit einem wörtlichen ? in der URL beginnt), ohne sie jedoch einzuschließen. Ist dies jedoch nicht der Fall, ist die Abfragezeichenfolge nicht Teil des URL-Pfads, dem das RewriteRulepattern entspricht. Stattdessen entspricht dies alles bis zum ersten RL-encoded? im URL-Pfad (falls vorhanden). Das ist seltsam, es sei denn, es ist eine andere "Sicherheits" -Funktion? Wenn es sich jedoch um eine "Sicherheits" -Funktion handelt, sollte sie stattdessen früher in der .htaccess -Datei als Blockierungsanweisung implementiert werden.

Leider konnte ich keine weitere Erklärung dafür finden, warum die Richtlinien möglicherweise so geschrieben wurden.

1
MrWhite