HTTP-AUTH logout

[Andreas Korthaus]

Hallo!

Wieso implementieren die Browser eigentlich keine Möglichkeit eines Logouts für HTTP-Auth? Es wäre doch ein leichtes eine Schaltfläche zu schaffen die die Auth-Daten aus dem RAM oder wo auch immer die stehen zu löschen, oder? Noch schöner wäre allerdings ein HTTP-HEader der den Browser dazu veranlassen würde, ist sowas geplant? Ich fänd das gut. Das Problem mit HTTP-Auth ist nämlich, das viele der sog. Entscheidungsträger keine Ahnung haben, aber wissen dass es gut ist wenn man sich aus einer Anwendung ausloggt, so dass wenn man seinen Arbeitsplatz kurz verläßt nicht jeder Zugriff erlangen kann. Und diese Leute glauben man ist blöd wenn man sowas nicht kann sondern sagt man möge doch bitte das Browserfenster schließen - _alle_ Browserfenster. Diese ekeligen Workarounds mit einem nicht vorhandenen Benutzernamen funktionieren sowieso nicht in aktuellen Browsern.
Also suche ich nach einer Alternative, aber ich sehe da wenig Aussicht auf Erfolg. Eine Möglichkeit wäre ja, wenn man aus der Passwortdatei den User kurzfristig entfernt, ich hatte erst dran gedacht in einem anderen Verzeichnis das Login zu machen und wenn jemand sich eingeloggt, diesen User einer temporären Passwortdatei hinzuzufügen, für das eigentliche Verzeichnis der Anwendung, das hat nur den Haken, dass der Login dann nur für das andere Verzeichnis gilt, und der User sich 2 mal einloggen muss, oder man sendet für den 2. Login eine HTML-Seite mit einem Link oder meta-refresh(wobei ich nicht weiß ob das funktionieren würde) um sich dann mit dieser user@pass... Geschichte einzuloggen. Das ist wohl nicht so schön, oder? Zumindest könnte man dann den User auch ausloggen indem man den Eintrag aus der temporären Passortdatei entfernt.

Dann habe ich noch eine Idee, die vielleicht etwas besser ist:
Ich habe nur eine Passwortdatei und ein Verzeichnis, wenn der User sich jetzt auslogt entferne ich diesen aus der Passwortdatei, schicke ihm einen Location-Header so dass der Browser noch einen Request sendet, aber diesmal abgeblockt wird. Das doofe ist jetzt nur, wann füge ich den Benutzer wieder ein, damit er sich dann auch wieder legal einloggen kann? Ich habe dann 1 Script:

logout.php:

fopen("passwortfile");
//entferne Benutzer
fwrite("daten ohne diesen Benutzer");

header('Location: http://www.meinedomain.tld/irgendeinedatei.html');

So, bis dahin kein Problem, aber dann, dann kommt in einer Zeit die ich nicht kenne(da der User ja jetzt nicht mehr zu PHP & Co. durchkommt) der Request der ja scheitern wird. Gibt es irgendeine Möglichkeit mit dem Apachen bei einem 403-Request den originalen Request-String an ein bestimmten PHP-Script zu leiten, obwohl die Authentifizierung aus gutem Grund ja scheitert?
Oder anders herum, wenn der Client den Request sendet der ja "fehlschlagen" wird, dann öffnet sich im Browser das Auth-Fenster. Gibt es eine Möglichkeit, den Client gleichzeitg mit oder am besten anstatt des 403-Header einen entsprechenden Location-Header oder sowas zu schicken, der den Benutzer auf ein frei zugängliches Script sendet, welches die Austragung rückgängig macht? Ich weiß, das ist auch ein Missbrauch von HTTP, aber ginge das nicht vielleicht mit irgendwelchen schmutzigen Tricks(Apache-Modul?)? Problem hierbei ist noch, dass ich die ID des Users brauche, nur woher nehmen? OK, ich könnte in meinem obigen logout.php - Script die UserID mit an den Request-String anhängen, dann käm die ID auf jeden Fall mit zurück zum Apache, dann muss ich sie nur noch auslesen und erneut in einen Location-Header einfügen, nur diesmal an ein frei zugängliches Script. Gibt es da wohl irgendeine Möglichkeit? Könnte ich das vielleicht mit einer Rewrite-Rule machen? Oder wird die HTTP-Authentifizierung grundsätzlich _vor_ den anderen Direktiven in der .htaccess ausgeführt?

