Zeit, die man bei HTTP-Auth. angemeldet ist, einstellen!?

[WauWau]

Hola,

Zu meinem Erstauen scheinbar ohne Probleme hab' ich gestern noch ne kleine HTTP-Authentizifierung in meinen Apachen reingebaut 8], und diesbezüglich ein kleines Fragelchen, genau :)

Jo, also, der Benutzer hat sich jetzt mal angemeldet, das heißt, die HTTP-Authentifizierung hat wunderbar stattgefunden und der Benutzer ist ... naja eben angemeldet halt. Nun meine Frage: Wo stellt man die Zeit an, nach der die "Session" ungültig sein soll? Also ich meine, wenn ich mich jetzt beim Selfforum /my/-Bereich anmelde, und in einer halben stunde erst wiederkomme, dann werde ich gerade "erneut" gefragt, wenn ich zu ...de/my/ gehe.

Ok, im Protokoll ist es afaik nicht vorgesehen, immerhin kann man es auch nicht in einer direktive beim Apachen steuern. Entsprechend regelt es wahrscheinlich der Browser. Dafürsprechen würde zum einen, dass es bei einigen Browsern ganz nette einstellungen zu solchen dingen gibt, außerdem wäre der browser dazu perfekt geeignet, da er ja sowieso nötige sicherheit schaffen will. Getestet: Gerade mal zum IE gegangen und forum...de/my/ aufgerufen, wie erwartet kam der HTTP-Authentifizierungsdialog.

Was spricht nun gegen die hochstwahrscheinliche Tatsache, dass der Browser bestimmt, wie lange man noch beim Server "angemeldet" ist, ist, dass man sich mal erstens einen eigenen browser zusammenprogrammieren könnte (man bräuchte auch nur einfach ein bisschen am mozilla rumwerkeln ;), und schon könnte man unendlich lange "unangemeldet" dort rumwerkeln, eine Passwortauthentifizierung hätte also in sofern keien sinn mehr, wenn nach dem Benutzer xy der Benutzer za noch auf dem server surfen kann, was ja nicht beabsichtigt ist.
Andererseits müsste der Browser dem server irgendwie kenntlich machen, wann er ihm das passwort senden will oder nicht. Hierbei könnte ich mir jedoch vorstellen, dass das Kennwort sowie der Benutzername sowieso bei jedem Request mitgeliefert wird und der Browser dann einfach nach einer gewissen zeit inaktivität des users sich vorstellen könnte... "so, jetzt sende ich das passwort einfach mal nicht mehr mit" (bin also nicht mehr "angemeldet"), und schon fragt der server nach dem pwd, und der browser stellt sich sozusagen "dumm"....

Also, wie ist das denn da dann genau...!?

WauWau

[Jens Holzkämper]

Tach,

Jo, also, der Benutzer hat sich jetzt mal angemeldet, das heißt, die HTTP-Authentifizierung hat wunderbar stattgefunden und der Benutzer ist ... naja eben angemeldet halt. Nun meine Frage: Wo stellt man die Zeit an, nach der die "Session" ungültig sein soll? Also ich meine, wenn ich mich jetzt beim Selfforum /my/-Bereich anmelde, und in einer halben stunde erst wiederkomme, dann werde ich gerade "erneut" gefragt, wenn ich zu ...de/my/ gehe.

es gibt keine Session; http baut im Prinzip für jede Resource eine neue Verbindung auf und schließt sie dann wieder. Die Authentifizierung wird deswegen jedesmal neu ausgehandelt, die Browser merken sich jedoch eine Anmeldung solange sie nicht geschlossen werden und schicken solange jedesmal die selben Daten wieder mit, außer sie erhalten irgendwann die Antwort 403, woraufhin sie die eingegebenen Daten verwerfen und den Benutzer erneut fragen.

Was spricht nun gegen die hochstwahrscheinliche Tatsache, dass der Browser bestimmt, wie lange man noch beim Server "angemeldet" ist, ist, dass man sich mal erstens einen eigenen browser zusammenprogrammieren könnte (man bräuchte auch nur einfach ein bisschen am mozilla rumwerkeln ;), und schon könnte man unendlich lange "unangemeldet" dort rumwerkeln, eine Passwortauthentifizierung hätte also in sofern keien sinn mehr, wenn nach dem Benutzer xy der Benutzer za noch auf dem server surfen kann, was ja nicht beabsichtigt ist.

