![]() |
Michael Schröpl:
|
|
| |
| E-Mail: | |
|---|---|
| Homepage-URL: |
Bei Fragen zu diesem Beitrag bitte den Autor des Beitrags kontaktieren!
Jeder Webserver besitzt eine zentrale Konfiguration, in welcher der Webmaster die Eigenschaften, Dienste, Zugriffsrechte usw. seines Servers zentral beschreiben kann. Hat er eine große Anzahl von Benutzern mit unterschiedlichen Anforderungen für die von ihnen auf dem Server abgelegten Dokumente, dann kann eine solche Konfiguration jedoch schnell unübersichtlich und schwer wartbar werden.
Sehr hilfreich ist hierbei das Konzept der dezentralen Konfiguration mit Hilfe von benutzereigenen Konfigurationsdateien des NCSA-Webservers (und aller hierzu kompatiblen Webserver): Zusätzlich zur zentralen Konfiguration kann jeder Benutzer das Verhalten bei Zugriffen auf seine eigenen Seiten durch das Anlegen einer Textdatei mit dem (konfigurierbaren) Namen .htaccess selbst beeinflussen.
In einer solchen Konfigurationsdatei kann man z. B.
Außerdem kann der Webmaster in seiner zentralen Konfiguration detailliert festlegen, welche dieser vielen Möglichkeiten der benutzereigenen Konfigurationsdateien innerhalb welcher Verzeichnisbäume zur Verfügung stehen sollen und welche nicht. Die Anweisungssprache dieser Dateien ist identisch zur derjenigen in den zentralen Konfigurationsdateien - alles, was ein Benutzer lokal definieren kann, könnte auch der Webmaster in seiner zentralen Datei access.conf global definieren.
authType basic
# Schutzverfahren (Apache 1.2 kennt nur "basic")
authName Web-Bereich_der_Abteilung_'Entwicklung'
# Name des Berechtigungsbereichs)
authUserFile /home/ms/httpzugriff/benutzer.txt
# Datei für Benutzerbeschreibung (nicht im Dokumentbaum!)
authGroupFile /home/ms/httpzugriff/gruppen.txt
# Datei für Gruppenbeschreibung (nicht im Dokumentbaum!)
order deny,allow
# Genehmigungen überdecken Verbote ...
deny from all
# ... aber erst einmal alles verbieten
satisfy all
# nur Rechneradresse PLUS Benutzerkennung berechtigen zum Zugriff!
allow from 153.46.90.
# nur Rechner dieses IP-Adressenbereichs dürfen zugreifen
require group entwickler
# alle Entwickler dürfen zugreifen
require user chef sekretae
# Firmenchef und Sekretärin dürfen auch zugreifen
# (Demo: jeweils Passwort = Benutzerkennung, crypt()-salt = "IN") chef:IN3WY1lATStaY sekretae:INz8B568yvs7Y schmidt:INQaGJBu4yljQ meier:INqq3xgT4zpp6 huber:INT.EAmojNwN6 test:INnA1BztLIaac
# Liste aller Mitglieder der definierten Gruppen entwickler: meier huber schmidt
Den Zugriff auf Dokumente eines Verzeichnisses kann dessen Besitzer zunächst einmal auf Hostnamen, IP-Adressen und Präfixe dieser beiden (also IP-Netzmasken und Domains!) beschränken. Das ist ganz praktisch in einem großen Firmennetz mit mehreren Teilnetzen bzw. Subdomains, wo man Filialen, Abteilungen usw. einfach dadurch voneinander abgrenzen kann, indem man sich auf eine bestehende Netzstruktur bezieht.
Insbesondere müssen sich Besucher, die auf bestimmte Seiten zugreifen dürfen, dazu nicht explizit ausweisen - und merken ggf. gar nicht, daß diese Seiten für andere Besucher gesperrt sind.
Will man weitergehende Kontrollen verwenden, bei denen der Besucher sich beim ersten Zugriff seiner Browser-Sitzung (danach merkt sich der Webserver das Ergebnis) explizit ausweisen muß, definiert man zunächst einmal einen Berechtigungsbereich, indem man für sein Verzeichnis einen logischen Namen vergibt.
Betritt ein Besucher einen solchen Bereich, indem er eine URL innerhalb des geschützten Verzeichnisses anzusprechen versucht, dann schickt der Webserver zunächst eine Aufforderung zur Authentifizierung an den Client. Der Browser zeigt dann dem Besucher z. B. eine Dialogbox mit Eingabefeldern für Benutzerkennung und Kennwort an, in der auch der Name des Bereichs angezeigt wird, damit der Besucher erkennen kann, wofür er sich gerade ausweisen soll. Weist sich der Besucher (gemäß der definierten Berechtigungen) korrekt aus, dann darf er auf das Dokument zugreifen, andernfalls löst der Webserver einen HTTP-Fehler 403 aus.
Innerhalb seines Berechtigungsbereichs kann der Besitzer eines Verzeichnisses Genehmigungen bzw. Verbote auf Benutzer- bzw. Gruppenkennungen beziehen. Die Definition dieser Kennungen erfolgt in einer entsprechenden Benutzer- bzw. Gruppendatei: In der Benutzerdatei stehen Zeilen mit Benutzerkennung und verschlüsseltem (!) Passwort (mit der UNIX-Systemroutine crypt()), in der Gruppendatei stehen Zeilen mit Listen von Benutzern der einzelnen Gruppenkennungen.
Außerdem kann man angeben, ob der Besucher sowohl von einem berechtigten Host aus als auch mit einer gültigen Benutzerkennung auf die Seite zugreifen kann oder ob die Kombination dieser beiden Rechte für einen erfolgreichen Zugriff erforderlich ist.
Beispiel: Benutzer meier definiert den Zugriffsschutz auf die Seiten seiner Entwicklungsabteilung im IP-Netzsegment 153.46.90.*
Anwender, die eine Homepage auf einem Apache- oder kompatiblen Server haben und .htaccess verwenden können, haben deshalb noch nicht unbedingt die Möglichkeit, sich selbst Kennworte nach dem Verfahren des crypt-Befehls zu verschlüsseln. In diesem Fall können Sie den folgenden kleinen Service nutzen, um sich ein Kennwort mit crypt verschlüsseln zu lassen.
Für eigene Experimente ist der weit verbreitete, gute und kostenlose Apache-Webserver (Download unter www.apache.org) zu empfehlen, für den es neben einer schon lange existierenden UNIX-Variante seit 1998 auch eine stabile Windows32-Variante gibt.
Zu beachten ist in diesem Falle allerdings, daß die Passworte in der Benutzerdatei auf Windows im Klartext, also unverschlüsselt eingetragen werden müssen (weil Windows95 und NT dem Webserver keine crypt()-Routine zur Verfügung stellen, wie UNIX das tut).
Die Version 1.3.6 des Apache-Webservers unter Windows hat einen Fehler, der die Verwendung von Passworten grundsätzlich verhindert; in der Version 1.3.9 (seit August 1999) ist dieser Fehler behoben.
Apache-Benutzerhandbuch V1.3,
core features und Module
mod_access bzw.
mod_auth.