Naja, wenn alle Stricke reißen, dann kann ich ja in meinem logout.php-Script eine gewisse Zeit nach senden des Header den Eintrag rückgängig machen.
Ich gehe doch Recht in der Annahme dass sobald ich in PHP einen Location-Header durch Aufruf der Funktion header() sende, der komplette Response-Header sofort gesendet wird, und nicht gewartet wird bis das Script zuende gelaufen ist, oder? Dann könnte ich nämlich nach header() ein sleep(10) einfügen und danach die Änderung rückgängig machen.

Was haltet Ihr davon? Wie würdet Ihr das machen?

Viele Grüße
Andreas

[Stefan Bach]

Hallo,

wie wäre es, wenn du diesen Mißbrauch, wie du es ja schon selbst
bezeichnest, sein lässt und stattdessen mit Sessions arbeitest, wenn du
unbedingt ein Logout Script haben willst.

Wenn die Firma für welche das ganze implementiert werden soll
allerdings nicht völlig verblödet ist, dann haben die Mitarbeiter an
ihren Workstations kein Windows 9x installiert.

In diesem Fall sollten sie, wenn sie ihren Arbeitsplatz kurz verlassen
einfach Strg-Alt-Entf drücken und dort Computer sperren auswählen.
Dann macht es auch nix, wenn der Browser die Zugangsdaten noch
gespeichert hat.

Viele Grüße,

Stefan

[Cheatah]

Hi,

Wieso implementieren die Browser eigentlich keine Möglichkeit eines Logouts für HTTP-Auth?

weil Browser dazu ungeeignet sind. Es sind die Browser-_Hersteller_, die es implementieren müssten ;-)

Es wäre doch ein leichtes eine Schaltfläche zu schaffen

Nein, wäre es nicht. Wo soll die hin? Wo stört sie nicht, auch zumal sie fast immer deaktiviert ist?

Noch schöner wäre allerdings ein HTTP-HEader der den Browser dazu veranlassen würde, ist sowas geplant?

Ist mir nicht bekannt. Das Problem dabei wäre, dass diese Methodik für eine _lange_ Zeit äußerst unzuverlässig wäre (weil eben nicht überall bzw. fast nirgends implementiert), was im Umfeld der Sicherheit praktisch nutzfrei ist.

Also suche ich nach einer Alternative, aber ich sehe da wenig Aussicht auf Erfolg.

Die Autoren der Apache-Doku übrigens auch nicht.

Eine Möglichkeit wäre ja, wenn man aus der Passwortdatei den User kurzfristig entfernt,

Naja. Mindestens einen Request lang die Zugangsdaten ablehnt. Der Browser wird dann allerdings erneut die Eingabe anbieten, was auch nicht das Gelbe vom Ohr ist.

ich hatte erst dran gedacht [...]

Jiautsch. Ganz ehrlich: Finde Dich lieber mit der Nichtexistenz einer vernünftigen Lösung ab. Deine Versuche sind zwar recht weit gedacht, haben aber allesamt ihre Tücken und Fallstricke, die insbesondere an recht freizügiger Implementierungsmöglichkeit bei den Clients hapern. Du kannst hier nicht jede Verhaltensweise existierender und zukünftiger(!) Clients vorhersehen.

Dann könnte ich nämlich nach header() ein sleep(10) einfügen und danach die Änderung rückgängig machen.

Jiautsch. Kids, don't do this at home.

Was haltet Ihr davon? Wie würdet Ihr das machen?