Das ist jedoch ein Problem des Benutzers xy, wenn er jemand anderen seine Benutzereinstellungen nutzen läßt. Darum brauchst du dir aber sowieso keine Sorgen machen, denn dann könnte za auch auf das Login zugreifen, weil xy z.B. die Daten im Browser gespeichert hat.

mfg
Woodfighter

[WauWau]

Hallo Jens,

es gibt keine Session; http baut im Prinzip für jede Resource eine neue Verbindung auf und schließt sie dann wieder. Die Authentifizierung wird deswegen jedesmal neu ausgehandelt, die Browser merken sich jedoch eine Anmeldung solange sie nicht geschlossen werden und schicken solange jedesmal die selben Daten wieder mit, außer sie erhalten irgendwann die Antwort 403, woraufhin sie die eingegebenen Daten verwerfen und den Benutzer erneut fragen.

Das hört sich nun so an, als macht es doch der Server, der nach einer bestimmten Zeit sagt: "Schacht im Schicht" und dem Clienten nur noch ein 403 zurückgibt...!? hmm, dann müsste es irgendwo einstellbar sein, oder?

Das ist jedoch ein Problem des Benutzers xy, wenn er jemand anderen seine Benutzereinstellungen nutzen läßt. Darum brauchst du dir aber sowieso keine Sorgen machen, denn dann könnte za auch auf das Login zugreifen, weil xy z.B. die Daten im Browser gespeichert hat.

Wenn man nichts irgendwo speichert, also der Browser das Passwort _nicht_ speichern soll, dann wäre man ja trotzdem noch angemeldet. Der "folgeuser", der nicht authorisiert sein soll, braucht nur in der History oder im "Verlauf" nachzuschlagen und schon ist er drin... naja, das ist ja dann auch egal 8]

Wauwau

[Sven Rautenberg]

Moin!

Das hört sich nun so an, als macht es doch der Server, der nach einer bestimmten Zeit sagt: "Schacht im Schicht" und dem Clienten nur noch ein 403 zurückgibt...!? hmm, dann müsste es irgendwo einstellbar sein, oder?

Nein, standardmäßig wird der Server das nicht tun. Übrigens ist der HTTP-Code 401, und nicht 403, das nur am Rande.

Wobei ich unter "standardmäßig" verstehe, dass keine besondere serverseitige Programmierung erfolgt. Wenn man ein Verzeichnis beim Apache mit HTTP-Authentifizierung schützt (der Anfänger würde sagen: "mit .htaccess"), dann ist die einmal gelungene Anmeldung solange gültig, wie der Browser die Anmeldedaten bei sich speichert.

Und das kann zeitabhängig sein (das wäre dann Einstellungssache beim Browser selbst, in den Benutzereinstellungen), so ein Verhalten wäre mir aber neu. Üblich ist, dass eine Anmeldung prinzipiell unendlich lange dauert, solange der Browser nicht beendet wird.

Wenn man nichts irgendwo speichert, also der Browser das Passwort _nicht_ speichern soll, dann wäre man ja trotzdem noch angemeldet. Der "folgeuser", der nicht authorisiert sein soll, braucht nur in der History oder im "Verlauf" nachzuschlagen und schon ist er drin... naja, das ist ja dann auch egal 8]

Wenn der erste Benutzer sich irgendwo anmeldet, und dann den Browser _nicht_ schließt, und danach der zweite Benutzer denselben Browser weiterbenutzt, _dann_ ist das ein Problem.

Aber sowas tritt in der Regel nicht auf. Browser komplett schließen reicht in der Regel aus, und wenn tatsächlich solche Multi-User-Computer von zwei Benutzern genutzt werden, bei denen der eine beim anderen nichts böses machen darf, dann ist in der Regel ein Multi-User-Betriebssystem installiert, bei dem sich der erste Benutzer ausloggen und der zweite Benutzer dann einloggen muß - und alleine dadurch ist dann sichergestellt, dass keine Anmeldungen verdeckt und ungewollt weitergegeben werden.

Allerdings hast du da natürlich einen wichtigen Punkt angesprochen: Es wäre beispielsweise undenkbar, dass man sich bei seiner Onlinebank mit HTTP-Authentifizierung anmeldet, egal wie lang die eigene Kontonummer und PIN ist (je länger, desto unratbarer). Denn es ist Kern des Sicherheitskonzeptes, dass eine Session nach kurzer Zeit der Nichtnutzung verfällt und eine Neuanmeldung erforderlich macht - idealerweise verfällt die Session und löscht dabei auch gleich die letzte aufgerufene Seite, ansonsten kann jemand, der den (ja offenbar verlassenen) Rechner benutzt, zumindest noch die letzte Ausgabe lesen, was nicht unbedingt im Sinne des Accountinhabers sein muß.

