.htaccess – Dateien sind kleine Webserver-Konfigurationsdateien, die einige sehr nützliche Features mitbringen.
Auf die meiner Meinung nach nützlichsten Tricks und Kniffe mit dieser Datei gehe ich in dieser Kurzabhandlung ein.
1) .htaccess erstellen
htaccess erstellen
Das erste Problem kommt postwendend: Wie erstellt man eine .htaccess-Datei? Da Windows keine Dateinamen zulässt,
die mit einem Punkt beginnen, hat man 2 Möglichkeiten: Entweder man erstellt die Datei unter htaccess.txt,
lädt sie auf den FTP-Server und benennt sie da erst in .htaccess um, oder man verwendet einen „besseren“ Texteditor
wie Notepad++,
erstellt ein neues Dokument und speichert dieses unter .htaccess, was dann komischerweise auch von Windows toleriert wird.
2) Was es zu beachten gilt
Fehler 500
.htaccess-Dateien müssen zu 100% korrekt geschrieben sein, denn sonst lacht euch ein Fehler 500 (siehe rechts) an,
der den Seitenzugriff auf den kompletten Server verhindert –
Also vorsichtig sein und lieber erstmal „lokal“ experimentieren oder die .htaccess in einem
Unterverzeichnis ausprobieren. Das bringt uns auch gleich zum nächsten Punkt: In der Wurzel erstellte .htaccess-Dateien (also etwa http://basti1012.de/.htaccess) haben
Gültigkeit über den kompletten Webserver einschließlich aller Unterverzeichnisse, wohingegen eine .htaccess in
einem Unterordner (also etwa https://basti1012.de/subfolder/.htaccess) nur auf diesen Unterordner und Unterordner
dieses Ordners (wie z.B. https://d-mueller.de/subfolder/weitererSubfolder/) hat
3) Webserver-Ansicht
Dateinamensübersicht
Jetzt geht’s auch schon los: Wenn Ihr ein Verzeichnis per Browser aufruft und keinen
Dateinamen angebt (also bspw. http://basti1012.de/verzeichnis/), so wird automatisch nach der index.php oder
index.html gesucht. Wenn es diese nicht geben sollte, heißt es
Forbidden – You don’t have permission to access /verzeichnis/ on this server..
Soll jetzt aber eine Dateiauflistung nach dem Schema des Screenshots auf der linken Seite erscheinen,
muss foldender Code in die .htaccess
Options +Indexes
DirectoryIndex index.html
Dies weißt den Webserver dazu an, eine index.html zu erstellen, die alle Dateien in diesem Unterverzeichnis anzeigt.
Vorsicht: Wie unter 2) Was es zu beachten gilt erwähnt, gilt dies auch für alle Unterordner. Bedenkt,
dass solch eine Option beachtliche Sicherherheitsrisiken mit sich bringen kann.
4) Alternative Fehler-404-Seite
Fehler 404
Die Standardseite für nicht gefundene Dateien ist nicht die hübscheste und die „Absprungrate“ der
Besucher dürfte wohl nah an 100% liegen. Wenn ihr jetzt allerdings eine eigene Seite erstellt,
die interessante News und andere „Ausweichdokumente“ anbietet, die die Aufmerksamkeit des Besuchers erregen,
ist die Chance wesentlich höher, keinen Besucher zu verlieren. Bei Webshops beispielsweise würde sich ein „Diese Artikel könnten Sie
interessieren“-Script anbieten, um die Aufmerksamkeit gleich wieder zu bekommen. Diese Codezeile macht’s möglich:
ErrorDocument 404 /fehler404.php
So würde der Benutzer nach dem vergeblichen Besuchen von https://gibt-es-nicht.de/gibtsnicht.htm auf http://basti1012.de/fehler404.php
weitergeleitet werden – geht natürlich auch mit Unterverzeichnissen.
5) PHP Fehler-Einstellungen
PHP Errorlog
PHP kann sehr offenherzig sein und durch großzügig detaillierte Fehlermeldungen zwar einerseits dem Admin bei der Fehlersuche
merklich unter die Arme greifen, allerdings auch potentiellen Störenfrieden einen tiefen Einblick in die logischer Struktur der
Website geben und damit die Chance für einen erfolgreichen Angriff erhöhen.
Mit der Fehlermeldung
Warning: mysql_connect()
[function.mysql-connect]: Access denied for user 'zugangsName'@'localhost' (using password: YES) in D:\xampp\htdocs\index.php on line 2
hätte man als „Interessent“ zumindest schonmal den Name für den Datenbank-Zugriff.
Zwar könnte man jetzt per PHP die Ausgabe der Fehlermeldung im Script unterdrücken, allerdings ist das unsauber,
unprofessionell und ihr habt keine Chance zum Debuggen, da ihr vom Fehler ja garnichts mitbekommt. Besser ist da das
komplette Ausschalten der PHP-Fehlermeldungen und das gleichzeitige Erstellen eines Error-Logs.
Folgender .htaccess-Code machts möglich:
php_flag display_errors off
php_flag log_errors on
php_value track_errors on
php_value error_log D:/xampp/htdocs/test/phperr.log
Dabei entspricht der in der letzten Zeile angegebene Pfad dem absoluten Pfad zu eurem Server,
zu erfahren per
<?php phpinfo(); ?>
und da unter „open_basedir“ oder per
<?php echo $_SERVER['DOCUMENT_ROOT']; ?>
Damit wird eine automatische Logdatei erstellt, die ihr regelmäßig einsehen solltet.
6) Verändern der PHP-Konfiguration
Gerade bei Shared-Hostern habt ihr oft keinen Zugriff auf die php.ini, in der alle Konfigurationsmöglichkeiten
festgeschrieben sind. Wenn euer Hoster kulant ist, habt ihr zwar vielleicht die Chance, dass jemand für euch die gewünschten Einstellunegn
an der php.ini vornimmt, allerdings gelten diese dann auch immer global für den kompletten Webserver. Gesetzt den Fall,
ihr habt verschiedene Web-Projekte, welche jeweils verschiedene Konfigurationen von PHP voraussetzen, ist die .htaccess wieder das
mittel zur Wahl:
php_flag magic_quotes_gpc off
php_flag register_globals off
So könnt ihr wieder recht einfach für jedes Subverzeichnis eigene Regeln bestimmen und „unmögliche“ Servereinstellungen
korrigieren, wie sie oft der Fall sind.
7) Zeichensatzoptionen
Weiterhin ist es möglich, den Standard-Zeichensatz für alle Dokumente einer bestimmten Endung zu definieren. Hier nur kurz den Code,
eine ausführlichere Beschreibung gibt es im UTF8-Tutorial unter 5) Der Webserver
Ein recht komplexes Thema, welches ich auch noch kurz anschneiden möchte, ist der Verzeichnisschutz mittels .htaccess.
Wenn ihr keine Lust auf das Schreiben komplexer Login-Scripte mit PHP habt, nur weil ihr vorübergehend ein geschütztes Verzeichnis
auf eurem Webserver braucht, ist .htaccess mal wieder eure Wahl. Es lassen sich hier ganze Usergruppen definieren, welchen man die
Befugnis auf verschiedene Dateien und Ordner gestatten oder verbieten kann. Erstmal etwas Beispielcode:
AuthUserFile /www/htdocs/w009d060/.htusers
AuthName "geheimer Bereich"
AuthType Basic
Satisfy Any
<Limit GET POST>
order deny,allow
deny from all
allow from 85.13.131.206
Require valid-user
</Limit>
Und nun im Einzelnen:
AuthUserFile definiert den absoluten Pfad zur Datei .htusers,
in der die berechtigten User mit ihrem Passwort angegeben sind. Die Syntax dieser Datei ist
dabeiBenutzername:verschluesseltes Passwort – Einen Generator zum verschlüsseln der Passwörter
sowie nähere Informationen zur Gruppenzugangsberechtigung findet ihr
bei sefthtml. Die tolle Sache mit der .htusers
ist, dass ihr mit dem einmaligen Erstellen und Anlegen dieser Datei in der Wurzel des Webservers bequem mehrere Verzeichnisse schützen könnt,
indem ihr die immergleiche .htaccess in alle zu schützenden Unterordner schiebt. Dies ist sehr nützlich, wenn der Zugriff auf die
Seite selbst (also https://d-mueller.de) gestattet sein soll, der Zugriff auf „private Unterverzeichnisse“ wie bspw.
https://basti1012.de/geheim/ nicht gestattet werden soll. In diesem Fall wäre dann einfach eine .htaccess nach oben definiertem
Schema in alle zu beschützenden Unterverzeichnisse zu schieben.
AuthName erscheint in der Passwort-Eingabebox als Name der Seite (siehe Screenshot). Dieser Parameter ist
optional und wird standardmäßig byPassword genannt, wenn ihr ihn nicht setzt.
AuthType definiert, ob die Übertragunsart des Usernamens und des Passworts. Basic ist unverschlüsselt,
Digest ist verschlüsselt, macht das ganze aber um einiges komplizierter.
Satisfy gibt an, ob alle geforderten Zugangsbedingungen (per Standard auf All) oder nur eine der
Bedingungungen (Any) erfüllt sein muss. Zu den Bedingungen dann später.
<Limit GET POST> definiert die Beschränkung des Zugriffs für alle Operationen, also Senden
an die Seite (POST) und Empfangen von Informationen von der Seite (GET).
Eine Alternative zu LIMIT ist das auch sehr nützliche FilesMatch, welches nach folgender Syntax den Zugriff
auf Dateien per Regular Expression genehmigt und verbietet.
Beispielsyntax:
<FilesMatch "^file.(css|php)$"> </FilesMatch>
(statt
<Limit GET POST> [...] </Limit>
)
würde als Filter nicht den Zugriff auf ALLE Dateien, sondern nur den Zugriff auf die Dateien file.php sowie
file.css mit den eingeschlossenen Angaben regulieren. Detailliertere Konfigurationsmöglichkeiten für den doch sehr mächtigen
FilesMatch-Parameter gibt es hier.
order deny,allow gibt die Reihenfolge der Abarbeitung von Erlaubnis und Verbot an. In der Reihenfolge deny,allow
wird erstmal pauschal alles verboten, es sei denn die nachfolgenden Bedingungen werden alle (Satisfy All)
oder zumindest eine (Satisfy Any) erfüllt. In der Reihenfolge allow,deny wird pauschal erstmal der Zugriff erstmal
erlaubt,es sei denn die nachfolgenden Bedingungen werden nicht erfüllt (siehe wieder Satisfy).
Zu diesem Bedinungen im nächsten Punkt.
allow from ermöglicht die Eingabe einer IP-Adresse, von der aus der Zugriff immer gestattet ist. Beachtet hierbei jedoch,
dass die IP normalerweise bei jeder neuen Verbindung ins Internet eine andere ist.
Require valid-user besagt, dass eine gültige Kombination aus Passwort und Benutzername aus der .htusers angegeben
muss, um den Zugriff zu gestatten. Alternativ lassen sich hier auch durch Leerzeichen getrennt berechtigte User aus der .htusers angeben,
wenn z.B. nicht jeder User der in der .htusers angegeben ist, Zugriff erhalten soll. Beispiel:Require stefan
david paula
Wer genau hat also mit dem obigen Beispielcode Zugriff auf die Seite? Es ist ja Satisfy Any gesetzt, also muss nur
eine der beiden geforderten Bedingungen (entweder ist die IP des Besuchers korrekt oder der Besucher gibt ein gültiges
Passwort ein) zutreffen, um Zugang zu erhalten. Wäre jetzt hier Satisfy All gefordert, würde eine Und-Verknüpfung
greifen und der Zugriffswillige müsste die korrekte IP und ein korrektes Passwort eingeben – doppelt
gemoppelt quasi ;).
9) Weiterleitungen
Ein weiteres großes Einsatzgebiet für .htaccess-Dateien ist die Weiterleitung
(Stichwort: mod rewrite). Ein paar sinnvolle, nützliche Anwendungsbeispiele werde ich hier aufzählen.
Ganze Website umleiten
Wenn ihr mehrere Domains verschiedener Schreibweise habt (also bspw. http://www.mein-name.de und http://www.meinname.de),
bietet es sich an, die eine auf die andere weiterleiten zu lassen. Dies mit PHP-Codes wie etwa
zu realisieren, ist immer aufwendig und google könnte in der Bewertung und Indizierung der Seite auch etwas dagegen haben.
Deswegen empfiehlt sich eine Umleitung per .htaccess. Syntax:
Redirect / http://www.meinname.de/
Dieser Code leitet alle Anfragen an die neue Domain weiter, sodass http://www.mein-name.de/unterordner/datei.htm
elegant auf http://www.meinname.de/unterordner/datei.htm verweist.
Doppelten Content vermeiden
Google hat ebenfalls etwas gegen doppelten Inhalt einzuwenden, also wenn eure Domain (wie das meistens der Fall ist) unter
http://www.euername.deundhttp://euername.de zu erreichen ist, existiert die
Seite quasi 2mal, was die Bedeutung der Seite im Google-Index evtl. herabsetzt. Um eure Seite nur auf eine Art und Weise aufrufen zu
können, hilft ein htaccess-Schnippsel wieder weiter. Diesmal bedienen wir uns des oben angesprochenen Plugins
mod rewrite, welches auf dem Großteil der Server bereits vorinstalliert ist. Falls ihr nicht sicher seid, steht
hier,
wie man testet, ob mod rewrite an ist oder nicht.
RewriteEngine On
RewriteCond %{HTTP_Host} ^d-mueller\.de$ [NC]
RewriteRule ^(.*)$ https://d-mueller.de/$1 [R=301,L]
Damit landen alle Anfragen (ob nun mit www. oder ohne) bei der www-Variante der Domain. Gleichzeitig
wird der Statuscode 301 gesetzt, was soviel wie moved permanentlybedeutet.
weiteres Mod-Rewrite Beispiel
Der Vollständigkeit halber sei noch ein Weiterleitungs-Beispiel mit mod rewrite angebracht,
welches „statische“ URL’s suggeriert, obwohl im Hintergrund ein PHP-Script arbeitet.
Die Bedeutung von statischen URL’s ist bei google höher gewichtet, außerdem gibt man einen weniger
tiefen Einblick in die Dateistruktur der Website und die URL’s sind leichter zu merken.
RewriteEngine On
RewriteBase /meineWebanwendung/
RewriteRule ^profil/([0-9]+)/$ showUserProfile.php?userid=$1
Die RewriteBase definiert das Unterverzeichnis auf dem Server,
für das die Regel gilt. Ob die .htaccess in der Wurzel oder im Unterverzeichnis selbst liegt,
ist hierbei unbedeutend, die .htaccess könnte also im Unterordner /meineWebanwendung/ oder in der Wurzel selbst liegen.
Erreicht wird eine Weiterleitung von http://www.domain.com/meineWebanwendung/profil/3/ auf
http://www.domain.com/meineWebanwendung/showUserProfile.php?userid=3.
So kann wird also im „Hintergrund“ konventionell die verarbeitende .php-Datei angesteuert, obwohl
der Benutzer o.g. „wohlgeformte“ URL besucht. Die Wildcard ist hierbei auf Zahlen beschränkt,
sodass nur Zahlen in der URL zu beschriebener Weiterleitung führen. Weitere Anwendungsbeispiele für mod rewrite gibt es
hier
Ende
Abschließend sei darauf hingewiesen, dass sich alle hier aufgeführten htaccess-Konfigurationsmöglichkeiten
beliebig miteinander kombinieren lassen.
These terms and conditions contain rules about posting comments. By submitting a comment, you are declaring that you agree with these rules:
Although the administrator will attempt to moderate comments, it is impossible for every comment to have been moderated at any given time.
You acknowledge that all comments express the views and opinions of the original author and not those of the administrator.
You agree not to post any material which is knowingly false, obscene, hateful, threatening, harassing or invasive of a person's privacy.
The administrator has the right to edit, move or remove any comment for any reason and without notice.
Failure to comply with these rules may result in being banned from submitting further comments.
These terms and conditions are subject to change at any time and without notice.
{"commentics_url":"\/\/basti1012.de\/commentics-3.4\/upload\/","page_id":28527,"enabled_country":false,"country_id":0,"enabled_state":false,"state_id":0,"enabled_upload":true,"maximum_upload_amount":1,"maximum_upload_size":1,"maximum_upload_total":5,"securimage":false,"securimage_url":"\/\/basti1012.de\/commentics-3.4\/upload\/3rdparty\/securimage\/securimage_show.php?namespace=cmtx_28527","cmtx_wait_for_comment":"cmtx_wait_for_comment","lang_error_file_num":"A maximum of %d files are allowed to be uploaded","lang_error_file_size":"Please upload files no bigger than %d MB in size","lang_error_file_total":"The total size of all files must be less than %d MB","lang_error_file_type":"Only image file types are allowed to be uploaded","lang_text_loading":"Loading ..","lang_placeholder_country":"Country","lang_placeholder_state":"State","lang_text_country_first":"Please select a country first","lang_button_submit":"Add Comment","lang_button_preview":"Preview","lang_button_remove":"Remove","lang_button_processing":"Please Wait.."}
Comments