Ich würde in Bugzilla einen Logout-Button vorschlagen. Wenn in Mozilla sowas implementiert wird, wird sich auch Microsoft in absehbarer Zeit Gedanken darüber machen.

Cheatah

[Henryk Plötz]

Moin,

Nein, wäre es nicht. Wo soll die hin? Wo stört sie nicht, auch zumal sie fast immer deaktiviert ist?

Mozilla hat doch eh einen Password Manager für gespeicherte Passwörter. Der könnte doch auch für Passwörter im RAM umgemodelt werden.

Naja. Mindestens einen Request lang die Zugangsdaten ablehnt. Der Browser wird dann allerdings erneut die Eingabe anbieten, was auch nicht das Gelbe vom Ohr ist.

Zumal mindestens ein Browser (lynx war es glaubich) das Passwort nach dem nächsten Request wieder hervorkramt. (lynx hat aber auch eine Auslogmöglichkeit.)

[Andreas Korthaus]

Hi Cheatah!

weil Browser dazu ungeeignet sind. Es sind die Browser-_Hersteller_, die es implementieren müssten ;-)

OK ;-)

Naja. Mindestens einen Request lang die Zugangsdaten ablehnt. Der Browser wird dann allerdings erneut die Eingabe anbieten, was auch nicht das Gelbe vom Ohr ist.

Ja, aber besser als nichts.

ich hatte erst dran gedacht [...]

Jiautsch. Ganz ehrlich: Finde Dich lieber mit der Nichtexistenz einer vernünftigen Lösung ab. Deine Versuche sind zwar recht weit gedacht, haben aber allesamt ihre Tücken und Fallstricke, die insbesondere an recht freizügiger Implementierungsmöglichkeit bei den Clients hapern. Du kannst hier nicht jede Verhaltensweise existierender und zukünftiger(!) Clients vorhersehen.

Muss ich das denn? HTTP ist "weitgehend" standardisiert implementiert, zumindest wird mir heute und in Zukunft jeder Client der einen 403-HEader bekommt von derselben Recource die er eigentlich im RAM als "Authetifiziert" gespeichert hat, das Login-Fenster öffnen. Das ausloggen klappt also durchaus. Nur muss ich dann dafür sorgen dass der User dann nicht für immer ausgeschlossen ist. Ich habe gerade mal ein bisschen mit dem Apachen rumexperimentiert, meine beiden angedachten Wege kann ich wohl vergessen, der 1. gefällt mir einfach nicht wegen der notwendigen Zwischenseite und dann noch dieser user:pass@ Syntax, dass will ich nicht, und auch dass Passwort im Klartext im Quelltect und damit im Cache des Browsers steht ist schlecht.
Die 2. Version scheitert daran, dass ich gerade einen Denkfehler gemacht habe, der Apache _muss_ ja erst den 403 senden damit es auch funktioniert, und 2 Statuscodes in einem Response, das sind ja gleich 2 Wünsche auf einmal, das wird wohl nicht gehen ;-)

Bliebe da noch die Timeout-Variante:

Dann könnte ich nämlich nach header() ein sleep(10) einfügen und danach die Änderung rückgängig machen.
Jiautsch. Kids, don't do this at home.

Wieso? Was um Himmelswillen soll da probleme bereiten? Von  mir aus setze ich den Timeout auf 60 Sekunden, der Request wird niemals so lange auf sich warten lassen, und wenn doch, dann kann ich den Request ja auf eine spezielle Seite leiten die erklärt dass es nicht funktioniert hat und dass man es nochmal versuchen solte, oder den Browser bitte komplett schließen oder so. Aber dazu wird es mit Sicherheit niemals kommen. Und wenn doch ist es zwar unschön aber sonst nichts.

Ah - neue Idee ;-)

Gruppen! Der Benutzer fliegt einfach aus einer bestimmtem Gruppe. Ah, das ist gut, wie wärs damit:

