Warum kein htaccess Auth Header per CGI?

[Andreas Korthaus]

Hallo!

Welche Möglichkeiten gibt es, einen .htaccess Schutz zu nutzen,
OHNE das vom Browser generierte Abfragefenster für User und Pass
zu nutzen.

Was genau meinst Du mit ".htaccess-Schutz"? .htaccess_Dateien sind lediglich Konfigurations-Dateien, mit denen man unter anderem (!) Verzeichnisse per Basic Authentication (mod_auth) schützen kann. Dieser Mechanismus ist in der HTTP-Spezifikation verankert(s.u.) und funktioniert eben nur mit diesen browserspezifischen Abfragefenstern.

Die HTTP Basic Authentifizierung läuft möglicherweise etwas anders ab als Du Dir vorstellst. Der Server kann lediglich eine Aufforderung an den Client schicken, dass dieser Zugangsdaten eingeben soll (401-Header). Entsprechend implementieren die Browser dieses typische Popup, in das die Zugangsdaten eingegeben werden können. Diese Daten werden im HTTP-Header zurück an den Server geschickt, und dieser kann dann prüfen, ob die Daten korrekt sind. Das kann dann entweder mit einer Passwortdatei wie üblicherweise per .htaccess passieren, oder auch anders, wie z.B. mit PHP, wenn es als Modul in den Server integriert ist, und somit Zugriff auf den kompletten HTTP-Header des Clients hat.

Wenn die Kontrolle der Zugangsdaten dann erfolgreich verlaufen ist, schickt der Server nichts an den Client, er liefert lediglich die gewünschte Seite aus. Wenn die Kontrolle nicht erfolgreich war, schickt er eine Fehlermeldung.

Es kommt keine Verbindung zwischen Client und Server zu Stande, wie man vermuten könnte. HTTP kennt keinen Zustand (es gibt kein "eingeloggt", wie z.B. bei SSH). Es gibt lediglich eine Empfehlung in der HTTP-Spezifikation, dass der HTTP-Client beim nächsten Request auf eine Resource im selben Verzeichnis davon ausgehen soll, dass hier ebenfalls derselbe Authentifizierungs-Mechanismus verwendet werden soll. Entsprechend sollen die Clients sich die einmalig eingegebenen Zugangsdaten merken, und automatisch auch bei Requests auf andere Resourcen in diesem Verzeichnis im HTTP-Client mitsenden. Die Prüfung der Zugangsdaten erfolgt auf dem Server bei jedem Request aufs neue, als wäre es der erste Request. Nur sind die Zugangsdaten nach der ersten Eingabe im Cache des Clients bis zum Ende der Session zwischengespeichert.

Größter Vorteil dieser Methode ist, dass diese sowohl in HTTP-Clients als auch HTTP-Server standardmäßig bereits implementiert ist, eben weil es so im HTTP-Standard festgelegt ist. Außerdem ist er nicht auf Scripte begrenzt, wie es z.B. bei PHP mit sessionbasierten Logins der Fall ist (wie z.B. in diesem Feature Artikel: http://aktuell.de.selfhtml.org/tippstricks/php/loginsystem/).

Soll heissen, ich möchte vom Server aus dem Browser per Header
(oder wie auch immer?) "etwas" schicken, dass Ihn künftig
so berechtigt, als hätte er bei einem manuellen Aufruf
eines geschützten Bereichs den richtigen Usernamen und Passwort
eingegeben.

Dazu musst Du als erstes definieren was genau Dein "geschützter Bereich" ist. Ist es ein Verzeichnis? Was für Dateien willst Du schützen? Was für serverseitige Technologien stehen Dir zur Verfügung?

Du könntest den Clients z.B. einen Cookie mit irgendeiner (nicht erratbaren) ID schicken. Diese kannst Du mit serverseitigen Technologien sehr einfach auswerten/kontrollieren (bei jedem Request!). Schwieriger wird es, wenn Du auch statische Dateien wie HTML, Bilder... schützen willst. Hier bräuchtest Du auch eine serverseitige Technik, die Dir die Kontrolle der übermittelten ID ermöglicht. Das kannst Du z.B. erreichen, indem Du Bilder nicht direkt auslieferst, sondern ebenfalls durch eine serverseitige Technologie, die vor der Ausgabe der Datei die ID im Cookie prüft (z.B. ein PHP-Script).

Cookies haben nebenbei den Vorteil, dass sie auch über eine Browsersession hinaus gelten können. Außerdem können Cookies gemäß HTTP-Spezifikation genau wie der Authorization-Header bei HTTP-Auth an alle Resourcen im Verzeichnis gesendet werden, sogar an alle Resourcen eines Hostnamens.

Möglich oder nicht?

Mit HTTP Basic Auth sicher nicht, aber anders, wie gesagt.

Siehe auch:
  -> RFC 2617: 1.2 Access Authentication Framework
  -> RFC 2616: 14.8 Authorization

Grüße
Andreas