Htaccess

Anwendung von .htaccess - Dateien

Weiterführende Links:

http://httpd.apache.org/docs/1.3/howto/htaccess.html

von: http://www.uni-duesseldorf.de/Service/Webmaster/htaccess.php3 Juli 2006

Referenz: Apache Manual: http://www.uni-duesseldorf.de/apache-manual/

Wozu braucht man das ?

An wen ein HTTP-Server Dokumente herausgibt, welche spezielle Verarbeitung er u.U. bei einer spezifischen Anforderung (einem request) durchführt - all das wird zunächst durch eine von der Server-Software abhängigen Konfiguration bestimmt, die ein Administrator - ein Webmaster - eingerichtet hat.

Oft ist es aber wünschenswert, daß einzelne Verantwortliche für eine Dokumentenhierarchie auf dem Web-Server selbst ohne Intervention des Webmasters Setzungen vornehmen können, daß z.B. auf einzelne Dokumente oder alle in einem bestimmten Verzeichnis nur ein Zugriff aus bestimmten Domains oder mit verifiziertem Usernamen möglich ist.

Beim Apache-HTTP-Server wie seinem Vorgänger, dem NCSA-httpd, gibt es diese Möglichkeiten durch die Einrichtung von .htaccess-Dateien in dem jeweiligen Verzeichnis. In der folgenden Darstellung wird als Referenz jeweils ein Verweis auf den entsprechenden Abschnitt in der lokale Kopie der Apache-Dokumentation für die Version 1.2 gegeben.

Achtung: In der Server-Konfiguration kann ein anderer Name als .htaccess vereinbart sein (AccesFileName-Direkt ive).

Zweiter Hinweis: Die Datei muß für den HTTP-Server lesbar sein, z.B. dadurch erreicht, daß sie öffentlich lesbar ist:

chmod 644 .htaccess 

Zugriffsbeschränkung auf eine Domain

für alle Dateien in einem Verzeichnis

.htaccess

order deny,allow
deny  from all
allow from .uni-duesseldorf.de 134.99 

Alle Dateien in dem Verzeichnis werden nur an Clients ausgeliefert, die eine IP-Adresse beginnend mit 134.99 oder einen Hostnamen endend mit uni-duesseldorf.de besitzen; anderenfalls erfolgt eine Fehlermeldung des Servers (403 Forbidden).

Natürlich genügt in vielen Fällen eine der Alternativen. Beachten Sie dabei die Unterschiede:

• Die Angabe des Domain-Namens allein schließt - bewußt oder nicht - den Zugriff von PC's aus, die nicht im Domain Name System (DNS) registriert sind.
• Die Angabe des IP-Subnetzes allein kann andere ausschließen, die organisatorisch zur gleichen Domain gehören, technisch aber in einem anderen Subnetz hängen.

Wie lässt sich diese Zugriffsbeschränkung testen? Normalerweise benötigt man dazu einen Internet-Zugang über einen anderen Provider (T-Online, AOL, Compuserve etc.). Oder man benutzt einen Browser auf dem Server selbst z.B. in folgender Weise:

lynx http://localhost/Service/Webmaster/htaccess.phtml 

Der Zugriff erfolgt dann über das Loopback-Interface mit der IP-Adresse 127.0.0.1.

Referenz: order, deny, allow.

für einzelne Dateien

.htaccess

<Files huh*.html>
order deny,allow
deny  from all
allow from .uni-duesseldorf.de 134.99
</Files>

Die Zugriffsbeschränkung wie oben gilt jetzt nur für die Dateien, deren Namen auf das hinter Files angegebene Muster passen. Es kann ein einzelner Name angegeben werden oder ein Muster mit den Wildcard-Zeichen ? für ein beliebiges einzelnes Zeichen oder * für eine beliebige Folge von Zeichen.

Schließlich sind auch feinere Muster über reguläre Ausdrücke möglich. Die Syntax der Files-Direktive dafür ist:

<Files ~ "regexp"> 

Referenz: <Files>, order, deny, allow.

Zugriffsbeschränkung über Passwort

für ein Verzeichnis

.htaccess

AuthType Basic
AuthName MeyersLeute
AuthUserFile /home/meyer/passwd
require valid-user

