von Wer ein Webprojekt lokal auf seinem Rechner entwickelt und die geänderten Dateien regelmäßig auf einen Webserver hochlädt, kommt irgendwann unweigerlich an den Punkt, an dem in der produktiven Umgebung Abweichungen von der lokalen Entwicklungsumgebung nötig sind.
So lässt sich z. B. folgende Rewrite-Regel in der htaccess-Datei nur in der produktiven Umgebung nutzen:
|
1 2 3 |
# rewrite domain-name RewriteCond %{HTTP_HOST} !^www\.blablatest\.de$ [NC] RewriteRule ^(.*)$ https://www.blablatest.de/$1 [R=301,L] |
In der Testumgebung hätte diese Regel keinen Sinn und würde deren Nutzung unmöglich machen.
Mit der Zeit nervt es einen dann, dass man bestimmte Stellen in der Entwicklungsumgebung auskommentieren und immer wieder anpassen muss. Spätestens nachdem man das erste Mal im Eifer des Gefechts die Dateien auf dem Webserver mit eigentlich nur lokal nutzbaren Dateien überschrieben hat und z. B. die Test-Datenbank von der Webanwendung nicht gefunden werden kann, geht man dazu über verschiedene Dateien anzulegen:
Die Gefahr die falschen Dateien von der Entwicklungs- in die Produktivumgebung zu übertragen ist aber nicht gebannt und auch bei der Nutzung einer Versionskontrolle müsste man mehrere Dateien pflegen. Auf der Suche nach einer Lösung für dieses Dilemma kam mir die Idee eine Variable zu nutzen, die kenntlich macht, dass man sich gerade in der Testumgebung befindet. Um diese auf möglichst hoher Ebene zu setzen, habe ich mich entschieden, diese direkt im Apache zu konfigurieren. Wie meine Recherche zeigte, hatten schon einige Leute vor mir diesen Einfall.
Das Vorgehen ist dabei recht einfach. Man initialisiert die Variable über die httpd.conf oder eine eigene conf-Datei:
|
1 2 3 4 5 |
# define variable DEV_ENV for test environment Define DEV_ENV true # Syntax Define variable-name value |
Diese Variable kann nun in der htaccess-Datei abgefragt werden. Je nach Apache-Version soll es hierbei Probleme geben. In meiner aktuellen Xampp-Installation scheint der Apache aber aktuell genug zu sein. Das Blöde ist nur, dass diese Variable nicht für PHP-Skripte oder dergleichen nutzbar ist. Deshalb setze ich diese bei der Überprüfung in der htaccess-Datei direkt nochmal als Environment-Variable, da diese über die $_SERVER-Variable auch in Skripten abgefragt werden kann:
|
1 2 3 4 5 6 |
# check if site is running in test-environment <IfDefine DEV_ENV> # set DEV_ENV-variable in a context in which it is accessible by php-scripts # through the global $_SERVER-variable: SetEnv DEV_ENV true </IfDefine> |
Die DEV_ENV-Variable direkt in der httpd-conf als Environment-Variable zu konfigurieren kann man leider vergessen. Es funktioniert einfach nicht, ist aber bei dem aufgeigten Vorgehen halb so wild. So spart man sich unnötiges Herumgebastel mit irgendwelchen Startparametern für den Apache, über welche man es schaffen soll die Variable als Environment-Variable zu setzen.
Nutzung der DEV_ENV-Variable in der htaccess-Datei:
|
1 2 3 4 5 6 |
# check if site is running in production-environment <IfDefine !DEV_ENV> # rewrite domain-name RewriteCond %{HTTP_HOST} !^www\.blablatest\.de$ [NC] RewriteRule ^(.*)$ https://www.blablatest/$1 [R=301,L] </IfDefine> |
Nutzung der DEV_ENV-Variable in PHP-Skripten:
|
1 2 3 4 5 |
// get the right config-file $config_file = 'config/online.ini'; if ($_SERVER['DEV_ENV'] == 'true'){ $config_file = 'config/localhost.ini'; } |
Lediglich bei der Nutzung dieser Variable in PHP bin ich mir nicht sicher ob dies in Bezug auf die Sicherheit der Webanwendung bedenklich ist.
Quellen:
https://stackoverflow.com/questions/6569080/how-to-define-a-variable-in-apaches-httpd-conf-file
https://stackoverflow.com/questions/11073752/apache-ifdefine-conditionals-in-htaccess
https://stackoverflow.com/questions/11073752/apache-htaccess-applying-basic-authentication-conditionally-based-on-environm