Jeder User ist in der gruppe "users", und wenn er sich einloggt wird dieser User der gruppe "online" hinzugefügt, die Gruppe "users" darf nur auf ein Script zugreifen, wenn der User sich also einloggt, wird dieses Script aufgerufen welches diesen user der Gruppe "online" hinzufügt, und einen location-header zurückschickt, der zur eigentlichen Startseite, oder der ursprünglich angefragten Recource leitet. Dann ist er "online" und kann tun und lassen was er will. Dann klickt er irgendwann auf logout und das Logout-Script wird aufgerufen, welches ihn aus der Gruppe "online" entfernt, hm, aber jetzt ist er aber noch drin, hm, schlecht :-(

Das Problem bleibt das alte denke ich, oder hat jemand ne Idee wie man diese Gruppen hierfür irgendwie ausnutzen könnt?

Hm, hm, hm, wenn ich doch PHP als Modul verwenden könnte, dann wäre das gar kein Problem, denn dann würde ich hiermit die Authentifizierung machen und hätte etwas andere Möglichkeiten.

Naja, aber so schnell gebe ich nicht auf ;-)

Ich kann ja auch einfach einen 401-Header(sorry, hatte das gerade mit 403 verwechelt) vom PHP-Script senden:

header("WWW-Authenticate: Basic realm="secret"");
header("HTTP/1.0 401 Unauthorized");
exit;

Naja, habe ich zumindest gedacht, aber als Ausgabe bekomme ich einen 500-Stauscode mit folgendem fehler in der Error.log:

malformed header from script. Bad header=HTTP/1.0 401 Unauthorized:

Heißt das httaccess und eine eigene Variante vertragen sich  nicht so? Oder liegts an HTTP1/0?

Ich weiß dass ich nicht _die_ Lösung finden werde, sonst hätt sie jeder, aber ich will einen Logout, und wenn ich dazu meine Timeout Methode verwende - auch gut - wenn ich nichts besseres finde soll es eben so sein ;-)

Ernsthaft, auch wenn es nicht perfekt ist, ist es doch immer noch besser als nichts, oder? Wieso sollte es da Probleme geben?

Ich würde in Bugzilla einen Logout-Button vorschlagen. Wenn in Mozilla sowas implementiert wird, wird sich auch Microsoft in absehbarer Zeit Gedanken darüber machen.

OK, dann sage ich den Leuten "ist in Arbeit, voraussichtlich Juli 2006 wird das in den IE 8.1 implementiert, und wenn Sie dann wie gewohnt 4 Jahre später updaten sollten wir es mit ein bisschen Glück so gegen 2010 verwenden können..." ;-)

Viele Grüße
Andreas

[Henryk Plötz]

Moin,

HTTP ist "weitgehend" standardisiert implementiert, zumindest wird mir heute und in Zukunft jeder Client der einen 403-HEader bekommt von derselben Recource die er eigentlich im RAM als "Authetifiziert" gespeichert hat, das Login-Fenster öffnen.

Dann wäre er unsagbar kaputt. Das traut sich nichtmal die Redmond-Mafia.
Recommended Reading hierzu: RFC 2616, Abschnitt 10.4.4 "Authorization will not help and the request SHOULD NOT be repeated". (Ja, ich weiss, dass das seit Jahr und Tag in Selfhtml falsch drinsteht. Ja, Ich habe auch schon das Fehlerformular bemüht.)

[Michael Schröpl]

Hi Andreas,

malformed header from script. Bad header=HTTP/1.0 401 Unauthorized:

ist denn Deine Anwendung befugt, dem Apache vorzuschreiben, welche HTTP-Version der verwenden soll?

Ich weiß dass ich nicht _die_ Lösung finden werde, sonst hätt sie jeder, aber ich will einen Logout, und wenn ich dazu meine Timeout Methode verwende - auch gut - wenn ich nichts besseres finde soll es eben so sein ;-)

Es gibt fertige Lösungen für Dein Problem, unter Verwendung angemessener Technologien.

Ernsthaft, auch wenn es nicht perfekt ist, ist es doch immer noch besser als nichts, oder?

Es ist viel schlechter als das, was es schon gibt.

Viele Grüße
      Michael

