.htaccess-Dateien sind ein einfacher Weg, um Konfigurationsanweisungen vornehmen zu können, die normalerweise in der Webserver-Konfiguration stehen müssten - auf die du beim shared hosting natürlich keinen Zugriff hast.
Mit .htaccess-Dateien kannst du viele spannende Dinge tun; einige Möglichkeiten möchten wir dir hier gerne vorstellen. Eine Einführung in .htaccess-Dateien findest du auch auf apache.org.
Achtung, Falle: .htaccess-Dateien werden immer vom Root-Verzeichnis des Servers aus verarbeitet, nicht erst ab dem DocumentRoot. Das ist dann problematisch, wenn du mehrere Domains hast und dabei DocumentRoots eingesetzt, die unterhalb des primären DocumentRoots, dem html-Verzeichnis liegen. Konkretes Beispiel:
Legst du nun eine /var/www/virtual/erna/html/.htaccess-Datei an, so gilt diese auch für http://blog.erna-von-mattern.nat/, was zu unverhergesehenen Überraschungen führen könnte. Wir empfehlen dir daher, separate DocumentRoots nur neben html anzulegen, also z.B. im konkreten Fall /var/www/virtual/erna/blog als DocumentRoot zu verwenden.
Einer der häufigsten Gründe für den Einsatz von .htaccess-Dateien ist, bestimmte Verzeichnisse mit einem simplen Passwortschutz zu versehen. Der Vorteil ist, dass das ohne zusätzliche Software funktioniert, also auch für Verzeichnisse, in denen lediglich statische Dateien (z.B. Fotos) liegen. Und so geht's:
Du brauchst zunächst eine Passwortdatei, in der die Benutzer und ihre Passwörter gespeichert werden; letztere verschlüsselt. Am einfachsten lässt sich diese Datei mit dem Programm htpasswd verwalten. So legst du sie an und trägst den ersten Benutzer ein:
[larissa@krypton ~]$ htpasswd -m -c /var/www/virtual/larissa/htuser onkeljonas New password: Re-type new password: Adding password for user onkeljonas
Dieser Befehl legt eine Passwortdatei an und trägt den User onkeljonas ein. Hierbei wird interaktiv - zweimal, zum Schutz vor Vertippern - das gewünschte Passwort abgefragt. Es gibt zwar auch einen sogenannten batch mode, bei dem man das Passwort direkt als Parameter mit übergeben kann; hier wäre es allerdings dann in der Prozessliste des Servers für einen kurzen Moment sichtbar und könnte von anderen Usern mitgelesen werden. Das Argument -m bedeutet, dass der Hashwert des Passworts mittels MD5 mit einem Salt generiert wird, was wesentlich schwerer zu knacken ist als die Standardverschlüsselung via crypt(), die htpasswd ansonsten benutzt (für den Fall, dass deine Passwortdatei mal in falsche Hände geraten sollte).
Der Ort und auch der Name der htuser-Datei ist nicht festgelegt; er muss jedoch unterhalb von /var/www/virtual/larissa liegen, damit der Webserver sie auch lesen kann, und es empfiehlt sich, die Datei außerhalb des DocumentRoots zu lagern, so dass sie nicht übers Netz heruntergeladen werden kann.
Zum Anlegen weiterer User lässt du das -c (das für create steht) einfach weg, ansonsten überschreibst du mit dem neuen User den bisherigen User.
Gibst du einen bereits bestehenden Usernamen an, so ändert htpasswd dessen Passwort:
[larissa@krypton ~]$ htpasswd -m /var/www/virtual/larissa/htuser onkeljonas New password: Re-type new password: Updating password for user onkeljonas
Schließlich fehlt noch das Löschen von Usern, das du mit -D (Achtung, Großschreibung!) erzielst:
[larissa@krypton ~]$ htpasswd -D /var/www/virtual/larissa/htuser onkeljonas Deleting password for user onkeljonas
Nun zur eigentlichen .htaccess-Datei. Hierzu kannst du dir einfach diesen Schnipsel kopieren und in deine .htaccess-Datei im gewünschten Verzeichnis einfügen:
AuthType Basic AuthName "Geheimer Bereich" AuthUserFile /var/www/virtual/larissa/htuser Require valid-user # oder auch: #Require user onkeljonas
Den AuthName kannst du natürlich ändern; wichtig ist, dass er in Anführungszeichen steht, zumindest sobald die Bezeichnung aus mehr als einem Wort besteht.
Den Pfad zum AuthUserFile musst du auf den Pfad deiner htuser-Datei anpassen.
Bei Require kannst du angeben, welche Benutzer Zugriff haben sollen. Hierbei kannst du entweder user und dann einen oder auch mehrere User aus einer htuser-Datei angeben (mehrere User einfach mit Leerzeichen trennen), oder du verwendest den speziellen Wert valid-user, um einfach sämtliche User, die in deiner htuser-Datei existieren, zu autorisieren.
Das war's auch schon! Detaillierte weitergehende Informationen, die auch die Bildung von Usergruppen umfassen findest du in der offiziellen Authentifizierungs-Doku auf apache.org.
Ein Teil unserer Webserver nutzt noch mod_ssl, während unsere neueren Hosts mit Pound als HTTPS-Frontend arbeiten. mod_ssl definiert bei HTTPS-Verbindungen eine Servervariable namens HTTPS, während HTTPS-Verbindungen über Pound eine Umgebungsvariable namens HTTPS bereitstellen. Es ist aber ohne Probleme möglich, in einer .htaccess-Datei auf beide Möglichkeiten Rücksicht zu nehmen. So kannst du alle Requests, die keine dieser Variablen haben, grundsätzlich blockieren:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteCond %{ENV:HTTPS} !=on
RewriteRule .* - [F,L]
Oder, noch schicker - du kannst einen Redirect auf die HTTPS-URL auslösen:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteCond %{ENV:HTTPS} !=on
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]
Eine der mächtigsten Möglichkeiten von .htaccess-Dateien ist, aufgerufene URLs auf andere URLs umzuschreiben. Nicht umsonst wird das dahinterstehende Modul mod_rewrite als „damned cool voodoo, but still voodoo“ bezeichnet. Es sei daher an dieser Stelle ausdrücklich auf den offizielle Apache-Dokumentation verwiesen werden, insbesondere auf das Intro zu mod_rewrite als auch auf den Rewrite Guide, der neben einer detaillierten Einführung auch viele praktische Beispiele liefert, die hier den Rahmen sprengen würden.
Exemplarisch zeigen wir dir aber ein Beispiel aus der Realität: Viele Webapplikationen bringen nämlich bereits fertige .htaccess-Dateien mit, die oftmals insbesondere für „schöne“ URLs sorgen, beispielsweise bei DokuWiki:
RewriteRule ^$ doku.php [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) doku.php?id=$1 [QSA,L]
Die erste Zeile sorgt dafür, dass die Startseite des Verzeichnisses, wenn also eine leere URL (dafür steht ^$) aufgerufen wurde, automatisch auf die doku.php umgeschrieben wird. Davon bekommt der Anwender nichts mit: Er sieht einfach nur https://uberspace.de/dokuwiki/, obwohl faktisch https://uberspace.de/dokuwiki/doku.php aufgerufen wird.
Die nächsten beiden Zeilen sind Bedingungen: Die RewriteRule in der vierten Zeile greift nur, wenn die beiden RewriteConds passen. Diese prüfen, ob der aufgerufene Dateiname physisch als Datei (-f) oder Verzeichnis (-d) auf der Festplatte vorliegt, und nur falls nicht, so wird die URL so umgeschrieben, dass aus dem aufgerufenen Dateinamen den URL-Parameter id macht und auch hier die doku.php aufruft. Im Moment liest du beispielsweise die URL https://uberspace.de/dokuwiki/webserver:htaccess - faktisch wurde das intern aber auf die neue URL https://uberspace.de/dokuwiki/doku.php?id=webserver:htaccess umgeschrieben. Ein vergleichbares Regelwerk benutzen übrigens auch andere Web-Applikationen wie z.B. Typo3.
In einigen Dokumentationen wird geraten, PHP-Einstellungen in .htaccess-Dateien unterzubringen (Stichworte: php_value, php_flag, php_admin_value, php_admin_flag). Das funktioniert aber nur, wenn PHP als Webserver-Modul zum Einsatz kommt, was bei uns aus Sicherheitsgründen nicht der Fall ist.
Du hast aber bei uns sowieso die Möglichkeit, eine eigene php.ini zu verwenden (und die Empfehlung, PHP-Einstellungen über eine .htaccess-Datei zu regeln, entspricht üblicherweise dem Umstand, dass genau das bei den meisten anderen Providern eben gerade nicht geht), was wir hierfür auch ausdrücklich empfehlen.
Möchtest du unbedingt bei der .htaccess-Variante bleiben, so gibt es die PECL-Erweiterung htscanner, die zur Laufzeit entsprechende Einträge aus .htaccess-Dateien heraussucht und umsetzt. Das ist allerdings deutlich weniger performant als der Weg über die php.ini. Wir haben htscanner auf unseren Hosting-Servern - mangels Bedarf - in der Regel nicht vorinstalliert. Solltest du es benötigen, wende dich bitte an uns.
Du kannst zwar mittels SetEnv Umgebungsvariablen setzen; diese werden jedoch nicht an deine Scripts durchgereicht. Der Grund dafür ist, dass suEXEC nur eine definierte Liste von Umgebungsvariablen durchlässt und alle anderen sperrt. Im entsprechenden Wiki-Artikel haben wir für dich Details dazu zusammengestellt.