Solch ein Auslogg-Vorgang läßt sich prinzipiell auch mit HTTP-Authentifizierung bewerkstelligen - allerdings nur mit serverseitigem Scripting (PHP als Apache-Modul, nicht als CGI, ginge beispielsweise), nicht mit .htaccess. Näheres dazu (Ausloggen bei HTTP-Auth) steht im Archiv - Alexander Korthaus hat dazu mal eine Methode mittels PHP gefunden.

- Sven Rautenberg

[WauWau]

Hallo Sven,

Nein, standardmäßig wird der Server das nicht tun. Übrigens ist der HTTP-Code 401, und nicht 403, das nur am Rande.

kann sein, ist ja auch schon so spät ;)

Wobei ich unter "standardmäßig" verstehe, dass keine besondere serverseitige Programmierung erfolgt.

sprich simple Apache-HTTP-Authentifizierung.

... (der Anfänger würde sagen: "mit .htaccess")

bei mir ist es direkt in der httpd.conf gespeichert.

, dann ist die einmal gelungene Anmeldung solange gültig, wie der Browser die Anmeldedaten bei sich speichert.

hmmm...

Und das kann zeitabhängig sein (das wäre dann Einstellungssache beim Browser selbst, in den Benutzereinstellungen), so ein Verhalten wäre mir aber neu. Üblich ist, dass eine Anmeldung prinzipiell unendlich lange dauert, solange der Browser nicht beendet wird.

wie ich überlegt habe...

Wenn man nichts irgendwo speichert, also der Browser das Passwort _nicht_ speichern soll, dann wäre man ja trotzdem noch angemeldet. Der "folgeuser", der nicht authorisiert sein soll, braucht nur in der History oder im "Verlauf" nachzuschlagen und schon ist er drin... naja, das ist ja dann auch egal 8]

eben

Wenn der erste Benutzer sich irgendwo anmeldet, und dann den Browser _nicht_ schließt, und danach der zweite Benutzer denselben Browser weiterbenutzt, _dann_ ist das ein Problem.

IE kann und will sich ja afaik sowieso auf Windows-systemen ab 98 nicht ganz schließen.

Allerdings hast du da natürlich einen wichtigen Punkt angesprochen: Es wäre beispielsweise undenkbar, dass man sich bei seiner Onlinebank mit HTTP-Authentifizierung anmeldet, egal wie lang die eigene Kontonummer und PIN ist (je länger, desto unratbarer). Denn es ist Kern des Sicherheitskonzeptes, dass eine Session nach kurzer Zeit der Nichtnutzung verfällt und eine Neuanmeldung erforderlich macht - idealerweise verfällt die Session und löscht dabei auch gleich die letzte aufgerufene Seite, ansonsten kann jemand, der den (ja offenbar verlassenen) Rechner benutzt, zumindest noch die letzte Ausgabe lesen, was nicht unbedingt im Sinne des Accountinhabers sein muß.

eben.....

Solch ein Auslogg-Vorgang läßt sich prinzipiell auch mit HTTP-Authentifizierung bewerkstelligen - allerdings nur mit serverseitigem Scripting (PHP als Apache-Modul, nicht als CGI, ginge beispielsweise), nicht mit .htaccess. Näheres dazu (Ausloggen bei HTTP-Auth) steht im Archiv - Alexander Korthaus hat dazu mal eine Methode mittels PHP gefunden.

jep ;)

WauWau

[Raik]

Hallo, Sven!

Näheres dazu (Ausloggen bei HTTP-Auth) steht im Archiv - Alexander Korthaus hat dazu mal eine Methode mittels PHP gefunden.

nennen wir ihn doch _Andreas_ Korthaus ;-)
http://forum.de.selfhtml.org/archiv/2003/9/56697/#m317009
http://tmp.knet-systems.de/auth.php
http://tmp.knet-systems.de/auth_source.php

freundl. Grüsse aus Berlin, Raik

[WauWau]

Hallo Raik,

http://tmp.knet-systems.de/auth.php
http://tmp.knet-systems.de/auth_source.php

Server nicht erreichbar 8[

WauWau

[Andreas Korthaus]

Hallo Sven!

Solch ein Auslogg-Vorgang läßt sich prinzipiell auch mit HTTP-Authentifizierung bewerkstelligen - allerdings nur mit serverseitigem Scripting (PHP als Apache-Modul, nicht als CGI, ginge beispielsweise), nicht mit .htaccess. Näheres dazu (Ausloggen bei HTTP-Auth) steht im Archiv - Alexander Korthaus hat dazu mal eine Methode mittels PHP gefunden.

"Alexander Korthaus", aha... :)

