Htaccess
Anwendung von .htaccess - Dateien
Weiterführende Links:
https://jweiland.net/know-how/internet/htaccess-konfigurieren.html#c2756
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.
Automatischer Index mit User Auth
(Quelle Weiland s.o.) Directory Listing
Soll über einer geschützen Unterseite (z.B. fileadmin/downloads) des Internetauftritts ein Directory Listing realisiert werden, dann sollte die .htaccess wie folgt eingestellt werden:
AuthType Basic AuthName "system - " Options +Indexes IndexOptions +FancyIndexing AuthUserFile /*ihr_serverpfad/projektpfad/filadmin/downloads/.htpasswd AuthGroupFile /dev/null require valid-user
- ihr_serverpfad finden Sie in Ihrem Kundenmenu unter Technische Infos oder durch Eingabe des Befehls $PWD in der Shell.
Den User mit verschlüseltem Passwort in dem Fall in der .htpasswd vorhanden sein.
Die Unterseite mit dem Directory Listing muss von der TYPO3 index.php ausgeschlossen werden und erreichen Sie über die .htaccess in dem Projektverzeichnis mit folgenden Angaben nach der RewriteEngine On:
RewriteRule ^fileadmin/downloads/$ - [L] RewriteRule ^fileadmin/downloads/.*$ - [L]
Startdatei festlegen
Mit dem vorigen Beispiel kann man auch festlegen welche Dateien beim Aufruf eines Verzeichnisses (oder der Webadresse) an den Browser geliefert werden sollen. Manchmal hat man den Fall das die Startdatei eines CMS index.php heißt und bei Wartungsarbeiten die Datei index.html aufgerufen werden soll.
DirectoryIndex index.html index.php start.html
weist den Apache an falls vorhanden die Datei index.html aufzurufen, wenn nicht die index.php und so weiter.
Bei Wartungsarbeiten kann man nun einfach eine index.html aufspielen die bei Aufruf der Domain angezeigt wird.
PHP - Werte setzen
Wenn der Server das erlaubt kann man es folgendermaßen machen:
PHP Memory Limit
php_value memory_limit 256M
PHP Execution Time
php_value max_execution_time 240
Error Reporting
Produktiv Betrieb
(Fehler unterdrückt aber protokolliert)
php_value error_reporting 2047 php_value display_errors 0 php_value log_errors 1 php_value error_log /eigener/pfad/fehler.log
Entwicklung
hier sollte display_errors auf 1 stehen
siehe auch PHP - Error Reporting / Fehlerbehandlung
siehe auch TYPO3 - Error Reporting / Fehlerbehandlung
Skripte sperren
z.B. bei Überlastung durch ein Skript (hier im Beispiel meineDomain.de/ajax/
RewriteEngine On
RewriteCond %{REQUEST_URI} (.*)ajax(.*) [NC]
RewriteRule ^(.*) - [F]
Zugriff auf Ordner
Sperren
# This file restricts access to the fileadmin/user_upload/_import_export_ directory. It is # meant to protect temporary files which could contain sensible # information. Please do not touch. # Apache < 2.3 <IfModule !mod_authz_core.c> Order allow,deny Deny from all Satisfy All </IfModule> # Apache ≥ 2.3 <IfModule mod_authz_core.c> Require all denied </IfModule>
Weiterleitung mit .htaccess
Beispiele mit Fokus auf TYPO3
Quelle Weiland (s.o.)
Weiterleitungen (Redirects)
Die Weiterleitung von Domains und Anfragen zu einzelnen Webseiten ist eine der Hauptanwendungen der .htaccess Datei. Das notwendige Apache Modul mod_rewrite ist in unseren Hosting Tarifen vorhanden.
Die Weiterleitung muss jedoch in der .htaccess Datei zunächst mit folgendem Eintrag aktiviert werden (in den weiteren Beispielen haben wir diese Zeile weggelassen):
RewriteEngine On
301 oder 302 Weiterleitung?
Der Weiterleitung (Redirect) sollte man noch einen Statuscode mitgeben: 301 oder 302. Worin liegt der Unterschied?
301: die Weiterleitung ist dauerhaft, z.B. weil die Navigationsstruktur einer Webseite umgestellt wurde
302: die Weiterleitung erfolgt nur vorübergehend, anschließend gilt wieder die bisherige Adresse
Am Ende der RewriteRule Zeile wird der Code für die Weiterleitung (Redirect) in eckigen Klammern angegeben. Mit dem zusätzlichen Parameter L (Letzter, Last) kann man festlegen, dass die weiteren Anweisungen in der .htaccess Datei ignoriert werden sollen. Hierzu ein Beispiel:
RewriteRule ^neues\.html$ /aktuelles.html [R=301,L]
Damit wird die Seite domain.tld/neues.html dauerhaft auf domain.tlld/aktuelles.htmlweitergeleitet.
Die Schreibweise der Rewrite Regeln basiert dabei auf "Regulären Ausdrücken" (Regular Expressions, regex).
Mit den Zeichen ^ und $ wird Anfang und Ende der umzuleitenden Seite gekennzeichnet. Der Punkt . steht in regulären Ausdrücken für ein beliebiges Zeichen, wenn wir wirklich einen Punkt meinen, dann wird dies mit einem Backslash \ gekennzeichnet (\ bedeutet also: exakt das nächste Zeichen).
Besonderheit: Anker auf einer Seite
Auf einer Webseite können "Anker" als Sprungmarke gesetzt sein. Beim Aufruf wird im Browser nicht auf den Anfang der Seite sondern direkt zum Ankerpunkt gesprungen. Der Anker wird durch ein Hash-Zeichen # in der URL gefolgt vom Namen der Sprungmarke gekennzeichnet. Beispiel für eine Adresse mit Anker:
domain.tld/aktuelles.html#artikel25
Soll per .htaccess Weiterleitung direkt auf eine Sprungmarke verwiesen werden, muss der zusätzliche Parameter NE (No Encoding) in eckigen Klammern angegeben werden:
RewriteRule ^neues\.html$ /aktuelles.html#artikel25 [R=301,L,NE]
Domain auf verschlüsselte Verbindung umleiten
Sollen alle Seiten einer Domain ausschließlich über eine SSL-Verbindung aufgerufen werden, so kann dies über einen Eintrag in der .htaccess Datei im Startverzeichnis der Domain eingerichtet werden:
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}/$1 [L]
In der ersten Zeile wird die Funktion zum Umschreiben von URLs im Apache Webserver aktiviert. In der zweiten Zeile wird die Bedingung definiert "Wenn der Aufruf nicht auf Port 443 erfolgt" (Port 443 wird für SSL-Verschlüsselung verwendet, Port 80 für unverschlüsselte Aufrufe). Zeile 3 ist die Regel für das Umschreiben der URL. Wenn die Bedingung aus Zeile 2 zutrifft, werden die Aufrufe einer beliebigen Seite auf die gleiche Domain (${HTTP_HOST}) jedoch über das https:// Protokoll umgeleitet. Mit /$1 wird die ursprüngliche URL (z.B. impressum.html) an den Domainnamen angefügt. Mit dem Parameter [L] wird angegeben, dass das Umschreiben der URLs hier enden soll, weitere Zeilen in der .htaccess Datei werden also ignoriert.
Domain name-of-domain.net nach name-der-domain.de umleiten
Oftmals werden für ein Projekt mehrere Domains registriert, um verschiedene Schreibweisen abzudecken. Nach außen wird eine Hauptdomain kommunziert (Beispiel: name-der-domain.de als Hautpdomain, dazu name-of-domain.net als Zusatzdomains).
Mit folgendem Eintrag in der .htaccess Datei werden alle Aufrufe für name-of-domain.net nach name-der-domain.de weitergeleitet:
RewriteCond %{HTTP_HOST} ^(www\.)?name-of-domain\.net$ [NC]
RewriteRule ^(.*)$ http://www.name-der-domain.de/$1 [R=301,L]
Die Weiterleitung nach name-der-domain.de erfolgt dabei mit dem Statuscode 301 (permanent), so dass auch in Suchmaschinen auf Dauer nur diese erscheint. Dadurch werden Probleme mit "doppeltem Inhalt" (Duplicate Content) vermieden. Alle bei der ursprünglichen Domain übermittelten Parameter werden an die Zieldomain weitergegeben.
Einer Domain immer www. voranstellen
Mit folgendem Eintrag in der .htaccess Datei werden alle Aufrufe für eine Domain ohne www auf die Variante mit www weitergeleitet:
RewriteCond %{HTTP_HOST} ^name-der-domain\.de$ [NC]
RewriteRule ^(.*)$ http://www.name-der-domain.de/$1 [R=301,L]
Die Weiterleitung nach www.name-der-domain.de erfolgt dabei mit dem Statuscode 301 (permanent), so dass auch in Suchmaschinen auf Dauer nur diese erscheint.
Domain auf eine Seite leiten
Bestimmte Domains oder Subdomains sollen entweder mit oder ohne www auf eine bestimmte Unterseite weitergeleitet werden.
Dazu fügen Sie folgende Zeilen in Ihre .htaccess ein:
#Ohne realurl:
RewriteCond %{HTTP_HOST} ^(www\.)?name-der-domain\.de
RewriteRule ^$ /index.php?id=85
#oder realurl/simulatestatic mit html Suffix:
RewriteCond %{HTTP_HOST} ^(www\.)?name-der-domain\.de
RewriteRule ^$ /unterseite.html
#oder realurl ohne html Suffix:
RewriteCond %{HTTP_HOST} ^(www\.)?name-der-domain\.de
RewriteRule ^$ /unterseite/
Weiterleitung auf eine andere Domain zu einer Unterseite
RewriteCond %{HTTP_HOST} ^(www\.)?name-of-domain\.net [NC]
RewriteRule ^(.*)$ http://www.name-der-domain.de/unterseite.hmtl [R=301,L]
Redirect mit ? in der URL
http://www.domainname.de/index.php?id=7 soll nach
http://www.domainname.de/impressum.html umgeleitet werden. Das Problem ist das ? in der alten URL und muss per QUERY_STRING in der Condition abgefragt werden. Lösung:
RewriteCond %{QUERY_STRING} ^id=7$
RewriteRule ^.*$ http://www.domainname.de/impressum.html? [L,R=301]
Wichtig ist auch der Browser-Cache. Der sollte unbedingt geleert werden, denn wenn ein Aufruf noch im Cache drin ist kann dadurch u.U. immer auf die falsche Seite leiten.
So verhindert man, dass alte durch einen Umzug oder Neuprogrammierung nicht mehr vorhandene URLs in den Suchmaschinen zu einem schlechteren Ranking
Weitere Beispiele (älter)
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]
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.
Weiterleitung über IP
Options +FollowSymlinks
RewriteEngine on
#IP Bedingung
RewriteCond %{REMOTE_HOST} ^85\.13\.128\.137
#Zielseite erlauben
RewriteCond %{REQUEST_URI} !/ip-remote\.php$
#Umleiten
#RewriteRule ^/* http://demo.webmynet.de/ip-remote.php [R,NE,NC]
RewriteRule /(.*)$ /ip-remote.php [R=302,L]
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)
IP Adressen sperren
Manchmal ist es notwendig, bestimmte IP Adressen vom Aufruf der Webseite auszusperren, z.B. bei einem Angriffsversuch auf die Webseite. Über folgenden Eintrag in der .htaccess Datei (z.B. vor dem Eintrag 'RewriteEngine On') im Startverzeichnis der Seite lassen sich unerwünschte Besucher abweisen:
order allow,deny deny from 192.168.2.17 deny from 10.10.20.63 allow from all
Bei mehreren IP Adressen wird jede in eine eigene Zeile eingetragen. Die Einstellung gilt auch für alle Unterverzeichnisse. Wenn jemand mit einer gesperrten Adresse versucht, die Seite aufzurufen, erhält er einen 403 Fehlercode.
HTML5 Videos / bestimmte Dateitypen zulassen
Falls es in einzelnen Browsern zu Problemen beim Abspielen von per HTML5 eingebundenen Videos kommt, helfen eventuell folgende Zeilen in der .htaccess Datei im Projektverzeichnis:
AddType video/ogg .ogm AddType video/ogg .ogv AddType video/ogg .ogg AddType video/webm .webm AddType audio/webm .weba AddType video/mp4 .mp4 AddType video/x-m4v .m4v
htaccess für Typo3
http://www.typo3lexikon.de/server/htaccess.html (11/2014)
.htaccess für TYPO3
Ich möchte auf dieser Seite nicht erklären wie .htaccess-Dateien erstellt werden. Nein. Davon gibt es schon zu genüge Dokumentationen im Web:
Allgemeines zu htaccess
URLs manipulieren
Reguläre Ausdrücke
htaccess Beispiele
Auf dieser Seite geht es mehr um das Zusammenspiel von TYPO3 und htaccess-Dateien gerade in Bezug unter der Verwendung von der Extension RealUrl. In den nächsten Zeilen werde ich Euch meine htaccess-Datei in Detail näher erklären:
RewriteEngine
Mit RewriteEngine kannst Du das Modifizieren von URLs de- bzw. aktivieren. Erst wenn diese Option aktiviert ist, kannst du z.B. alle Anfragen, die an Deinen Server gesendet werden auf eine völlig andere Webseite umleiten.
RewriteEngine On
Bestimmte Verzeichnisse nicht umschreiben
Wenn Ihr RealUrl installiert habt, dann erhaltet Ihr je nach Konfiguration URLs wie
/meine-seite/kontakt/impressum.html
Dabei sind die vermeintlichen Ordner gar keine echten Ordner auf dem Server, sondern Informationen, die an die index.php weitergeleitet werden, um dann die gewünschte Seite aufrufen zu können. Was aber, wenn wir wirklich mal einen Ordner auf dem Server öffnen wollen? Dann darf dieser Name des Ordner NICHT an die index.php weitergeleitet werden. Um das zu erreichen verwende ich das Script aus der RealUrl-Dokumentation:
RewriteRule ^typo3$ - [L]
RewriteRule ^typo3/.*$ - [L]
RewriteRule ^uploads/.*$ - [L]
RewriteRule ^fileadmin/.*$ - [L]
RewriteRule ^typo3conf/.*$ - [L]
Hinweis
[L] bedeutet, dass nach dieser Umschreibung der URL keine weiteren Umschreibungen mehr ausgeführt werden.
Der Bindestrich (-) bedeutet, dass keine Umschreibung der URL stattfinden soll.
Doppelter Content
Wer von Euch seine Seite schon mal mit www.seitwert.de bewertet hat, wird bestimmt schon mal über den Eintrag bzgl. doppelten Content/Inhalt gestoßen sein. So kommt es je nach Konfiguration vor, dass eine Seite wie sfroemken.de das Gleiche anzeigt wie www.sfroemken.de. Dieses "Problem" kann sich auch negativ auf die Position in den Suchergebnissen auswirken. Aber auch das lässt sich mit Hilfe der htaccess-Datei bereinigen:
RewriteCond %{HTTP_HOST} ^sfroemken\.de$ [NC]
RewriteRule ^(.*)$ www.sfroemken.de/$1 [R=301,L]
Erklärung
%{HTTP_HOST} kann in diesem Fall sfroemken.de oder aber auch www.sfroemken.de sein. Mit RewriteCond könnt Ihr nun überprüfen, ob der HTTP_HOST mit dem Wert sfroemken.de übereinstimmt. Dank [NC] soll die Groß- und Kleinschreibung bei diesem Vergleich nicht berücksichtigt werden.
Wenn RewriteCond nun ein true zurück gibt, dann wird die Modifikation in RewriteRule ausgeführt. Alles was durch die Klammern markiert wurde, kann im zweiten Parameter mit $1 wiederverwendet werden. [R=301]: Das R steht für redirect und die 301 ist ein bestimmter Servercode, mit dem bestimmt wird, dass es sich bei dieser Weiterleitung um eine parmanente Weiterleitung handelt.
So wird aus
sfroemken.de/kontakt/index.php
ein
www.sfroemken.de/kontakt/index.php
Subdomains
Bei Subdomains müssen wir das genau andersrum machen. Dort gibt es kein www. Da www.seitwert.de aber trotzdem überprüft, ob die Domain auch mit einem www davor erreichbar ist, müssen wir das folgendermaßen abfangen:
RewriteCond %{HTTP_HOST} ^www\.typo3\.sfroemken\.de$ [NC]
RewriteRule ^(.*)$ typo3.sfroemken.de/$1 [R=301,L]
Ordner
Leider haben sich viele Surfer daran gewöhnt Ordner auf einem Server ohne abschließendem Slash (/) anzugeben. Damit dieser Slash automatisch hinten dran gemacht wird, können wir folgendes Script verwenden:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule (.*[^/])$ %{HTTP_HOST}/$1/ [L,R]
Erklärung
Die ersten beiden RewriteCond fragen ab, ob es sich bei der aufzurufenden URL nicht um eine Datei handelt und nicht um einen symbolischen Link. Wenn beides zutrifft, kann getrost ein zusätzlicher Slash hinten angefügt werden.
Achtung
Wenn Ihr RealUrl so konfiguriert habt, dass Ihr URLs wie
/kontakt/impressum.html
erhaltet, dann muss das Script noch etwas angepasst werden, dann ansonsten erhaltet Ihr eine URL wie diese hier:
/kontakt/impressum.html/
Hier das angepasste Script:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REQUEST_FILENAME} (^.htm$|^.html$)
RewriteRule (.*[^/])$ %{HTTP_HOST}/$1/ [L,R]
Heißt: Wenn die URL mit .htm oder .html endet, dann soll der zusätzliche Slash NICHT hinten dran gemacht werden.
Index-Dateien in Ordnern
Je nach Projekt und Ordner kann es vorkommen, dass Du trotz RealUrl die Index-Dateien in bestimmten Ordnern ausführen möchtest:
/fileadmin/projekt/download/index.php
Allerdings wird derzeit noch diese URL an die TYPO3-eigene index.php im Rootverzeichnis weitergeleitet. Um auch das zu unterbinden sind folgende 6 Zeilen vorgesehen:
RewriteCond %{REQUEST_FILENAME}/index.html -f
RewriteRule / %{REQUEST_URI}/index.html [L]
RewriteCond %{REQUEST_FILENAME}/index.htm -f
RewriteRule / %{REQUEST_URI}/index.htm [L]
RewriteCond %{REQUEST_FILENAME}/index.php -f
RewriteRule / %{REQUEST_URI}/index.php [L]
URL-Modifikation für RealUrl
Dieses Script ist das wichtigste Script überhaupt für RealUrl. Hier wird nun endlich gesagt, dass alle Teile aus der URL an die TYPO3-eigene index.php weitergeleitet werden sollen zur Weiterverarbeitung durch RealUrl.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* index.php
Hinweis
Je nach Art Eurer TYPO3-Installation könnte es sein, dass Eure index.php ein symbolischer Link ist. In diesem Fall müsst Ihr die letzt Zeile folgendermaßen ändern:
RewriteRule .* /index.php
Scripmerger
Dieses Script benötigt Ihr nur, wenn Ihr die Extension scriptmerger verwenden wollt:
# Expires Header + Removal of ETag
<FilesMatch "\.(ico|png|gif|js|css|jpg|jpeg|swf)">
<IfModule mod_expires.c>
ExpiresActive on
ExpiresDefault "access plus 7 days"
ExpiresDefault "access plus 2 months"
</IfModule>
# ETag
FileETag MTime Size
<IfModule mod_headers.c>
FileETag none
Header unset Last-Modified
</IfModule>
</FilesMatch>
# Compressed Content
<FilesMatch "\.gz\.(js|css)">
<IfModule mod_headers.c>
Header set Content-Encoding gzip
</IfModule>
</FilesMatch>
Shell Restriction auf all-inkl Server
Ab TYPO3 6 moniert das Install Tool das exec nicht augeführt werden darf. Es funktioniert wenn man die cgi Version von PHP nimmt. Das kann man per htaccess oder im KAS Backend einstellen.
Beispiele.
AddHandler php55-cgi .php (sofern vom Server unterstützt) AddHandler php54-cgi .php (sofern vom Server unterstützt) AddHandler php53-cgi .php AddHandler php52-cgi .php AddHandler php5-cgi .php (Version entsprechend der PHP Apache-Modul Version)
