Webserver/htaccess/FAQ

Aus SELFHTML-Wiki
Wechseln zu: Navigation, Suche

Auf dieser Seite sind einige häufig wiederkehrende Fragen zum Thema .htaccess mit den (hoffentlich) hilfreichen Antworten gesammelt.

Inhaltsverzeichnis

[Bearbeiten] Wie heißt eigentlich die .htaccess-Datei?

Ganz allgemein gesagt: So, wie der Webmaster sie in der Direktive AccessFileName genannt hat. Vielleicht ist es gar nicht erwünscht, dass der Name einer so wichtigen Datei mit einem Punkt beginnt, also bei bestimmten Verzeichnislisten auf UNIX-Servern ggf. gar nicht angezeigt wird, wenn man etwa beim UNIX-Kommando ls nicht explizit den Operand -a angibt (wie das manche FTP-Clients tun).

.htaccess ist lediglich der voreingestellte Defaultwert in der Apache-Konfiguration.

[Bearbeiten] Geht das auch auf meiner Homepage?

Das kommt auf die Konfiguration des Webservers an.

Das Konzept von .htaccess bedeutet, dass der Webmaster einen Teil seiner Kontrollmöglichkeiten an einen Benutzer abtritt. Bei den Massenanbietern von Homepages ist generell kaum zu erwarten, dass sie dazu bereit sind - und sei es nur aus Angst, einem Benutzer versehentlich das Recht zu geben, etwas zu tun, was ihren Betrieb mit tausenden von Homepages lahmlegen könnte.

Der Webmaster müsste auf jeden Fall wissen, was er tut - oder er müsste dem Anwender vertrauen. Deshalb wird eine Fähigkeit wie .htaccess vermutlich nur in den etwas teureren Paketen an Web-Speicher enthalten sein - was schade ist, denn wenn man das als Webmaster einmal richtig eingerichtet hat, könnten tausende von Benutzern davon profitieren.

Da bei bestimmten Einstellungen der Server-Konfiguration automatisch .htaccess-Dateien in übergeordneten Verzeichnissen mit geprüft werden müssen, könnte das Ganze bei wirklich hohen Zugriffszahlen auch eine Performance-Frage werden. Auch hier ist der Server für den Massenbetrieb der wahrscheinlichste Kandidat dafür, so eine Fähigkeit nicht anzubieten.

Falls der Provider tatsächlich einen solchen Service anbietet, dann sollte er auch angeben, welche der vielen features von .htaccess er freigeschaltet hat.

Abschließend ist ggf. noch zu beachten, dass der Name .htaccess in der Konfiguration des Webservers einstellbar ist. Im Zweifelsfalle also den Provider nach dem Namen der Datei fragen.

[Bearbeiten] Fragen zur Zugriffskontrolle

  • Kann ich Besucher von verschiedenen IP-Adressen unterschiedlich behandeln?
  • Wie kann der Webserver eigentlich diese per crypt() verschlüsselten Passworte wieder entschlüssen?
  • Kann ich den Fragetext des vom Browser angezeigten Authentifizierung-Dialogs beeinflussen?


[Bearbeiten] Wie kann der Webmaster in seiner Konfiguration features zur Verwendung in .htaccess freischalten?

Das Kommando der (als Beispiel verwendeten) Apache-Konfiguration, welches den Funktionsumfang einer .htaccess-Datei regelt, heißt AllowOverride. Hierbei kann der Webmaster eine beliebige Teilmenge der folgenden Schlüsselworte angeben. Jedes Schlüsselwort schaltet die gesamte Gruppe an Rechten für die Verwendung in .htaccess-Dateien frei.

Da das Kommando zur Definition der Rechte eines URL-Baums gehört, kann man in verschiedenen URL-Bäumen problemlos unterschiedlich viele .htaccess-Rechte für seine Anwender freischalten.

AuthConfig

  • Definition einer Berechtigungsstruktur, wie im Artikel beschrieben (Definition von Realms, Benutzer- und Passwortdateien sowie Anforderungen für die Authentifizierung). Bewirkt erst zusammen mit Limit die gewünschten Mechanismen.

FileInfo

  • Eigene Definition von MIME-Typen und deren Abbildungen auf Datei-Endungen,
  • bedingte Verwendung sprachspezifischer Varianten von HTML-Dokumenten,
  • Definition von Dokumenten als Reaktion auf http-Fehlercodes.
  • Natürlich wäre CGI-Fähigkeit gerade im Zusammenhang mit der Definition von Fehlerdokumenten schön, weil man dann über eine CGI-Anwendung die entsprechenden Zugriffe protokollieren lassen könnte ... aber statt dessen kann der Provider dem Anwender auch einen Auszug aus den zentralen Log-Dateien anbieten, was ihm die Vergabe des (gefährlichen) CGI-Rechtes erspart.

Indexes

  • Feineinstellung für intelligentes directory browsing, falls solches erlaubt ist:
  • selbst definierbare Icons für Dateitypen
  • eigene Beschreibungstexte für MIME-Typen
  • Definition des Namens der Indexdatei (index.html etc.)
  • automatische Kopf- und Fußzeilen-Includedateien für directory-browsing
  • Liste von nicht anzuzeigenden Dateien (regular expressions!)

