Warum kein htaccess Auth Header per CGI?

[Sebastian]

Moin!

Nachdem ich mich nun recht lange mit der .htaccess Authentifizierung
beschäftigt habe, bin ich auf folgende Frage gestoßen, auf die
ich bislang keine eindeutige Antwort gefunden habe:

Wie kann ich es realisieren, dem Client Browser per Script einen
Header zu schicken, der eine htaccess Autentifizierung emuliert?

Also die Kommunikation zwischen Webserver und Browser per Script
nachbilden?
Per PHP z.B. kann ich ja einen Header schicken, der das graue
Fensterchen beim Client öffnet und User sowie Pass zurück gibt.

Das, was der Webserver dann bei Erfolg an den Client zurück
schickt, muss doch auch manuell möglich sein, oder nicht?

Danke und Gruß

[wahsaga]

hi,

Wie kann ich es realisieren, dem Client Browser per Script einen
Header zu schicken, der eine htaccess Autentifizierung emuliert?

in dem du den in dieser sprache verfügbaren befehl nutzt, um einen HTTP header auszulösen.

Das, was der Webserver dann bei Erfolg an den Client zurück
schickt,

(und damit meine ich: _______________ )

muss doch auch manuell möglich sein, oder nicht?

was meinst du mit manuel? willst du per tastatur die bytes eintippen, die über die leitung gehen sollen?

gruß,
wahsaga

[Andreas Korthaus]

Hallo!

Wie kann ich es realisieren, dem Client Browser per Script einen
Header zu schicken, der eine htaccess Autentifizierung emuliert?

in dem du den in dieser sprache verfügbaren befehl nutzt, um einen HTTP header auszulösen.

Aber AFAIK kommt man per CGI dann leider nicht an das gesendete Passwort, oder?

Grüße
Andreas

[Cybaer]

Hi,

Aber AFAIK kommt man per CGI dann leider nicht an das gesendete Passwort, oder?

Ja, das geht nur wenn PHP als Modul läuft ...

Gruß, Cybaer

[Sebastian]

Hallo,

erstmal Danke für die Antworten.

Vielleicht habe ich meine Frage etwas
undeutlich gestellt. Ich versuche es nochmal.

Welche Möglichkeiten gibt es, einen .htaccess Schutz zu nutzen,
OHNE das vom Browser generierte Abfragefenster für User und Pass
zu nutzen.
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. Möglich oder nicht?

Gruß Sebastian
Sebastian

[wahsaga]

hi,

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

ohne aufwendige und unschöne verrenkungen - eigentlich gar keine.

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.

definiere zukünftig - für den rest der sitzung, oder bis zum jüngsten gerücht?

Möglich oder nicht?

ersteres: per session beispielsweise, ja.
dann musst du den "schutz" vor unbefugten zugriffen allerdings selber implementieren; bspw. in dem du die dateien über http gar nicht erreichbar machst, und per PHP-script "durchschleust".

gruß,
wahsaga

[Sebastian]

definiere zukünftig - für den rest der sitzung, oder bis zum
jüngsten gerücht?

Für den Rest der Sitzung hätte völlig gereicht ;-)

ersteres: per session beispielsweise, ja.
dann musst du den "schutz" vor unbefugten zugriffen allerdings
selber implementieren; bspw. in dem du die dateien über http gar
nicht erreichbar machst, und per PHP-script "durchschleust".

Was ja dann nichts mehr mit dem .htaccess Ansatz zu tun hätte.
Der (vermutlich naive) Ansatz dem Browser die "Berechtigung"
z.B. per Header zu übermitteln, ist also nicht möglich?

Gruß
Sebastian

[wahsaga]

hi,

Was ja dann nichts mehr mit dem .htaccess Ansatz zu tun hätte.

ja, weil eben das nicht geht - das sollte doch inzwischen rübergekommen sein.
bei HTTP AUTH möchte der server bei _jedem_ neuen request die zugangsdaten mitgeteilt bekommen.
wenn der client keine mitschickt, fordert der server ihn explizit dazu auf. wenn er welche mitschickt, dann OK.

Der (vermutlich naive) Ansatz dem Browser die "Berechtigung"
z.B. per Header zu übermitteln, ist also nicht möglich?

nein.
der browser selber merkt sich die eingegebeben zugangsdaten idR. nach dem erstmaligen eingeben.

gruß,
wahsaga

[Sebastian]

Hi,

nun sehe ich doch um einiges klarer und meine gedanklichen
Verwirrungen sind (nahezu) aufgelöst :-)

Vielen Dank für die kompetenten und aufschlussreichen Antworten!

Gruß
Sebastian

[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

[Cybaer]

Hi,

Möglich oder nicht?

Nicht möglich, aber auch nicht notwendig. Du kannst den Abruf von bestimten/allen Dateien sehr einfach mittels mod_rewrite über ein einziges, einfaches PHP-Script laufen lassen, welches dann die eigentliche Datei z.B. mittels readfile() übergibt. Für den Benutzer macht das keinen Unterschied, d.h., er kann zumindest keinen offensichtlich erkennen (ggf. auch unoffensichtlich nicht ;-)). Er sieht nur die "normalen" URLs.

Normalerweise legt man schützenswerte Dateien dann auch prinzipiell außerhalb des per HTTP erreichbaren Pfades an (das ist ja PHP auch prinzipiell egal). Ist das nicht möglich, so schützt man die Dateien eben sicherheitshalber nochmal per .htaccess.

Gruß, Cybaer

[Siechfred]

Tag Sebastian.

Wie kann ich es realisieren, dem Client Browser per Script einen
Header zu schicken, der eine htaccess Autentifizierung emuliert?
[...]
Das, was der Webserver dann bei Erfolg an den Client zurück
schickt, muss doch auch manuell möglich sein, oder nicht?

Nein, denn der CGI-Standard sieht nur zwei Möglichkeiten der Informationsübermittlung vor: entweder über Argumente, die der CGI-Anwendung mitgegeben werden, oder über die Umgebungsvariablen, die der Server vor Aufruf des Programms selbständig setzt. Da der Server in seiner Eigenschaft als CGI-Gateway zwar den Nutzernamen als Umgebungsvariable "REMOTE_USER" zur Verfügung stellt, das Passwort aber nicht, besteht unter reinen CGI-Bedingungen keine Möglichkeit, an das Passwort zu gelangen. Man kann zwar mittels eines CGI-Programms einen entsprechenden Statuscode 401 zusammen mit einem WWW-authenticate-Header senden und so den Eingabedialog provozieren, scheitert aber an der Auswertung der Antwort.

Ergo braucht es irgendeine Zusatztechnologie, die den Server dazu überredet, die gesuchten Informationen preiszugeben, das wäre z.B. im Falle von Perl mod_perl, mit dessen Hilfe letztendlich nichts anderes gemacht wird, als den Handler für den Authentifizierungsmechanismus auf ein Perlmodul umzubiegen (PerlAuthenHandler). Dann kann man mit Hilfe eines eigenen Perlscripts die Daten der Authentifizierung überprüfen und mit Hilfe des Scriptes reagieren. Aber das alles ist dann kein CGI mehr.

Siechfred