Die Presse

Sophiadesigns Blog

Internes & PMs · Sophiadesigns Blog · In der Presse

Git und staging/dev-Zugriffskontrolle per htaccess sinnvoll kombinieren – ohne Verwendung von gitignore

Sobald man mindestens zwei Umgebungen bei der Webentwicklung verwendet, z.B. eine um neue Features zu testen und eine für den Live-Betrieb, braucht man in der Regel auch unterschiedliche htaccess-files für beide Umgebung. Die dev/staging-Umgebung soll nämlich nicht durch Unbefugte betreten werden können. Der wichtigste Anwendungsfall ist sicher Google: wem ist es nicht schon mal passiert, dass man vergisst noindex, nofollow für den dev/staging-Bereich einzustellen und plötzlich dev.kundendomain.de im Index zu finden? Peinlich.

Das Problem: Die Kollision von Git und htaccess

Daher verwenden wir für jede dev/staging-Umgebung htaccess. Das lässt sich leicht aufsetzen, macht genau was es soll, man muss sich keine großartigen Gedanken mehr über meta robots machen und kann sich auf die Entwicklung konzentrieren. Problematisch wird es, wenn man Git zur Versionskontrolle verwendet. Normalerweise ist die htaccess-Datei Teil des Codehaufens, den man mit Git verwaltet, da die htaccess auf der Webseite noch weitere Funktionen erfüllt. Um zu verhindern, dass live.kundendomain.de auf einmal per htaccess jeglichen externen Zugriff ausschließt, muss man sich etwas überlegen. Häufig wird dabei wohl auf die Git-interne Möglichkeit zurück gegriffen, bestimmte Dateien zu ignorieren. Das funktionierte aber bei uns nie so wirklich gut, und daher hier eine andere Lösung, die auch andere Vorteile neben der Optimierung des Workflows mit Git bietet.

Die Lösung: ein htaccess für alle Umgebungen

Ausgehend von diesem Artikel verwenden wir eine einheitliche htaccess-Datei. Diese Datei überprüft, ob die Seite über eine bestimmte URL aufgerufen wird und fragt nur dann nach einem Passwort. Sprich, wenn dev.kundendomain.de als zu schützende URL eingetragen ist, wird eine Passwort-Abfrage geworfen, wenn die Webseite über kundendomain.de aufgerufen wird, kann die Webseite ganz normal besucht werden.

SetEnvIf Host dev.kundendomain.de passreq
AuthType Basic
AuthName "Password Required"
AuthUserFile /full/path/to/.htpasswd
Require valid-user
Order allow,deny
Allow from all
Deny from env=passreq
Satisfy any

Wie in jeder htaccess-Datei muss der gesamte Pfad zur htpasswd-Datei angegeben werden. Wir haben die htpasswd jetzt in einem zentralen Ordner liegen, das bedeutet nämlich auch einen geringeren Pflegeaufwand, siehe unten. Außerdem ist es sicherer, die htpasswd-Datei außerhalb des htaccess-Verzeichnisses liegen zu haben und somit jeden unbefugten Direktzugriff auszuschließen.

Diese Datei kann jetzt frei zwischen den verschiedenen Branches gemerged und in unterschiedliche Umgebungen deployed werden ohne dass es zu Problemen kommt. In Git sind keine weiteren Einstellungen erforderlich.

Mod. 1 für das Agentur-Umfeld: eine htpasswd für alle Projekte

Als Agentur verwaltet man gegebenenfalls mehrere Kunden-Seiten auf einem eigenen Server. Erfahrungsgemäß ist das Aufsetzen und Verwalten der vielen unterschiedlichen htaccess-Dateien für die verschiedenen Kunden mit der Zeit ziemlich nervig und unübersichtlich. Um das obige htaccess/htpasswd-Setup jetzt noch effizienter als Agentur einzusetzen, ist es wichtig die htpasswd-Datei an einen zentralen Ort auf dem Server auszulagern, statt sie irgendwo in den Ordnern des Kundenprojekts aufzubewahren.

In diese zentrale htpasswd-Datei können dann alle Kundenzugänge eingepflegt werden. Die htpasswd-Datei sieht dann in etwa so aus (Link zu einem einfachen htpasswd-Generator):

kunde1:asdasdd24123sdfad3w1
kunde2:hrtger423ewfewe

Jetzt sollte noch die htaccess-Datei entsprechend angepasst werden, so dass nur bestimmte User zu bestimmten Umgebungen zugelassen werden, so dass die Kunden sich nicht gegenseitig auf die dev/staging-Umgebungen gucken. Der Fall ist zwar extrem theoretisch, aber denkbar. Deshalb passen wir die htaccess für dev.kundendomain1.de wie folgt an:

Require user kunde1

Mod. 2 für Agenturen: ein Zugang für alle dev/staging-Umgebungen

Zusätzlich haben wir noch einen einheitlichen Zugang für die interne Verwendung angelegt. Das spart wenigstens einmal das Öffnen von Excel :) Die zentrale htpasswd-Datei sieht dann so aus:

sophiadesigns:123213dsdfsd45ffgsf
kunde1:asdasdd24123sdfad3w1
kunde2:hrtger423ewfewe

Die htaccess-Datei in allen Kunden-Projekten wird wie folgt ergänzt (mehr zum Thema htaccess bei selfhtml.org, z.B. auch zum Thema Gruppenzugriff):

Require user sophiadesigns kunde1

Ergebnis und Vorteile

Da haben wir sie, die vermeintlich perfekte Lösung aller htaccess-Probleme, sogar wenn Git im Spiel ist. Die Vorteile im Kurzüberblick:

  • htaccess/htpasswd Lösung, die mit mehreren Umgebungen problemlos zusammen spielt
  • eine zentrale htpasswd-Datei, die außerhalb vom Projekt-Ordner liegt (sicherer) und zentral verwaltbar ist (bequemer)
  • einen gemeinsamen Agentur-Zugang für alle Entwicklungsumgebungen
  • ein – leicht recyclebares – htaccess-File für zukünftige Projekte


Von in Blog am 15. Januar 2013 mit den Schlagwörtern: , , mit 0 Kommentaren »


Name (erforderlich)
e-Mail (erforderlich)
URL (no no-follow)
Kommentar (erforderlich)
XHTML: Diese HTML-Tags dürfen Sie verwenden: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>