Mit geeigneten Einstellungen kann man ganz ohne eigene HTML-Dokumente eine halbwegs komfortable Navigationsfunktion allein über die directory-browsing-Funktion des Webservers organisieren, die dennoch individuell aussieht.

Limit

  • Zugangskontrolle, wie im Artikel beschrieben (Freigabe der Kommandos allow, deny und order).
  • Limit alleine ohne AuthConfig erlaubt die Zugangsbeschränkung auf Verzeichnisse nur anhand von durch den Webmaster vordefinierten Rechtestrukturen, nicht aber z. B. die Definition eigener Benutzerkennungen.

Options

  • XBitHack - damit kann man eine Art selbstprogrammierbarer Variante von SSI erzeugen
  • Options - damit kann man Optionen für das Verhalten des Verzeichnisses setzen, und zwar:
  • Indexes - erlaubt die Verwendung oder Abschaltung von directory browsing (ansonsten gilt einfach die zentrale Voreinstellung des Servers).
  • ExecCGI - erlaubt die Definition eigener CGI-Verzeichnisse.
  • Includes - erlaubt die Verwendung oder Abschaltung von Server Side Includes im vollen Umfang (inklusive ExecCGI!).
  • IncludesNoCGI- erlaubt die Verwendung oder Abschaltung von Server Side Includes im beschränktem Umfang (ohne ExecCGI!).
  • MultiViews - erlaubt die Verwendung oder Abschaltung von dynamischen sprachabhänigen Dokumenten.
  • SymLinks - erlaubt die Verwendung von symbolic links als Verweise auf Dokumente in anderen Verzeichnissen. Elegant, falls man auf Objekte zeigen will, die außerhalb des URL-Baums liegen (z. B. Protokolldateien des Webservers), unterläuft aber damit ggf. bewusst das Verbergen solcher Objekte durch eben diesen URL-Baum.
  • SymLinksIfOwnerMatch - eingeschränkte Version, erlaubt nur den Verweis auf Objekte derselben Benutzerkennung. Das hier ist die Einstellung, bei welcher der Webmaster wirklich aufpassen muss und besser erst mal nur die entsprechenden Rechte in seiner zentralen Konfiguration definieren sollte (IncludesNoCGI für sich genommen ist ungefährlich und sehr nützlich!).

Wenn man einem Benutzer erlaubt, diese Optionen selbst zu setzen, dann kann dieser alles aus dieser Liste selbst einstellen! Das ist sehr schade, denn es verhindert auch die Freigabe der ungefährlichen Rechte an alle Benutzer (etwa die Entscheidung, ob man directory browsing will oder nicht) und zwingt den Webmaster dazu, dies in seiner zentralen Konfiguration ggf. für verschiedene Benutzer selbst unterschiedlich zu definieren.

[Bearbeiten] Kann man damit auch CGI-Anwendungen schützen?

Grundsätzlich schon, allerdings ist die Standardserverkonfiguration des Apache so eingestellt, dass cgi-bin nicht durch .htaccess beeinflussbar ist. Falls es Probleme dabei gibt (insbesondere 500 Internal Server Error oder Ausbleiben der Funktionalität), sollte man seinen Provider darauf ansprechen.

[Bearbeiten] Wie kann eine CGI-Anwendung die Authentifikation eines Benutzers auswerten?

In der CGI-Spezifikation ist eine Environment-Variable REMOTE_USER beschrieben, welche die Benutzerkennung einer Authentifizierung der entsprechenden Realm speichern soll. Über diese Variable lässt sich z. B. der Name eines Benutzers protokollieren usw. Hat sich der Anwender nirgendwo anmelden müssen, um auf die URL der CGI-Anwendung zuzugreifen, dann ist der Inhalt dieser Variable natürlich leer.

Der Apache-Webserver hält sich an diese Spezifikation. Leider aber lehrt die Erfahrung, dass sich keineswegs alle Webserver strikt an die CGI-Spezifikation halten. Der Webserver WebSite1.1 für Windows32 nennt diese Variable beispielsweise AUTH_USER! Da hilft im Zweifelsfalle nur, ein CGI-Skript zur Ausgabe sämtlicher CGI-Variablen zu installieren und nachzusehen - oder über die CGI-Variable SERVER_SOFTWARE den Namen des Webservers abzufragen, um herauszufinden, welche Environment-Variable man abfragen muss ...

Hat sich ein Anwender innerhalb eines realms erfolgreich angemeldet, dann bleibt ihm seine Identität für die Dauer seiner Browser-Sitzung erhalten - sofern er diese nicht bewusst ändert. Wie kann man seine Identität ändern? Indem man auf eine URL desselben realms zugreift, für welche die bisherige Identität kein Zugriffsrecht hat. In diesem Moment wird wieder der ursprüngliche Authentifizierungsdialog gestartet, und der Anwender kann nun eine andere Benutzerkennung und ein passendes Kennwort eingeben - sofern er solches besitzt. In diesem Moment verliert er seine alte Identität - greift er also wieder auf die ursprüngliche URL zu, erfolgt erneut ein Authentifizierungsdialog ...

Meine Werkzeuge
Namensräume

Varianten
Aktionen
Übersicht
Index
Mitmachen
Werkzeuge
Spenden
SELFHTML