Dokumente in einem Verzeichnis mit dieser .htaccess-Datei (oder einem Unterverzeichnis) können erst nach Eingabe eines gültigen Benutzernamen und Passwortes gelesen werden. Der Wert hinter AuthName wird vom Browser in der Dialog-Box für die Passwortabfrage angezeigt und dient gleichzeitig dazu, andere Dokumente mit dem gleichen Schutz zu erkennen und einmal eingelesene Werte für Username und Password ohne erneute Abfrage unmittelbar zu verwenden.

Hinter AuthUserFile steht der Pfad der Passwortdatei, die die Benutzernamen und (verschlüsselten) Passwörter enthält. Sie sieht etwa so aus:

/home/meyer/passwd

meyer:xm.kPd4VJc3Fo
mueller:eJFQCL8GftDXI

Auch die Passwortdatei muß für den HTTP-Server lesbar sein. Gerade deshalb sollte sie niemals in demselben Bereich liegen wie die vom Server bedienten Dokumente, da sonst zumindest die gültigen Benutzernamen lesbar wären. (Aus diesem Grund müssen Sie aber u.U. daran denken, auch das entsprechende Verzeichnis - wie /home/meyer im Beispiel - für den HTTP-Server zumindest suchbar zu setzen, also etwa:

   chmod 711 /home/meyer 

Angelegt und gepflegt werden kann die Passwortdatei mit dem Programm htpasswd:

   htpasswd -c /home/meyer/passwd meyer
   htpasswd /home/meyer/passwd mueller 

Referenz: AuthType, AuthName, AuthUserFile, require.

für einzelne Dateien

.htaccess

AuthType Basic
AuthName MeyersLeute
AuthUserFile /home/meyer/passwd
<Files Huh*.html>
require user meyer mueller
</Files>

Die Kombination von 2. und 3. - Passwortschutz für einzelne Dateien in dem aktuellen Verzeichnis. Beim require wird hier noch eine andere Alternative gezeigt: die Aufzählung einzelner Benutzernamen aus der Passwortdatei. Wenn neue Benutzer in der Passwortdatei ergänzt werden, haben diese noch keinen Zugriff auf die so geschützten Seiten.

Wenn die gleiche Liste von Benutzern an mehreren Stellen verwendet werden soll, ist die Definition der Liste über eine Gruppendatei empfehlenswert. Für diese dritte Alternative bzgl. der require-Direktive sind fogende Änderungen notwendig:

1. In der .htaccess-Datei wird eine Gruppendatei angegeben:

AuthGrouprFile /home/meyer/groups

Für den Ort der Ablage dieser Datei gelten dieselben Erwägungen wie für die Passwortdatei oben. 2. In der require-Direktive wird jetzt auf eine Gruppendefinition in der Gruppendatei Bezug genommen:

require group meyers

3. Die Gruppendatei ist eine einfache Textdatei mit je einer Gruppendefinition pro Zeile in folgender Form:

/home/meyer/groups
meyers: meyer mueller

Referenz: AuthType, AuthName, AuthUserFile, AuthGroupFile, <Files>, require.

Spezielle Optionen

automatischer Index (Directory Listing)

ausführliche Infos hier: htaccess - Directory Listing

.htaccess

Options +Indexes

Mittels der Options-Direktive können - so von der globalen Server-Konfiguration her erlaubt - Voreinstellungen für Verarbeitungsoptionen für das aktuelle Verzeichnis und Unterverzeichnisse überschrieben werden.

Die gezeigte Variante weist den Server an, bei der Referenz auf das aktuelle Verzeichnis oder ein Unterverzeichnis ein Directory-Listing als Index-Datei automatisch zu generieren. Er macht dies allerdings nur, wenn nicht schon eine Index-Datei (mit vordefiniertem Namen wie index.html) vorhanden ist. Ggf. kann man die hier bekannten Namen mit der Direktive

   DirectoryIndex Welcome.html 

einschränken.

Referenz: Options, DirectoryIndex.

Weiterleitung mit .htaccess

Hinweis: eine Alternative hierfür ist eine PHP Weiterleitung (PHP - Tipps und Tricks) Quelle Dr.Web 28.12.2006

Sie können sowohl Zugriffe auf bestimmte Dateien als auch auf Verzeichnisse bequem weiterleiten. Das klappt innerhalb der eigenen Domain, aber auch mit externen Verweisen.

Die Datei .htaccess kann mit jedem Text-Editor bearbeitet werden. Eine Umleitung könnte so aussehen:

Redirect /beispielverzeichnis http://www.drweb.de

Ruft jemand die URL http://www.drweb.de/beispielverzeichnis auf landet er ohne weiteren Zwischenstopp direkt auf der Startseite.

Mit Einzeldateien klappt es auch:

Redirect /beispielseite.shtml http://www.drweb.de

oder

Redirect /beispielseite.shtml neueseite.shtml

Wer mag, kann die gesamte Domain auf eine andere umleiten

Redirect / http://www.drweb.de/

Nützlich während Bauarbeiten, bei Reparaturen oder wenn Dateien durch andere ersetzt wurden. Da die Umleitung serverseitig geschieht, spielt der Browser des Besuchers keine Rolle.

Weitere nützliche Beispiele:

Den Domainnamen ohne www auf den mit www umleiten. Es wird der Code 301 mitgegeben.

RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [L,R=301]

Erlaubte Anweisungen in .htaccess-Dateien

http://de.selfhtml.org/servercgi/server/htaccess.htm

Auszug (Datum des Zugriffs: 10.9.2007):

Die Anweisung AllowOverride kann nicht innerhalb einer .htaccess notiert werden, sondern wird ausschließlich vom Server-Administrator in der zentralen Konfigurationsdatei vorgegeben. Um den AllowOverride-Wert in Erfahrung zu bringen, benötigen Sie Einsicht in die Serverkonfiguration. Kontaktieren Sie dazu gegebenenfalls Ihren Webhosting-Provider. Dieser kann den Wert auch ändern, falls Sie bestimmte bisher nicht erlaubte Anweisungen verwenden möchten. Im einzelnen gibt es dafür folgende mögliche Werte:

    * Mit AllowOverride None wird der Webserver angewiesen, .htaccess-Dateien zu ignorieren. Das ist im Übrigen die Voreinstellung.
    * Mit AllowOverride All wird festgelegt, dass in einer .htaccess-Datei (so gut wie) sämtliche zentrale Vorgaben überschrieben und damit abgeändert werden dürfen. Das kann bedeuten, dass Vorhaben, die eigentlich verboten sind (beispielsweise die Ausführung von CGI-Scripts), mit Hilfe einer .htaccess-Datei erlaubt werden. Als Server-Administrator werden Sie diese Anweisung also nur sehr vorsichtig einsetzen.
    * Mit AllowOverride Options wird festgelegt, dass in einer .htaccess-Datei nach unten Anweisungen zur Steuerung spezieller Verzeichniseigenschaften zulässig sind.
    * Mit AllowOverride Limit wird festgelegt, dass in einer .htaccess-Datei nach unten Zugriffe von bestimmten Hosts erlaubt oder untersagt werden können.
    * Mit AllowOverride Indexes wird festgelegt, dass in einer .htaccess-Datei nach unten Anweisungen zur Steuerung von Verzeichnisindizes zulässig sind.
    * Mit AllowOverride FileInfo wird festgelegt, dass in einer .htaccess-Datei Anweisungen zur Akzeptanz bestimmter Dokumenttypen zulässig sind - beispielsweie, um nach unten Individuelle Fehlermeldungen ausgeben zu können.
    * Mit AllowOverride AuthConfig wird festgelegt, dass in einer .htaccess-Datei Autorisierungsanweisungen stehen dürfen - das betrifft beispielsweise Regelungen zum nach unten Passwortschutz.

Diese Werte können auch miteinander kombiniert werden. All ist der mächtigste Parameter, mit dem alles das zugelassen wird, was die anderen Parameter steuern.

Nach dem Ändern muß natürlich der Server neu gestartet werden (bei Debian: apache restart)

Moved Permanently 301 Redirect

Quelle:http://www.fladi.de/2008/04/28/howto-webseiten-redirect-mit-301/ (25.7.2008)

Was ist ein 301 redirect?

301 redirect ist die wohl beste Möglichkeit das aktuelle Suchmaschinenranking beim Umzug einer Seite oder des gesamten Webauftritts zu behalten. Der Code “301″ steht für “moved permanently” (dauerhaft verschoben). Ein solches Redirect wird in der .htaccess Datei eintragen. Es trägt die Form (alles in einer Zeile):

redirect 301 pfad/alte/seite/datei.html http://www.domain.de/pfad/neue/seite/datei.html 

Beachte, kein “http://www” in das erste Statement zu schreiben. Es muss der komplette Pfad vom Root deines Webservers angegeben werden. Schauen wir uns die Zeile nun nochmal genauer an:

   * “redirect 301″ - die eigentliche Anweisung für den Webserver
   * “/pfad/alte/seite/datei.html” - die Seite die umgeleitet werden soll
   * “http://www.domain.de/pfad/neue/seite.datei.html” - die komplette neue URL

Wie reagiert nun ein Suchmaschinen-Spider auf eine solche Umleitung? Die .htaccess wird ja nicht vom Spider ausgelesen, sondern vom Webserver “ausgeführt”. Der Spider jedoch erkennt den Statuscode, den der Webserver liefert. Beim nächsten Update seiner Datenbank sollte die Suchmaschine nun die alte URL aus dem Index werfen und die neue aufnehmen. Häufig kommt es aber auch vor, dass alte und neue URL gemischt auftauchen. Auch leichte Änderungen im Pagerank können auftreten. Es dauert so ca. 6-8 Wochen bis sich die Änderungen an der Seite auch in den Suchergebnissen niederschlagen.

Weitere Möglichkeiten von 301 redirect:

  1. Um ALLE Dateien Deiner Domain mithilfe einer .htaccess umzuleiten kannst Du (auf einem Unix/Linux-Webserver) i.d.R. folgendes verwenden:
redirect 301 ^(.*)$ http://www.domain.de
redirectMatch permanent ^(.*)$ http://www.domain.de

Um Deine alte Startseite (index.html) umzuleiten:

redirect 301 /index.html http://www.domain.de/index.html
redirect permanent /index.html http://www.domain.de/index.html

2. Wenn Du http://domain.de auf http://www.domain.de umleiten möchtest und mod_rewrite auf dem Webserver verfügbar ist, erreichst Du dies durch folgende .htaccess:

Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_HOST} ^domain\.de
RewriteRule ^(.*)$ http://www.domain.de/$1 [R=permanent,L]