Das Problem ist, dass die Browser unterschiedlich auf das Senden von 401-Headern reagieren. Beim IE läuft es so, dass man nach einem 401 sich wieder neu einloggen muss. Ältere Mozilla-Versionen versuchen _jeden_ Request erstmal ohne Auth-Header, und schicken dann beim Erhalt eines 401 automatisch denselben Requst nochmal - diesmal _mit_ Auth-Header (sofern man sich vorher mal eingeloggt hat). Neuere Mozilla-Versionen schicken inzwischen nach dem Login auch direkt den Auth-Header mit, aber man kann ihm dann durch Senden eines 401-headers keinen neues Login-promt entlocken. Ich habe das mal ne Zeit lang umgangen, indem ich für ein Logout einen anderen "authentication realm" gesendet habe, indem ich den Zeiptunkt mit reingeschreiben habe. Das hat auch grundsätzlich funktioniert, nur hatte ich zum einen Probleme zusammen mit Session-Cookies, und damit dass die HTTP-Authentifizierung z.B. nicht in zu öffnenden Word-Dokumenten... funktioniert hat(man musste sich dann in Word extra einloggen...).
Daher bin ich dann wohl oder übel wieder bei HTML-Formularen gelandet, der große Vorteil ist einfach die 100%ig serverseitige Kontrolle.

http://forum.de.selfhtml.org/archiv/2003/9/56697/

btw., die Dateien sind nicht mehr da, aber das ist auch gut so, denn so wie es da steht funktioniert es mit dem Mozilla nicht 100%ig zuverlässig.
Ich habe aber eine Idee wie ich es ändern würde das es funktionieren müsste... Das große Problem bei der Geschichte ist zu unterscheiden - wann sendet der Browser den Auth-Header automatisch - und wann kommen die Daten tatsächlich vom User.

Grüße
Andreas

der alte Source(nicht verwenden!):
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

<?php
    // Sessions sind Voraussetzung
    session_start();

// user ausloggen (säter vielleicht eher mit session_destroy()...)
       if($_REQUEST['action'] == 'logout') {
        $_SESSION['auth']['status'] = 'off';
        display_logout();
    }

// prüfen ob user eingeloggt ist
    if ($_SESSION['auth']['status'] != 'on') {
        if (!isset($_SERVER['PHP_AUTH_USER'])) {
            // user sendet keine Auth-Daten -> komplett neuer Login, noch kein Login im aktuellen Browserfenster gewesen
            $_SESSION['auth']['newlogin'] = 1;
            authenticate();
        }
        else {
            // user sendet Auth-Daten: entweder durch Aufforderung oben, oder wegen "relogin"
            if ($_SESSION['auth']['newlogin'] == 1) {
                // neue Daten eingegeben
                check_auth();
                $_SESSION['auth']['newlogin'] = 0;
                $_SESSION['auth']['status'] = 'on';
                display_login();
            }
            else {
                // 'relogin': damit auch Mozilla Auth-Daten nicht automatisch aus dem Cache schickt -> sende "unique realm"
                $_SESSION['auth']['newlogin'] = 1;
                re_authenticate();
            }
        }
    }
    else {
         display_login();
    }

// Authentifizierungs Header senden
    function authenticate() {
        header ('HTTP/1.0 401 Unauthorized');
        header ("WWW-Authenticate: Basic realm="Test Authentication System"");
        die ("You must enter a valid login ID and password to access this resource\n");
      }

// Authentifizierungs Header mit "unique realm" senden (damit Mozilla bei Relogin nicht Auth-Daten aus dem Cache verwendet)
    function re_authenticate() {
        $unique = date ('d.m.Y, h.i.s');
        header ('HTTP/1.0 401 Unauthorized');
        header ("WWW-Authenticate: Basic realm="Test Re-Authentication System ($unique)"");
        die ("You must enter a valid login ID and password to access this resource\n");
      }

// HTML Quellcode für "logged in" Seite
      function display_login() {
          die ('<html><body><h3>User logged in</h3><a href="auth.php?action=logout">logout</a><br></body></html>');
    }

// HTML Quellcode für "logged out" Seite
    function display_logout() {
        die ('<html><body><h3>User logged out</h3><a href="auth.php">login again</a><br></body></html>');
    }

// Authentifzierung mit DB... durchführen
    function check_auth() {
        // check Auth...
    }
?>