Home > Tipps & Tricks > Zend Framework (1.x) > Zend MVC: Erzwingen von https- und https-URLs mittels URL-Rewriting

Zend MVC: Erzwingen von https- und https-URLs mittels URL-Rewriting

Geschrieben von   admin on    Januar 8, 2011

Es ist eine häufig auftretende Problemstellung bei Webanwendungen, dass einige Adressen der Website per https, andere aber per http aufgerufen werden sollen.

Sofern man eine Zend Framework-MVC-Anwendung erstellt, gibt es - ausser dem in diesem Beitrag beschrieben Verfahren - mindestens ein andere Lösung mittels Controller-Plugin, die ich hier beschrieben habe.

Eine Möglichkeit hat man per mod_rewrite-Anweisungen. Die unten vorgestellten Anweisungen habe ich für Helicons ISAPI_rewrite erstellt. Es sollte aber genauso auch mit mod_rewrite funktionieren. Übrigens, für IIS-Benutzer: Es gibt von ISAPI_rewrite eine "light"-Variante, die kostenlos einsetzbar ist, aber keine individuelle Einstellung für getrennte Websites auf dem gleichen Server zulässt. Daher möchte ich für den IIS ab Version 7.x Helicon Ape (Apache Emulator) empfehlen. Helicon Ape ist ein Tool, was beim IIS für fast komplette Apache-Kompatibilität sorgt, und im Gegensatz zu ISAPI_Rewrite komfortabel zu konfigurieren ist. Nicht unwichtig: Die kostenlose Version lässt sich für bis zu drei Domains auf dem gleichen Server einsetzen! Und auch mit der kostenlosen Version sind individuelle Einstellungen auf Website und Verzeichnisebene möglich!

Kommen wir nun zu den Rewrite-Anweisungen mit nachfolgenden Erklärungen:

RewriteEngine On
RepeatLimit 200
RewriteBase

#Fix missing trailing slash char on folders
RewriteRule ^([^.?]+[^.?/])$ $1/ [R,L]

RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]

#Redirect non-HTTPS to HTTPS
RewriteCond %{HTTP:Host} (.*)
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} (^/login/.*)
RewriteRule .? https://%1%2 [R,L]

#Redirect HTTPS to non-HTTPS
RewriteCond %{HTTP:Host} (.*)
RewriteCond %{HTTPS} on
RewriteCond %{REQUEST_URI} (^(!/login/.*))
RewriteRule .? http://%1%2 [R,L]

RewriteRule ^.*$ /index.php [NC,L]


Mit RewriteBase (ohne Wert) wird eingestellt, dass im Folgenden auch der / nach dem Domänennamen in den RewriteRules angegeben werden muss. Ist das Basisverzeichnis woanders sind entsprechende Anpassungen nötig. Aber ich glaube, mit Zend Framework MVC wird man ohnehin nur glücklich, wenn die Webanwendung gleichzeitig auch das Webroot der Domain ist.

Mit der ersten RewriteRule wird sichergestellt, dass alle Websiten-URLs (ohne Dateiendung) mit / enden.

Der darauf folgende Block dürfte jedem geläufig sein, der für Zend Framework MVC schon einmal das URL-Rewriting eingestellt hat. Es geht darum, für tatsächlich existierende Datein und Verzeichnisse die Verarbeitung an dieser Stelle abzubrechen. Es erfolgt keine Umleitung dafür. Das der Block oberhalb des folgenden Rests steht, ist immens wichtig: Es ist dann nämlich egal, ob die Seite über https oder http aufgerufen wird. Dateien, wie Bilder, CSS-Dateien und JavaScript-Dateien werden passend zum Protokoll der Seite abgerufen!

Der Block mit dem Kommentar "#Redirect non-HTTPS to HTTPS" sorgt dafür, dass für eine URL /login/ ein Redirect auf die https-URL erfolgt, sofern er aktuell per http vorliegt. Sofern weitere URLs abgedeckt werden müssen, ist statt (^/login/.*) etwa zu schreiben: (^/(login|privat/bereich|auchprivat)/.*))

Der Block mit dem Kommentar "#Redirect HTTPS to non-HTTPS" wiederum sorgt dafür, dass in allen anderen Fällen bei Vorliegen einer https-URL auf die http-Entsprechung umgeleitet wird. Auch hier ist bei der letzten RewriteCond (^(!/login/.*)), um beim obigen Beispiel zu bleiben, durch etwa folgendes zu ersetzen: (^(!/(login|privat/bereich|auchprivat)/.*)). Im Resultat wird für alle Abweichungen der als https-URLs definierten URLs eine Umleitung auf die http-URL erzwungen.

Die letzte Rewrite Rule entspricht der letzten Standardanweisung für das Rewriting bei Zend Framework-MVC-Anwendungen.

Kommentare

Geschrieben von admin am
Nachtrag: Aktuellen Berichten zufolge will Google dazu übergehen, Websites, deren Inhalt ausschließlich per https erreichbar ist, besser zu gewichten. Von daher empfiehlt es sich wohl eher, die ganze Website auf https laufen zu lassen.
Hintergrund: Beim Hin- und Herspringen zwischen http- und https-URLs ergibt sich eine Sicherheitslücke, sofern Cookies verwendet werden. Sitzungs-Cookies lassen sich nämlich bei http durch "Man in the middle"-Attacken abgreifen und anschließend missbrauchen, selbst wenn Formulare per https gesichert übertragen werden. Ein erfolgreicher Angreifer könnte so eine fremde Identität gegenüber Shop-Systemen usw. annehmen.
Kommentar schreiben



(Ihre E-Mail-Adresse wird nicht angezeigt.)


Ungültiger Sicherheitscode

Bitte klicken Sie das Bild an, um einen neuen Sicherheitscode zu laden.