oder

Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_HOST} ^domain\.de$ [NC]
RewriteRule ^(.*)$ http://www.domain.de/$1 [R=301,L]

3. Alle .html Dateien auf .php Dateien umzuleiten ist durch mod_rewrite auch kein großes Problem:

RewriteEngine on
RewriteBase /
RewriteRule (.*).html$ /$1.php

4. Um ein Verzeichnis und alles darunter umzuleiten:

redirectMatch 301 ^/verzeichnis-alt/(.*) http://www.domain.de/verzeichnis-neu/

Warum nicht per META-Tag redirect machen?

Die Umleitung per META-Tag erfolgt direkt in der aufgerufenen Seite. Dort wird im HEAD-Teil

<meta http-equiv=”refresh” content=”0; url=http://www.domain.de/”>

eingetragen. Hierbei bewirkt das “content=10″, dass der Browser nach 10 Sekunden die darauffolgende URL aufruft. Wenn man “content=0″ einträgt wird die Umleitung sofort ausgeführt. Ein paar alte Browser unterstützen diese Art der Umleitung nicht. Deshalb ist es besser noch zusätzlich den Link (neue Domain) mit anzugeben.

Technisch gesehen liefert die angefragte Seite, wie auch die Seite auf die umgeleitet wird, einen Statuscode “200 OK” zurück. Es sind also zwei unabhängige Seiten. Dementsprechend versucht die Suchmaschinen auch beide Seiten zu indizieren. Hier genau liegt aber das Problem. Denn der Spider des Suchmaschinenbetreibers erkennt die Umleitung und wertet Deine Seite deshalb u.U. ab, da es sich um eine beliebte SPAM-Methode handelt. So könnte man 1000 Domains mit solchen Seiten und jeder Menge Keywords einrichten. Echte Besucher (kein Spider) werden umgeleitet auf die eigentliche Seite. Indiziert wird aber nicht nur die eigentliche Seite sondern auch die 1000 Domains mit Keywords, die meist gar nichts mit dem eingentlichen Inhalt zu tun haben.

Beim 301 redirect wird hingegen nur die echte Zielseite in den Index aufgenommen und durch den Statuscode kann der Suchmaschinenbetreiber zusätzlich noch die veralteten Seite aus dem Index werfen. Dies ist also der beste Weg um alte Seiten auf neue umzuleiten und gleichzeitig wird auch der Page Rank mit übertragen.