nicht angemeldet
wie komme ich an user und pw nach 401???
Hi,
über $PHP_AUTH_USER sowie _PW kommt man ja bekanntlich unter PHP an die authentifizierungs-daten nach erfolgreichem login auf eine per .htaccess geschütze seite (Apache).
Schlägt die authentifizierung fehl, wird ein 401er erzeugt, welchen ich per .htaccess-direktive (ErrorDocument) auf eine eigene seite legen kann. Leider sind hier $PHP_AUTH_USER u. _PW leer :(((
Gibt es trotzdem eine möglichkeit, an die fehlerhaften daten für "user" und "passwort" zu gelangen, welche zum 401 führten???
--Micha
-
Hi auch (long time no read),
Schlägt die authentifizierung fehl, wird ein 401er erzeugt,
welchen ich per .htaccess-direktive (ErrorDocument) auf eine
eigene seite legen kann.
Leider sind hier $PHP_AUTH_USER u. _PW leer :(((
Gibt es trotzdem eine möglichkeit, an die fehlerhaften daten für
"user" und "passwort" zu gelangen, welche zum 401 führten???Hm, ich kenne das CGI-Interface von PHP nicht, aber der Apache selbst
schreibt im Falle eines 401 eine Menge Informationen ins Environment:REMOTE_ADDR=153.46.90.209
REMOTE_PORT=4264
REMOTE_USER=123 (der von mir eingegebene Benutzername)REQUEST_METHOD=GET
REQUEST_URI=/~ms/401/ (mein geschütztes Verzeichnis)REDIRECT_REDIRECT_ERROR_NOTES=user 123 not found: /~ms/401/
REDIRECT_REDIRECT_REQUEST_METHOD=GET
REDIRECT_REDIRECT_STATUS=401 (zu dem Thema hatten wir gerade ein Posting hier)
REDIRECT_STATUS=401
REDIRECT_URL=/~ms/env.pl (mein 401-Handler, der das hier ausgibt)Gib doch mal Dein komplettes Environment aus, um zu isolieren, ob PHP
die Daten gar nicht sieht oder bloß nicht durchreicht.Viele Grüße
Michael-
Moin
Hm, ich kenne das CGI-Interface von PHP nicht, aber der Apache selbst
schreibt im Falle eines 401 eine Menge Informationen ins Environment:Nein, geht so nicht. Wenn der Webserver die Authentifizierung per .htaccess vornimmt, dann kriegt PHP die Username/Passwort-Daten nicht (über CGI sollte es auch nicht gehen). Das ist übrigens ein dokumentiertes Feature!
Wenigstens der Username sollte im Error oder Access-Log landen.
Wenn du das Passwort unbedingt haben willst, musst du wohl die Authentifikation mit PHP machen. Dann hast du auch mehr Kontrolle darüber was passiert.
--
Henryk Plötz
Grüße aus Berlin-
Hi Henryk,
Hm, ich kenne das CGI-Interface von PHP nicht, aber der Apache selbst
schreibt im Falle eines 401 eine Menge Informationen ins Environment:
Nein, geht so nicht.Mein Posting basiert auf einer Konfiguration, mit der ich den Zugriff
gerade hier habe laufen lassen. (Ich hätte es nicht auswendig gewußt. ;-)Die Benutzerkennung wird bei "401" in REMOTE_USER gesetzt.
(Sogar dann, wenn es zu gar keiner Überprüfung gekommen ist, weil vorher
ein interner Serverfehler aufgrtreten war - beim ersten Versuch hatte ich
mich im Pfadnamen der User-Datei vertippt ... probier's selbst aus!)Wenn der Webserver die Authentifizierung per .htaccess vornimmt,
dann kriegt PHP die Username/Passwort-Daten nicht
Das ist übrigens ein dokumentiertes Feature!Daß PHP nicht an das normale Environment ran kommt?
Das wäre dann aber ein heftiges Argument _gegen_ die Verwendung von PHP.Wenigstens der Username sollte im Error oder Access-Log landen.
Das naturlich außerdem (falls entsprechendes Log-Format).
Wenn du das Passwort unbedingt haben willst, musst du wohl die
Authentifikation mit PHP machen.An das Passwort kommt man über Server Authentication natürlich generell
nicht ran.
Das kann ja schon deshalb nicht funktionieren, weil der Webserver es ggf.
auch nicht kennt (es könnte ja verschlüsselt übertragen worden sein, bei
AuthType Digest).Viele Grüße
Michael-
Moin
Die Benutzerkennung wird bei "401" in REMOTE_USER gesetzt.
(Sogar dann, wenn es zu gar keiner Überprüfung gekommen ist, weil vorher
ein interner Serverfehler aufgrtreten war - beim ersten Versuch hatte ich
mich im Pfadnamen der User-Datei vertippt ... probier's selbst aus!)ok, siehe unten
Daß PHP nicht an das normale Environment ran kommt?
Das wäre dann aber ein heftiges Argument _gegen_ die Verwendung von PHP.Nein, natürlich kommst du an das Environment, nur nicht an das Passwort wenn der Server schon authentifiziert. Ich bezog mich aus dem Gedächtnis auf diesen Abschnitt aus http://www.php.net/manual/en/features.http-auth.php:
In order to prevent someone from writing a script which reveals the password for a
page that was authenticated through a traditional external mechanism, the PHP_AUTH
variables will not be set if external authentication is enabled for that particular page. In
this case, the $REMOTE_USER variable can be used to identify the
externally-authenticated user.Der Teil mit dem $REMOTE_USER war mir wohl grad entfallen, weil ich es eh nie brauche :)
--
Henryk Plötz
Grüße aus Berlin-
HI Henryk,
In order to prevent someone from writing a script which reveals the password for a
page that was authenticated through a traditional external mechanism, the PHP_AUTH
variables will not be set if external authentication is enabled for that particular page.mir wird der Zusammenhang zwischen diesen beiden Informationen nicht klar.
Okay, PHP möchte verhindern, daß man ein Passwort versehentlich irgendwohin ausgibt.
Was aber hat das damit zu tun, die Benutzerkennung zugänglich zu machen?
Denn nur um diese Informationgeht es ja gerade.
Eine Variable mit dem via HTTP-Authentication übertragenen Passwort kann PHP doch
ohnehin nicht anbieten, weil ggf. nicht mal der Webserver weiß, welches Passwort
er da gerade empfangen hat (siehe mein vorheriges Posting).Viele Grüße
Michael-
Moin
Okay, PHP möchte verhindern, daß man ein Passwort versehentlich irgendwohin ausgibt.
Nicht "versehentlich". Es soll verhindert werden dass ein Passwortgeschützter Bereich irgendwo existiert (mit einweg-gehashtem Passwort) und ein böser Bube da ein PHP-Skript reinsetzt dass Passwörter mitloggt.
Was aber hat das damit zu tun, die Benutzerkennung zugänglich zu machen?
Die Benutzerkennung wird nicht unzugänglich gemacht. Es stehen lediglich die Variablen $PHP_AUTH_USER und $PHP_AUTH_PW nicht zur Verfügung (die ja eigentlich nur zusammen einen Sinn haben).
Denn nur um diese Informationgeht es ja gerade.
Wie gesagt, $REMOTE_USER bleibt dir erhalten
Eine Variable mit dem via HTTP-Authentication übertragenen Passwort kann PHP doch
ohnehin nicht anbieten, weil ggf. nicht mal der Webserver weiß, welches Passwort
er da gerade empfangen hat (siehe mein vorheriges Posting).Das habe ich schon im vorherigen Posting nicht verstanden: Der Webserver empfängt ein Passwort (BASE64-enkodiert) und kennt es dann nicht mehr?
Also:
Normaler Ablauf ohne externe Authentifizierung: mit PHP: Der Webserver empfängt Passwort und Benutzername base64-codiert, dekodiert sie und wurschtelt sie auseinander. Der PHP-Interpreter läuft an und holt sich das Passwort und den Benutzernamen beim Webserver ab. Der Benutzername landet in $REMOTE_USER und $PHP_AUTH_USER und das Passwort in $PHP_AUTH_PW.
mit CGI/Perl: Wahrscheinlich ähnlich, bloss das die Informationen im Environment rumliegen?Mit externer Authentifizierung: mit PHP: Der Webserver empfängt Passwort und Benutzername, dekodiert sie, entwurschtelt sie und überprüft ob der Zugriff gewährt wird. Wenn der Zugriff gewährt wurde, zum Beispiel auf ein PHP-Skript, dann springt der PHP-Interpreter an und kriegt jetzt das Passwort _nicht_ vom Server, da die Authentifikation ja schon vorbei ist und es keinen vernünftigen Grund mehr gibt, das Passwort irgendwo hin weiterzugeben. Der Benutzername landet weiterhin in $REMOTE_USER. Das selbe sollte passieren wenn ein PHP-Skript als 401 Dokument aufgerufen wurde.
mit CGI/Perl: hmm? Ich hoffe stark das Passwort wird auch hier nicht von Webserver rausgegeben.--
Henryk Plötz
Grüße aus Berlin-
Hi Henryk,
Das habe ich schon im vorherigen Posting nicht verstanden:
Ich rede von Server Authentication im Allgemeinen.
Du redest von Server Authentication im Modus "Basic".Der Webserver empfängt ein Passwort (BASE64-enkodiert) und kennt es
dann nicht mehr?Das ist "Basic".
In Digest empfängt er ein MD5-codiertes Passwort und vergleicht es mit
dem gespeicherten, ebenfalls MD5-codierten Wert.
Was der eigentlich bedeutete, weiß er aber nicht (wozu auch?).mit CGI/Perl: Wahrscheinlich ähnlich, bloss das die Informationen
im Environment rumliegen?Kein Passwort (siehe oben).
Was immer PHP als Passwort ausgibt, kann es bestenfalls dadurch bekommen,
daß mod_php sich so tief in den Apache hinein hängt, daß es in die Tabellen
von mod_auth hinein greift oder aus den Core-Tabellen den Original-HTTP-
Header fischt.
PHP via CGI sollte genauso wenig ein Passwort zu sehen bekommen wie Perl
via CGI, denke ich mal. Ich wüßte zumindest nicht, woher die Information
stammen sollte.Probier doch mal, einen Digest-geschützten Bereich zu definieren und darin
mit PHP ein Passwort abzufragen. (M$IE 5+, Opera 4+, Mozilla 0.9.7.+)Viele Grüße
Michael-
Moin
Ich rede von Server Authentication im Allgemeinen.
Du redest von Server Authentication im Modus "Basic".Ah, ok, alle Unklarheiten beseitigt. Vielleicht hätte ich das 'Only "Basic" authentication is supported at this point' noch extra erwähnen sollen :)
In Digest empfängt er ein MD5-codiertes Passwort und vergleicht es mit
dem gespeicherten, ebenfalls MD5-codierten Wert.
Was der eigentlich bedeutete, weiß er aber nicht (wozu auch?).Hmm, auch wenn ich jetzt vor lauter Schreck nicht in der Lage war einen per Digest geschützten Bereich zu basteln (oder liegt das an Mozilla 0.9.6 ?), denk ich, ich weiss was du meinst.
Was immer PHP als Passwort ausgibt, kann es bestenfalls dadurch bekommen,
daß mod_php sich so tief in den Apache hinein hängt, daß es in die Tabellen
von mod_auth hinein greift oder aus den Core-Tabellen den Original-HTTP-
Header fischt.Das ist ja das schöne an einem Server-Modul.
Daher hier noch eine Notlösung für Wowbagger: Mit getallheaders() holst du dir ein Array aller HTTP-Header (geht nur wenn PHP als Modul läuft). Mit etwas Glück liegt da noch ein Eintrag "Authorization" drin rum. Der enthält dann einen Base64-kodierten String bestehend aus Username, einem Doppelpunkt und dem Passwort. Also mit base64_decode() (http://www.php.net/manual/en/function.base64-decode.php) lesbar machen, und dann am : auftrennen. Schon solltest du Username und Passwort haben. (bei Basic Auth)PHP via CGI sollte genauso wenig ein Passwort zu sehen bekommen wie Perl
via CGI, denke ich mal. Ich wüßte zumindest nicht, woher die Information
stammen sollte.Stimmt.
Wenn man jedoch das PHP-Modul benutzt, sollte man damit auch Digest-Auth machen können, man muss sich die benötigten Header bloss per Hand holen.
--
Henryk Plötz
Grüße aus Berlin-
Hi Henryk,
(oder liegt das an Mozilla 0.9.6 ?),
in der Changes-Liste von Mozilla 0.9.7 ist "Digest" explizit als Neuheit
dieser Version erwähnt. (Ist also noch "heiß").Wenn man jedoch das PHP-Modul benutzt, sollte man damit auch Digest-Auth
machen können, man muss sich die benötigten Header bloss per Hand holen.Was spricht dagegen, Digest langsam mal in PHP einzubauen (wenn die schon
so eine API anbieten)?RFC 2617 (ftp://ftp.isi.edu/in-notes/rfc2617.txt) ist von Juni 1999.
Apache meint dazu in (http://httpd.apache.org/docs/mod/mod_auth_digest.html):
"As of this writing (October 2001), the only major browsers which support
digest authentication are Opera 4.0, MS Internet Explorer 5.0 and Amaya.
Therefore, we do not yet recommend using this feature on a large Internet
site. However, for personal and intra-net use, where browser users can be
controlled, it is ideal."Viele Grüße
Michael
-
-
-
-
-
-
-
-
-
ReHi Michael+Henryk,
ja, leider lange nix mehr voneinander gehört...
Da hab' ich ja 'ne richtige diskussion angezettelt zwischen euch beiden und dabei traten ganz interessante dinge zu tage, danke dafür ;-)Bis (so hoffe ich) demnächst 'mal wieder...
--Micha