nicht angemeldet
Hi Sven!
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.
Die ich ja habe...
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.
Genau. Daher verwende ich ja sessions ;-)
Ich verwende http-Auth nur einmalig für die erste Anmeldung, halt an Stelle des HTML-Anmeldeformulars (Spart auch ne Menge Traffic ;-)))
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.
http://www.cherrycorp.com/deutsch/advanced-line/tastatur-fingertip-id-board-g83-14000-14100.htm
aber hast Recht, doofes Beispiel, ging mir Prinzipiell um verschiedene Umgebungen der User, ich z.B. wohne alleine und niemand außer mir geht an meien Computer wenn ich nicht dabei bin, also speichere ich schonmal unwichtigere Passwörter.
Und die Frage ist, auf welche Eingabemöglichkeiten so eine Tastatur reagiert.
Fingerbdruck, Chipkarte, der Phantasie sind denke ich keine Grenzen gesetzt ;-) Von "Mission Impossible" & Co. kennt man da ja einige nette Schutzmechanismen :)
Allerdings: Mit dem richtigen Browser ist das eben gerade kein Argument mehr,
Ich will aber einen Kunden von meiner Web-Software überzeugen, und nicht dabei noch von einem anderen Browser, Nutzungsregelen, Email-Regeln.. überzeugen. Das mag in bestimmten Projekten Sinn machen, bei mir nicht.
weil _der_ sich die Anmeldedaten speichern kann. Der Zugriff auf den Rechner per Codekarte kann ja trotzdem gesperrt werden.
Die Leute besorgend sich ja gerade solche Hardware, eben weil sie nicht in der Lage sind auf kommunikativer Ebene entsprechende Richtlinien durchzusetzen, oder einfnach aus Bequemlichkeit.
Du hast vollkommen Recht - so sollte es nicht sein, aber ich muss mich nach den Kunden richten, und nicht die Kunden so umerziehen wie ich es für richtig halte. Ganz klar daf man nicht alles mitmachen, nur sehe ich in diesem Fall keinen einzigen Nachteil.
Das ist eben sehr die Frage, ob diese Interessen wirklich nur mit HTTP-Auth zufriedengestellt werden können. Ich meine: Nein. :)
Da halte ich dagegen : aber sicher doch ;-)
(bisher habe ich noch kein hinreichend "vernichtendes" Argument gelesen)
Die Kernfrage ist eben: Warum HTTP-Auth für etwas verwenden, was HTTP-Auth grundsätzlich nicht leisten kann.
Nein! Diese Fragestellung impliziert die Lösung _meiner_ Frage und das auf negative Weise. Denn gerade das will ich ja in diesem Thread herausfinden, kann HTTP-Auth sowas grundsätzlich nicht leisten? Im RFC steht ja sowas drin, zum einen dass Clients nach eien Authentifzierung annehmen sollen, dass sie sich bei jedem Request an den Host ohne vorherige Anfrage authentifizieren sollen, mit denselben Daten. Das Impliziert IMHO doch schonmal dass die Entwickler durchaus sowas wie eine "login-Session" im Hinterkopf hatten, denn welchen Sinn würde es sonst machen?
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.
Obeflächig passiert genau dasselbe mit Formular/Session.
Wenn der Benutzer nicht geschult ist, wird er wieder sein Passwort eingeben.
Worein? Der Ablauf ist folgender:
1. Usr klickt auf Link "login"
2. User bekommt 401 und es öffnet sich das Auth-Fenster
3. User gibt Zugangsdaten ein
4. Server prüft Zugangsdaten und Loggt User bei Erfolg in Session ein. (jetzt kann user sich frei bewegen)
5. User klickt auf "logout"
6. Server erkennt Logout-Versuch, löscht Session und gibt "logged Out" HTML-Seite aus
7. User bekommt "logged out" HTNMKL-Seite angezeigt und ist Fertig
erst wenn der UEser sich erneut einloggen will, oder einen Link innerhalb des geschützten Bereiches aufruft.. erst dann kommt ein 401 um sich erneut einzuloggen.
Und damit bist du genauso schlau, wie vorher.
Wie gesagt, damit der User das passwort nach dem logout erneut eingibt, muss er sich vorher aktiv neu einloggen!
Du kannst auch keine Rückmeldung an den Benutzer liefern auf einer Seite, die ihm bestätigt, dass er jetzt abgemeldet ist.
Doch kann ich! Ich verwende nicht .htaccess, sondern PHP, daher habe ich die volle Kontrolle über das was der Server dem Client schickt.
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.
nein ;-) An dieser Stelle schicke ich eine Seite "Passwort stimmt nicht..."
Wenn das so wäre, dann würde das ganze für mich überhaupt kleien Sinn machen. Gehe nochmal auf: http://tmp.knet-systems.de/auth.php und lies ganz genau was da steht wenn Du Dich einloggst, und wenn Du Dich ausloggst. An Stelle des Textes kommen bei mir dann natürlich entsprechende Seiten. Oder liegt es an Opera? Das wäre nicht so gut, hast Du es mal mit IE oder Mozilla probiert?
Das sind alles Probleme, die du mit Sessions nicht hast.
a) sehe noch kein Probleme, und
b) habe ich Sessions ;-)
Zumal du ja sowieso Sessions verwendest und HTTP-Auth nur dazu mißbrauchst, Username und Passwort übermittelt zu bekommen.
Was ist sonst der Sinn von HTTP-AUTH?
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.
Mache ich ja! Einmal Login mit HTTP-Auth, der Login-Status wird dann in der Session gespeichert.
Dann kannst du den Realm gerne unique machen (meinetwegen mit einer neuen Session-ID) - bei jeder Anmeldung neu, weil die Anmeldung nur einmal vorkommt.
Das mache ich ja, der Unterschied ist nur, das ich mich bemühe ein erstmaliges Login zu erkennen, um hier denselben REALM zu verwenden, um dem Anwender die möglichst weitgehende Kontrolle über die Features seines Browsers zu erlauben.
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.
Genau das mache ich doch ?!
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.
ja ;-)
Sie verwenden die Session-Variante, weil dort all diese Probleme von HTTP-Auth nicht auftreten.
Bisher habe ich in meinem Konzept keine Probleme erkennen können.
Sie können die zeitliche Gültigkeit einer Session kontrollieren,
kann ich auch
sie können simpelst ein Logout realisieren,
kann ich auch, mein vollständiger Logout sieht so aus:
if($_REQUEST['action'] == 'logout') {
$_SESSION = array();
session_destroy();
display_logout();
}
sie können ebenso simpelst ein Login realisieren :),
das ist der kleien Unterschied. Ohne mein Bestreben den ersten Login zu erkennen wäre die Sache fast genauso einfach.
Aber unter: http://tmp.knet-systems.de/auth_source.php
sind das nur gut 20 Zeilen, was mich nicht wirklich überfordert.
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).
Ja, aber ich finde das Image dieser anpassbaren Logins ist auch nicht mehr das was es mal war. Ist doch wirklich so dass es auf wirklich jeder Seite so einen Login Bereich gibt, gepaart mit x Newslettern...
Und der Hauptgrund warum so selten HTTP-Auth verwendet wird ist der fehlende Logout, was es für die meisten Anwendungen unbrauchbar macht. Außerdem fehlt es auf einigen Seiten an der Kontrolle der HTTP-Header.
Dass ich die Idee insgesamt nicht wirklich für gut befinde aufgrund der aufgetretenen Problemfälle, sollte deutlich geworden sein.
Es wurde deutlich, nur versteh ich die Problemfälle nicht da ich bisher nichts davon rekonstruieren konnte. Für mich sind das 2 komplett identische Anmeldeverfahren, nur dass Du beim einen ein HTML-Formular verwendest welches Du selber anpassen kannst, beim anderen halt das HTTP-Auth Fenster des Browsers verwenden kannst.
Und mir persönlich gefällt es durchaus die Wahl zwischen beiden Varianten zu haben, was bisher eigentlich von allen ausgeschlossen wurde. Zumindest bisher habe ich noch keinen Anhaltspunkt an meinem Script zu zweifeln. Das habe ich erst dann wenn jemand entweder den Passwort-Schutz umgehen kann, oder wenn das ganze in einem Browser nicht anständlich funktioniert.
Grüße
Andreas