HTTP-Auth Logout

[Sven Rautenberg]

Moin!

Ja, ich will dem User die Möglichkeit(!) bieten sich aus der Anwendung auszuloggen, so dass man mit dem Browserfenster ohne Eingabe der Benutzerdaten nichts mehr anfangen kann. Auf der anderen Seite will ich Benutzern die Möglichkeit(!) bieten, Zugangsdaten bequem abzuspeichern.

Ok, und die Antwort auf diese Frage sind eben ganz normale Sessions. Das Abspeichern von Anmeldedaten ist ein Feature des verwendeten Browsers, welches sowohl mit HTTP-Auth, als auch mit Formularen funktioniert. Das Logout funktioniert aber nur mit Sessions einfach und zufriedenstellend.

User A hat sich eine teure Tastatur gekauft um sich nicht allew Passwörter merken zu müssen... udn speichert die gerne ab.

Hab ich noch nie gesehen. Und die Frage ist, auf welche Eingabemöglichkeiten so eine Tastatur reagiert.

Allerdings: Mit dem richtigen Browser ist das eben gerade kein Argument mehr, weil _der_ sich die Anmeldedaten speichern kann. Der Zugriff auf den Rechner per Codekarte kann ja trotzdem gesperrt werden.

User B muss sich nachdem er mit einer Anwendung gearbeitet hat immer sofort abmelden, damit niemand anders Zugriff bekommt.

beide haben verschiedene Interessen, aber vielleicht verwenden beide meine Software, also muss die Softwar beide zufrieden stellen können.

Das ist eben sehr die Frage, ob diese Interessen wirklich nur mit HTTP-Auth zufriedengestellt werden können. Ich meine: Nein. :)

Und ja, User A sollte grunsätzlich kein Passwörter speichern,  udn ja, User B könnte nauch eben das Fenster schließen, nur ist es nicht meine Aufgabe alle Welt zu erklären wie ein Computer und wie das Internet funktioniert bzw. alle entsprechend meinen Vorgaben zu erziehen. Entweder die Software kann das was die User wollen, oder eben nicht. User überzeugen geht nzur bis zu einem gewissen Grad. (Und HTTP-AUTH ist sicher nicht die einzige "Front" an der man zu kämpfen hat da gibt es wichtigeres...)

Die Kernfrage ist eben: Warum HTTP-Auth für etwas verwenden, was HTTP-Auth grundsätzlich nicht leisten kann. Man kann sich eben nur anmelden, aber nicht wieder abmelden. Das Abmelden ist extrem browserabhängig.

Du kriegst vermutlich noch ein weiteres DAU-Problem mit deiner Lösung nicht in den Griff: Wenn du dem Browser eine neue 401 schickst, die dieser noch nicht kennt, wird er wieder nach einem Passwort fragen. Wenn der Benutzer nicht geschult ist, wird er wieder sein Passwort eingeben. Und damit bist du genauso schlau, wie vorher. Du kannst auch keine Rückmeldung an den Benutzer liefern auf einer Seite, die ihm bestätigt, dass er jetzt abgemeldet ist. Denn diese Seite kannst du rein technisch erst mit dem 401 zusammen schicken - die wird der Benutzer aber nicht sofort sehen, sondern zunächst nur den Passwort-Dialog. Er muß ihn abbrechen, um zur "Logout ok"-Seite zu kommen.

Das sind alles Probleme, die du mit Sessions nicht hast. Zumal du ja sowieso Sessions verwendest und HTTP-Auth nur dazu mißbrauchst, Username und Passwort übermittelt zu bekommen.

Da wäre es eigentlich wesentlich einfacher, wenn du das Login in einem kleinen Unterverzeichnis abwickeln würdest, welches meinetwegen sogar mit .htaccess geschützt ist (PHP-401-Header tuns aber natürlich auch), aufgrund dieser Daten eine Session eröffnet wird, die für die gesamte Domain gilt, und im restlichen Bereich nur noch mit dieser Session arbeitest. Dann kannst du den Realm gerne unique machen (meinetwegen mit einer neuen Session-ID) - bei jeder Anmeldung neu, weil die Anmeldung nur einmal vorkommt. Und das Logout ist dann überall möglich und zerstört die Session, verhindert somit jeglichen weiteren Kontakt mit dem Server - und das Login ist trotz der gespeicherten Daten nicht möglich, weil der Realm nicht mehr paßt.

Diese Lösung ließe sich außerdem ganz hervorragend an eine bestehende Session-only-Lösung dranstricken, denn die Authentifizierung dient ja wirklich nur zum Übertragen der Userdaten.

Wieso verwenden dann andere Entwickler überhaupt die Session-Login Variante wenn das ganez so einfach mal eben "zwischenmenschlich" lösbar ist? Übrigens kann man eingegeben Zugangdaten in HTML-Formularen ebenfals speichern.

Sie verwenden die Session-Variante, weil dort all diese Probleme von HTTP-Auth nicht auftreten. Sie können die zeitliche Gültigkeit einer Session kontrollieren, sie können simpelst ein Logout realisieren, sie können ebenso simpelst ein Login realisieren :), und sie können das Aussehen des Anmeldefensters nach eigenem Gusto variieren und der CI anpassen (auch nicht zu verachten, sowas wird hier im Forum immer mal wieder gefragt und gewünscht - mit HTTP-Auth geht das logischerweise aber nicht).

Session-Authentifizierung hat also einige Vorteile, die HTTP-Auth nicht hat. Session-Auth hat aber keine Nachteile gegenüber HTTP-Auth.

Ich wollte das eigentlich weniger grundsätzlich diskutieren, sondern ob das technisch mit einer HTML-Formular/Session Lösung ebenbürtig ist . Es sind vielleicht 10 Zeilen Code mehr, es ist eben ein alternativer Weg dasselbe zu erreichen, weil es eben das HTTP-Auth Fenster sein sollte. Die Frage ist nur - habe ich dasselbe erreicht?

Du benutzt grundsätzlich Sessions - alles, was an Sicherheitsüberlegungen stattfindet, ist also in diesem Punkt identisch zu bewerten.

Die Anforderung des Passwortes per HTTP-Auth funktioniert ebenfalls und ist sicherheitstechnisch nicht anders zu bewerten, als die Übermittlung von Formulardaten per POST.

Dass ich die Idee insgesamt nicht wirklich für gut befinde aufgrund der aufgetretenen Problemfälle, sollte deutlich geworden sein.

- Sven Rautenberg