Schleife beim Einloggen
johny7
- php
2 Edgar Ehritt0 johny70 Edgar Ehritt0 johny71 Edgar Ehritt0 johny7
Moin allerseits,
ich versuche nun seit etlicher Zeit vor einem Bereich meiner Site einen Login zu schalten nach dem bekannten Prinzip:
if (!isset($PHP_AUTH_USER)) {
header('WWW-Authenticate: Basic realm="Download Technischer Fachwirt"');
header('HTTP/1.0 401 Unauthorized');
var_dump($_SERVER);
exit;
} else {
if ($PHP_AUTH_USER != "usr" || $PHP_AUTH_PW != "pass") {
header('HTTP/1.0 401 Unauthorized');
exit;
}
}
Nach Eingabe der Daten taucht das Fenster jedoch wieder und wieder auf. Ich habe auch schon vorher den ganz normalen Klassiker versucht:
if (!isset($PHP_AUTH_USER) || !isset($PHP_AUTH_PW) || $PHP_AUTH_USER != "usr" || $PHP_AUTH_PW != "pass") {
header('WWW-Authenticate: Basic realm="Download Technischer Fachwirt"');
header('HTTP/1.0 401 Unauthorized');
var_dump($_SERVER);
exit;
} else {
// :-)
}
Nichts tut sich da. Mir ist das wohl schonmal gelungen, aber das betr. Script hilft mir irgendwie nicht weiter. Kann mir jemand den Hintergrund beschreiben, warum so eine Schleife auftritt?
Grüße, JN
Hallo Johny7,
Kann mir jemand den Hintergrund beschreiben, warum so eine Schleife auftritt?
das ist denkbar einfach erklärt:
Dein Script setzt auf die Existenz der Variablen $PHP_AUTH_USER
. Jedoch spricht die Dokumentation PHPs von $_SERVER['PHP_AUTH_USER']
. Weiterhin ist zu lesen, dass HTTP-Authentifizierung durch PHP nur verfügbar ist, wenn PHP als Apache-Modul läuft. Das ist zwar nicht hundertprozentig korrekt, entspricht aber den Konfigurationen der allermeisten Webserver-CGI-Anbindungen. Wenn PHP tatsächlich als Apachemodul laufen sollte, was Du mit echo php_sapi_name();
überprüfen kannst, Solltest Du Dein Script auf $_SERVER['PHP_AUTH_USER']
umstellen.
Wie es derzeit für mich als Außenstehender aussieht, ist entweder die Variable $_SERVER['PHP_AUTH_USER']
auch bei einem Login nicht vorhanden (PHP wird via CGI angesprochen), oder $PHP_AUTH_USER
wird einfach nur nicht gefunden. Letzteres liegt an der Konfiguration von register_globals.
Was auch letztendlich zutreffen mag, führt in Deinem ersten Script zu der Schleife. Es ist nämlich egal, ob jemand sich noch gar nicht versucht hat einzuloggen, oder Nutzername und Passwort nur nicht erkannt werden bzw. falsch sind, denn sowohl im Anweisungsblock unter IF
als auch im Anweisungsblock unter ELSE
wird immer der HTTP-Header "HTTP/1.0 401 Unauthorized" ausgegeben. Dieser sorgt dafür, dass der Browser immer wieder eine Aufforderung zum Einloggen ausgibt.
Sollte auch Dein zweites Script immer wieder dafür sorgen, dass eine Aufforderung zum Einloggen am Browser ausgegeben wird, existiert die Variable $PHP_AUTH_USER
tatsächlich nicht. Versuche es also bitte mit $_SERVER['PHP_AUTH_USER']
!
Gruß aus Berlin!
eddi
Moin allerseits,
Hallo Johny7,
das ist denkbar einfach erklärt:
Dein Script setzt auf die Existenz der Variablen
$PHP_AUTH_USER
. Jedoch spricht die Dokumentation PHPs von$_SERVER['PHP_AUTH_USER']
.
Diese Variante habe ich auch schon probiert - erfolglos.
Wie es derzeit für mich als Außenstehender aussieht, ist entweder die Variable
$_SERVER['PHP_AUTH_USER']
auch bei einem Login nicht vorhanden (PHP wird via CGI angesprochen), oder$PHP_AUTH_USER
wird einfach nur nicht gefunden. Letzteres liegt an der Konfiguration von register_globals.
Kann ich das denn im Script umkonfigurieren oder muss ich beim Anbieter anfragen? Ich bin bei bplaced.net
denn sowohl im Anweisungsblock unter
IF
als auch im Anweisungsblock unterELSE
wird immer der HTTP-Header "HTTP/1.0 401 Unauthorized" ausgegeben. Dieser sorgt dafür, dass der Browser immer wieder eine Aufforderung zum Einloggen ausgibt.
Der 401-Header sorgt für den Einloggen-Dialog? D.h., wenn ich ihn im ersten IF-Block weglasse, ist das Problem gelöst?
Grüße, JN
Re:
Ich bin bei bplaced.net
Alles klar. Da kannst Du machen, was Du willst. Es wird keinesfalls funktionieren.
Das folgende Beispiel kann auch für PHP via CGI verwendet werden. Notwendig ist neben PHP, dass mod_rewrite genutzt werden kann. Dazu braucht man ein Verzeichnis und eine .htaccess-Configuration:
RewriteEngine On
RewriteCond %{HTTP:Authorization} (.+)
RewriteRule ^(.*)$ index.php?AUTH=%1 [L,QSA]
Die index.php, die in dem Verzeichnis liegt, könnte dann in etwa so aussehen:
<?php
if (!isset($_GET['AUTH'])){
header('WWW-Authenticate: Basic realm="Download Technischer Fachwirt"');
header('HTTP/1.0 401 Unauthorized');
exit;
}
@list($nutzer,$passwd)=explode(':',base64_decode(substr($_GET['AUTH'],6)));
if($nutzer!='usr' || $passwd!='pass'){
header('WWW-Authenticate: Basic realm="Download Technischer Fachwirt"');
header('HTTP/1.0 401 Unauthorized');
exit;
}
echo 'Du bist eingeloggt.'
?>
Gruß aus Berlin!
eddi
Moin allerseits,
erstmal vielen Dank, es hat funktioniert.
Ich bin bei bplaced.net
Alles klar. Da kannst Du machen, was Du willst. Es wird keinesfalls funktionieren.
Weil? Ich habe nicht ganz verstanden.
Das folgende Beispiel kann auch für PHP via CGI verwendet werden. Notwendig ist neben PHP, dass mod_rewrite genutzt werden kann. Dazu braucht man ein Verzeichnis und eine .htaccess-Configuration:
RewriteEngine On
RewriteCond %{HTTP:Authorization} (.+)
RewriteRule ^(.*)$ index.php?AUTH=%1 [L,QSA]
>
Bedeutet? Ist das alles, was in der htaccess stehen muss? Ich habe nämlich das Problem, dass jetzt irgendwie die Grafiken aus untergeordneten Verzeichnissen nicht angezeigt werden. Müssen da Berechtigungen gesetzt werden?
> Die index.php, die in dem Verzeichnis liegt, könnte dann in etwa so aussehen:
>
> ~~~php
<?php
@list($nutzer,$passwd)=explode(':',base64_decode(substr($_GET['AUTH'],6)));
> ?>
Was bedeutet speziell dieser Ausdruck?
Danke schonmal
Grüße, JN
Re:
Ich bin bei bplaced.net
Alles klar. Da kannst Du machen, was Du willst. Es wird keinesfalls funktionieren.
Weil? Ich habe nicht ganz verstanden.
Hier liegt das Problem eindeutig bei bplaced.net. Ich selbst habe dort auch Webspace und kenne die einzelnen Rahmenbedingungen recht gut. Mir ist bis heute nicht klar, ob bplaced.net PHP als FastCGI-Binär oder als ApacheModul betreibt. Deren PHP verhält sich wie ein Zwitter (nicht nur in der Hinsicht und es kann nicht nur an der integrierten GEOIP-Erweiterung liegen). Daher war mir alles klar, als Du bplaced.net schriebst.
RewriteEngine On
RewriteCond %{HTTP:Authorization} (.+)
RewriteRule ^(.*)$ index.php?AUTH=%1 [L,QSA]
> >
> Bedeutet? Ist das alles, was in der htaccess stehen muss? Ich habe nämlich das Problem, dass jetzt irgendwie die Grafiken aus untergeordneten Verzeichnissen nicht angezeigt werden. Müssen da Berechtigungen gesetzt werden?
Mehr muss dort nicht stehen. Hättest Du vorher Dein Problem eingehend geschildert, hätte ich gleich darauf Rücksicht nehmen können:
~~~apache
RewriteEngine On
RewriteCond %{HTTP:Authorization} (.+)
RewriteRule !^(unterverzeichnisnamen|nocheinunterverzeichnis|undnocheins)$ index.php?AUTH=%1 [L,QSA]
<?php
@list($nutzer,$passwd)=explode(':',base64_decode(substr($_GET['AUTH'],6)));
?>
@ Verhindert Fehlermeldungen. Alle anderen Funktionen schlägst Du bitte selbständig im [PHP-Manual](http://www.php.net/manual/de/) nach!
Gruß aus Berlin!
eddi
Moin allerseits,
vielen Dank für deine Hilfe.
RewriteEngine On
RewriteCond %{HTTP:Authorization} (.+)
RewriteRule !^(unterverzeichnisnamen|nocheinunterverzeichnis|undnocheins)$ index.php?AUTH=%1 [L,QSA]
>
Ich habe das probiert in meinem speziellen Fall mit:
~~~apache
RewriteRule !^(icons)$ index.php?AUTH=%1 [L,QSA]
Ich habe folgende Verzeichnisstruktur:
root
|
|-- downloadverzeichnis
|-- Dateimanager
| |
| |- icons
| |- index.php
| |- .htaccess
|-- etc
Die Autorisierung geschieht nun im Dateimanager. Der greift aber auf Daten auf dem downloadverteichnis zu. Diese will ich auch schützen. Nun habe ich versucht, die .htaccess im Dateimanager zu löschen und eine ins Wurzelverzeichnis mit folgendem Inhalt zu schreiben:
RewriteEngine On
RewriteCond %{HTTP:Authorization} (.+)
RewriteRule !^(downloadverzeichnis|Dateimanager)$ Dateimanager/index.php?AUTH=%1 [L,QSA]
Das hat aber nicht so geklappt, wie ich es wollte. Komischerweise funktioniert es aber auch nicht mehr so wie vorher, auch nachdem ich die .htaccess wieder im Dateimanager so wie vorher erstellt und im Wurzelverzeichnis gelöscht habe. Die Anmeldung funktioniert aber die Bilder werden wieder nicht angezeigt.
Die mod Rewrite Google-Suchergebnisse beziehen sich irgendwie nicht auf die Autorisierung.
Grüße, JN
Re:
RewriteEngine On
RewriteCond %{HTTP:Authorization} (.+)
RewriteRule !^(downloadverzeichnis|Dateimanager)$ Dateimanager/index.php?AUTH=%1 [L,QSA]
>
> Das hat aber nicht so geklappt, wie ich es wollte. Komischerweise funktioniert es aber auch nicht mehr so wie vorher, auch nachdem ich die .htaccess wieder im Dateimanager so wie vorher erstellt und im Wurzelverzeichnis gelöscht habe. Die Anmeldung funktioniert aber die Bilder werden wieder nicht angezeigt.
Wer löst denn die Aufforderung zur Authentifizierung aus? Deine index.php!
Wird diese ausgeführt, wenn das Wurzelverzeichnis angefordert wird? Nein!
...soweit für Dein Verständnis, warum Dein Versuch nicht funktionieren kann.
Generell gäbe es zwar jetzt die Möglichkeit, dafür erneut mod\_rewrite zu bemühen, um tatsächlich die index.php auszuführen, wenn die Verzeichnisse "downloadverzeichnis" oder "Dateimanager" angefordert werden. Nur, wozu? Der Server kann Authentifizierung erheblich besser, als das PHP kann. Mit "besser" meine ich hier auch "sicherer", da die Authentifizierungsmethode Digest Passworte nicht quasi als Klartext durch die Leitung jagt.
Es stellt sich also generell die Frage, was Du tatsächlich machen willst: Willst Du Dich nur mit PHP ausprobieren, wie man eine Authentifizierung umsetzen kann, oder brauchst Du tatsächlich Anmeldefunktionalität, weil ein reales Schutzbedürfnis dem zugrunde liegt? Im letzen Fall sei Dir [Authentication, Authorization and Access Control](http://httpd.apache.org/docs/2.2/howto/auth.html) der Apache-Dokumentation als Lektüre empfohlen.
> Die mod Rewrite Google-Suchergebnisse beziehen sich irgendwie nicht auf die Autorisierung.
So schlau sind die meisten leider nicht, Authentifizierung beim CGI mittels mod\_rewrite zu realisieren, alsdass es dazu viel zu finden gäbe. Auch allgemein sind die üblichen Erklärungen und deren Beispiele eher auf SEO-Pfadtranskription beschränkt, damit auch der letzte seine webgeloggten Auslassungen hochrangig bei google positionieren kann...
Es beleibt also beim Rat, nicht Suchmaschinen lang zu strapazieren, wenn man Probleme mit Serverkonfigurationen hat, sondern die [Dokumentation von mod_rewrite](http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html) aufzusuchen. Dort steht alles kurz, knapp, knackig, was man tatsächlich wissen muss.
Gruß aus Berlin!
eddi