Neu ist nicht was man damit machen kann sondern was man damit macht!
Gewöhnlich werden für URLs, deren Inhalte nur bestimmten Nutzern zugänglich sein sollen, eine zusätzliche Konfigurationsdatei .htaccess und eine Passwort-Datei im entsprechenden Verzeichnis angelegt:
AuthType Basic
AuthName "Geheim"
AuthUserFile /var/www/vhosts/.htpasswd
Require valid-user
Wobei die Passwortdatei, hier .htpasswd genannt, die Benutzernamen mit den dazugehörigen Passworten beinhaltet. zum Erstellen und Bearbeiten dieser Datei dient das Apache-Utility htpasswd dessen Verwendung untenstehend gezeigt ist:
c:\var>htpasswd
Usage:
htpasswd [-cmdpsD] passwordfile username
htpasswd -b[cmdpsD] passwordfile username password
htpasswd -n[mdps] username
htpasswd -nb[mdps] username password
-c Create a new file.
-n Don't update file; display results on stdout.
-m Force MD5 encryption of the password (default).
-d Force CRYPT encryption of the password.
-p Do not encrypt the password (plaintext).
-s Force SHA encryption of the password.
-b Use the password from the command line rather than prompting for it.
-D Delete the specified user.
On Windows, NetWare and TPF systems the '-m' flag is used by default.
On all other systems, the '-p' flag will probably not work.
Die Konfigurationsdatei .htaccess legt den AuthType fest, der hier in diesem Fall Basic lautet. AuthName gibt den sog. Realm an, mit diesem Namen kann der Browser die Zugangsdaten speichern sofern der Anwender das möchte. Mit dieser Konfiguration setzt der Browser beim ersten Aufruf der Seite folgende Header in die Response:
HTTP/1.1 Status 401 Authorization Required
WWW-Authenticate: Basic realm="Geheim"
Was den Browser veranlasst einen Prompt hervorzubringen, also ein modales Formular in dem der Benutzer seinen Namen und sein Passwort einzugeben hat. Sofern diese Eingabe richtig ist, sendet der Browser bei allen folgenden Requests an die Authority (Domäne) einen zusätzlichen Header Authorization: Basic dXNlcjpwYXNz wobei der Parameter die Credentials user:pass base64 kodiert. Erst nach dem Beenden und Neustart der Browsersitzung wird dieser Header nicht mehr gesendet, hierzu muss der Anwender Benutzername und Passwort erneut eingeben.
Die bisher beschriebene Konfiguration hat einige Nachteile. Zum Ersten sind zusätzliche Dateien erforderlich und eine zentrale Benutzerverwaltung, respektive Benutzergruppen ist nicht möglich. Des Weiteren erscheint der Prompt sofort in dem Moment wenn die Seite aufgerufen wird. Sollen Name und Passwort jedoch erst angefordert werden wenn der Benutzer auf einen Link zur Anmeldung klickt, müssen weitere Überlegungen angestellt werden. Zuerst muss dafür gesorgt werden, daß der vom Browser gesendete Authorization-Header in die Serverumgebung gesetzt wird, so daß ein nachfolgender Prozess Benutzername und Passwort bei jedem Request prüfen kann. Hierzu bewährt sich untenstehende Regel:
RewriteRule .* - [e=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
Damit stehen Benutzername und Passwort jedem CGI-Prozess zur Verfügung, im Klartext sind sie wie folgt erhältlich:
if( my $auth = $ENV{HTTP_AUTHORIZATION} ){
require MIME::Base64;
my ($basic, $cred) = split /\s+/, $auth;
( $ENV{HTTP_USER}, $ENV{HTTP_PASS} ) = split ":", MIME::Base64::decode_base64($cred);
}
else{
( $ENV{HTTP_USER}, $ENV{HTTP_PASS} ) = ('','');
}
Steht mit einer Anmeldung der Benutzername zur Verfügung, ist es möglich, je nach Benutzername oder Benutzergruppe bestimmte Inhalte auszuliefern oder weitere Webanwendungen bereitzustellen die dann ohne Neuanmeldung in der Browsersession verfügbar sind. Zum Beispiel kann die Routingtable erweitert werden. Und natürlich ist es auch möglich, die Routingtable komplett auzutauschen. Das heißt daß man mit HTTP-Authorization eine Zugangskontrolle vom Programmcode vollständig trennen kann! Was ja auch sinnvoll ist! Also bevor man einen Code lädt den nur ein bestimmter Benutzer ausführen darf, prüfen ob der betreffende Benutzer den Request gefeuert hat.
HTTP-Authorization umzusetzen heißt, daß man bei der Eingabe der Benutzerdaten (Credentials) auf das Formular angewiesen ist was der Browser erzeugt. Erst nachdem dieser Handshake erfolgreich abgeschlossen ist, setzt der Browser den Authorization-Header in jeden Request. Eine andere Möglichkeit besteht darin, das Eingabeformular für die Credentials selbst zu erzeugen mit den Mitteln der HTML.
Nach einer erfolgreichen serverseitigen Prüfung der Credentials wird ein Header Set-Cookie: Auth=dXNlcjpwYXNz zurückgeschickt, wobei auch hierin user:pass Base64-Kodiert ist, genauso wie in Authorization Basic. Der Browser speichert diesen Cookie für die Dauer seiner Session (Browser-Sitzung) und sendet diesen bei jedem Request an die gleiche Authority, genauso wie das in HTTP-Authorization der Fall ist. Serverseitig erhält man die Credentials zur Prüfung in der Umgebungsvariablen HTTP_COOKIE, so daß diese bei jedem Request geprüft werden können. Und natürlich ist es auch hierbei möglich, diese Prüfung vom weiteren Code weitestgehend zu trennen.
Es versteht sich von selbst, einen Secure Socket Layer (SSL) zu verwenden, also HTTPS anstelle HTTP. Mithin wird alles verschlüsselt übertragen was nicht an den URL angehängt wird, also sämtliche Header (Benutzername, Passwort) und natürlich der HTTP-Message-Body.
Rev.: 2023-06-03 13:43:57
Datenschutzerklärung: Diese Seite dient rein privaten Zwecken. Auf den für diese Domäne installierten Seiten werden grundsätzlich keine personenbezogenen Daten erhoben. Das Loggen der Zugriffe mit Ihrer Remote Adresse erfolgt beim Provider soweit das technisch erforderlich ist. sos@rolfrost.de.