[Michael Schröpl]

Hi Andreas,

Wieso implementieren die Browser eigentlich keine Möglichkeit eines Logouts für HTTP-Auth?

warum fragst Du das hier im Forum und nicht die jeweiligen Hersteller?

Noch schöner wäre allerdings ein HTTP-HEader der den Browser dazu veranlassen würde,

Das wäre keineswegs schöner. Die Initiative für ein Logout liegt beim Client, nicht beim Server.
Server Authentication ist kein Session-Protokoll - wenn Du ein solches verwenden willst, dann tu es auch.

ist sowas geplant?

Warum fragst Du das hier im Forum und nicht die jeweiligen Hersteller?

Ich fänd das gut.

Ich nicht. Ich fände es gut, wenn die diversen Hersteller HTTP/1.1 unterstützen würden - davon sind sie _weit_ entfernt.

Das Problem mit HTTP-Auth ist nämlich, das viele der sog. Entscheidungsträger keine Ahnung haben,

Das ist kein Problem der HTTP-Auth, sondern eines unserer gesamten Gesellschaft.

aber wissen dass es gut ist wenn man sich aus einer Anwendung ausloggt, so dass wenn man
seinen Arbeitsplatz kurz verläßt nicht jeder Zugriff erlangen kann.

Dafür gibt es andere Mechanismen - beispielsweise die applikationsübergreifende Sperrung des gesamten Arbeitsplatzes.
Gerade _weil_ dieser Effekt in beliebig vielen Applikationen benötigt würde, macht es keinen Sinn, ihn in jeder dieser Applikationen einzubauen, wenn man es auch im Betriebssystem (GUI-Manager) tun kann.

Und diese Leute glauben man ist blöd wenn man sowas nicht kann

Dann kläre sie auf, daß es alle anderen auch nicht können.

Also suche ich nach einer Alternative, aber ich sehe da wenig Aussicht auf Erfolg.

Ich auch.

Eine Möglichkeit wäre ja, wenn man aus der Passwortdatei den User kurzfristig entfernt,

Grusel. _Dafür_ willst Du eine Schreib-Synchronisation bauen?

Und wann soll diese Synchronisation denn greifen?
Falls Du dazu einen Logout-Button in einer HTML-Seite verwenden willst, dann hast Du eine allerzweiundvierzigste Methode erfunden, Sessions zu emulieren.

Du versuchst gerade, mit einem Schraubenzieher einen Nagel in die Wand zu schlagen.

Was haltet Ihr davon? Wie würdet Ihr das machen?

Verwende eine bereits existierende Session-Implementierung Deiner Wahl.
HTTP-Authentication ist ohnehin nicht das, was Du haben willst - denn es liefert Dir nicht nur kein Logout, sondern vor allem auch gar kein (gegenseitig ausschließendes) Login!

Viele Grüße
      Michael

[Henryk Plötz]

Moin,

Das Problem mit HTTP-Auth ist nämlich, das viele der sog. Entscheidungsträger keine Ahnung haben, aber wissen dass es gut ist wenn man sich aus einer Anwendung ausloggt, so dass wenn man seinen Arbeitsplatz kurz verläßt nicht jeder Zugriff erlangen kann.

Der korrekte Weg wäre das Sperren der Arbeitsstation. Ich hoffe doch, dass man allen seinen Mitarbeitern in einer Firma einhämmert, dass sie _immer_ die Arbeitsstation sperren müssen, wenn sie sie verlassen. Auch wenn es nur für 5s an das andere Ende des Raumes geht. Strg-Alt-Entf Enter muß zum Reflex werden, der vor dem Aufstehen ausgelöst wird.

Also suche ich nach einer Alternative, aber ich sehe da wenig Aussicht auf Erfolg.

Man könnte mit Digest Access Authentication was basteln, indem man eine Art Session-ID im opaque-Feld an den Browser gibt und diese beim Ausloggen invalidiert. Leider unterstützt der Internet Explorer diese Authentifizierungsform nicht korrekt.