HTTP-Auth Logout

[Andreas Korthaus]

Hallo!

Ich habe die Auflage bekommen in meinem aktuellen Projekt eine Logout-Funktion für die verwendete basic authentication zu implementieren.

Naja, zunächst sagen alle "das geht nicht...", aber ich habe ja nicht nur HTTP-alleine zur Verfügung. Ich verwende neben HTTP-Auth auch Sessions. Das versetzt mich in die Lage, zusätzliche Informationen zum Client zu speichern, mit dessen Hilfe zusammen mit einigen Annahmen und der Möglichkeit eigene Header zu senden, ich glaube dass ein Logout möglich ist.
Mit Logout meine ich, dass wenn der User in der Anwendung auf einen Button "logout" klickt, dass er dann auf eine Seite "sie wurden ausgeloggt..." weitergeleitet wird, und bevor er wieder die auf irgendwelche der geschützten Seite zugreifen kann wieder neue Daten in das HTTP-Auth Popup eingeben müssen, auch wenn das Browserfenster nicht geschlossen wurde.

Im Prinzip wäre das ganz einfach wenn sich alle Browser an die HTTP-Spec halten würden, aber das tun sie nicht, zumindest der Mozilla in diesem Fall. Gemäß rfc2616(HTTP/1.1) und rfc1945(HTTP/1.0) sollen die Clients, wenn Sie 401 als Response erhalten nachdem(!) sie bereits an selbigen host/realm Auth-Daten gesendet haben, diese als ungültig betrachten, und eine neue Eingabe der Daten anfordern. Das macht der IE auch, nur der Mozilla sendet die Daten einfach nochmal. Also reicht es nicht bei klick auf "Logout" einfach einen 401-Header zu senden. Die einzig zuverlässige und IMHO kein Protokoll verletzende Möglichkeit die ich gefunden habe, ist das Verändern des realms in diesem Fall, das heißt ich füge einen unique-String in den realm-string ein, so dass der Client keine Daten mehr aus seine Cache verwendet und den User erneut zur Authentifzierung auffordert. Als Unique-String verwende ich die aktuelle Uhrzeit, sekundengenau.

Das hat aber den Nachteil, dass der user seine Auth-Daten nicht speichern kann wenn er das möchte, da jedesmal neue Daten angefordert werden und der Client davon ausgeht, dass es sich um ein völlig anderes Projekt handelt.
Daher habe ich mir überlegt, wenn der User sich erstmalig einloggt, erkenne ich das daran, dass er im Gegensatz zu einem "relogin" (2. Login innerhalb einer "Browsersession")_keine_ Auth-Daten mitsendet. Das heißt am Vorhandensein der HTTP-Auth Daten kann ich sehen ob es sich um eine neue oder eine laufende "Browserfenstersession" handelt.

Ich habe das Script mal hochgeladen, wäre nett wenn Ihr mal ausprobieren könntet ob es bei euch auch funktioniert oder eben nicht. Mich interessiert auch was Ihr allgemein ganz realistisch davon haltet.

Das Script: http://tmp.knet-systems.de/auth.php
Der Source: http://tmp.knet-systems.de/auth_source.php

Aufgrund von Änderungen am Namenserver kann es sein dass die Dateien nicht sofort gefunden werden.

Daher der Code schonmal vorab:

Viele Grüße
Andreas

<?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...
    }
?>

[Andreas Korthaus]

Hallo!

Das Script: http://tmp.knet-systems.de/auth.php
Der Source: http://tmp.knet-systems.de/auth_source.php

Ich habe inzwischen noch einige Kleinigkeiten geändert, so dass es auch mit Firebird funktioniert(welcher IMHO an einer weiteren Stelle das HTTP-Protokoll falsch implementiert hat, er versucht jeden Request zuerst ohne Auth-Daten, egal was kommt), und die Session wird jetzt ganz  gelöscht. Also bei mir funtioniert das jetzt in allen getesteten Browsern(IE 5+6, Mozilla 1.3, Firebird 0.6.1).

Eines habe ich allerdings noch nicht bedacht, ohne Cookies funktioniert das ganze überhaupt nicht. Im Prinzip soll bei der Anwendung eh die "Akzeptanz von Cookies" vorgeschieben sein, nur würde ich es trotzdem, rein prinzipiell, auch ohne Cookies hinbekommen. Da habe ich jetzt wirklich einiges probiert, wirklich hinbekommen habe ich es noch nicht.

Naja.

Grüße
Andreas

[Henryk Plötz]

Moin,

Vorweg: Dir ist doch hoffentlich klar dass du dir damit ein <I> für einen Tipp&Trick, wenn nicht gar einen Feature-Artikel eingefangen hast? ;-)

Ich habe inzwischen noch einige Kleinigkeiten geändert, so dass es auch mit Firebird funktioniert(welcher IMHO an einer weiteren Stelle das HTTP-Protokoll falsch implementiert hat, er versucht jeden Request zuerst ohne Auth-Daten, egal was kommt),

Nein, nicht wirklich. Digest Authentication erfordert sogar Informationen aus einem vorangegangenen 401. Oder habe ich dich jetzt falsch verstanden?

Eines habe ich allerdings noch nicht bedacht, ohne Cookies funktioniert das ganze überhaupt nicht.

Ja, was ich da noch nicht ganz verstehe ist warum du überhaupt HTTP Auth nimmst, wenn du eh Sessions hast? Ist es dir wirklich so wichtig dass die Zugangsdaten bei jedem Request im Klartext durch die Leitung rauschen?

[Andreas Korthaus]

Hi!

Vorweg: Dir ist doch hoffentlich klar dass du dir damit ein <I> für einen Tipp&Trick, wenn nicht gar einen Feature-Artikel eingefangen hast? ;-)

Wenn denn am Ende rauskommt dass es so geht wie ich es mir vorstelle, dann gerne(viel fehlt da nicht mehr) ;-)

Ich habe inzwischen noch einige Kleinigkeiten geändert, so dass es auch mit Firebird funktioniert(welcher IMHO an einer weiteren Stelle das HTTP-Protokoll falsch implementiert hat, er versucht jeden Request zuerst ohne Auth-Daten, egal was kommt),

Nein, nicht wirklich. Digest Authentication erfordert sogar Informationen aus einem vorangegangenen 401. Oder habe ich dich jetzt falsch verstanden?

Bei Basic Authentication sollten die Clients, nachdem sie sich eienmalk für ein realm/host authentifiziert haben annehmen, dass sie sich im gesamten Verzeichnis und den Unterverzeichnissen authentifizieren müssen, _ohne erneute Aufforderung_ hierzu. Mozilla 1.3, IE... daie ,machen das auch alle so, nur der Firebird nicht, der sendet niemals 2 Requests mit Auth-Daten hintereinander. Er veruscht es immer erst ohne, wenn ein 401 kommt kommt zwar keine Aufforderung zur Passworteingabe, das macht er dann automatisch nachdem na sich einmal für den realm manuell authentifiziert hat, und eben dieses Verhalten macht das ganez so kompliziert. Man muss erkennen ob es sich bei dem Request um einen manuellen, also nach Eingabe von Authdaten handelt, oder um einen automatischen. Und da reagieren die Browser insgesamt unterschiedlich, und am schlimmsten ist halt der Firebird, da er IMHO das HTTP-Protokoll an den meisten Stellen mißachtet, bzw. geht es dabri nicht um MUSTs sondern um SHOULDs, aber ich sehe keine Grund wieso der Firebird hier den Empfehlungen nicht entspricht. Ich hatte das rein zufällig mal gemerkt als ich neue Statistiken für eien Testseite aufgesetzt hatte und mich dann wunderte, warum ich ungefähr genau so viele 401 Statuscodes habe, wie 200er.

Eines habe ich allerdings noch nicht bedacht, ohne Cookies funktioniert das ganze überhaupt nicht.

Ja, was ich da noch nicht ganz verstehe ist warum du überhaupt HTTP Auth nimmst, wenn du eh Sessions hast?

Das wüßte ich auch gerne ;-)
Es soll halt das bekannte HTTP-Auth Fenster zur Authentifizierung dienen.

Ist es dir wirklich so wichtig dass die Zugangsdaten bei jedem Request im Klartext durch die Leitung rauschen?

Wozu gibt es SSL ;-)

Nochmal zurück zu "ohne Cookies". Das ist wirklich nochmal ne Ecke komplizierter, und am besten macht man das glaube ich wie folgt:
Ich ermitel bevor ich mich überhaupt um Authentifizierung gucker erstmal "Statusvariablen" für die aktuelle Session, und zwar folgende:

$_SESSION['status']['newlogin'] = (0|1)

$_SESSION['status']['relogin'] = (0|1)

$_SESSION['status']['param'] = (html|cookie)

Wie ich die ersten beiden ermittle ist klar(das mache ich ja bereits im Script), den 3. ermittle ich wie folgt:

if (!isset($_REQUEST[session_name()])) {
    header('Location: '.$_SERVER['SCRIPT_URI'].'?'.SID.'&'.$_SERVER['QUERY_STRING']);
    exit;
}
else if (!isset($_SESSION['status']['param'])) {
    if (isset($_COOKIES[session_name()])) {
        $_SESSION['status']['param'] = cookie;
    }
    else {
        $_SESSION['status']['param'] = html;
    }
}

Jetzt weiß ich vorher was genau es für ein Request ist, das muss ich jetzt "nur noch" einbauen.

Grüße
Andreas

[Andreas Korthaus]

Hallo nochmal!

So, jetzt bin ich zufrieden ;-)

Mit allen von mir getesteten Varianten funktioniert es jetzt einwandfrei. Ich habe es doch nicht ganz so gelöst wie oben beschreiben, eher etwas einfacher, hier nochmal die Links:

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

Was haltet Ihr davon? Haben wir hier einen "Hacker" der es schafft den Schutz zu umgehen (also sich nach einem Logout ohne manuelle Eingabe von Zugangsdaten Zugang zum "login-Bereich" verschaffen kann)? Oder gibt es sogar jemanden hier in der "Elite" der gar mit bloßem Auge einen Fehler oder ein Risiko sehen kann? ;-)

Die Gefahr ist ja, das die Auth-Daten im Cache des Browsers liegen, solange das Fenster bzw. der gesamte Browser geöffnet ist. Bei den meisten Browsern(u.A. IE) kann man den Wert mit einem einfachen 401er Response-Header löschen, bei anderen geht das nicht, da bleibt einem nur der Weg über einen neuen(unique) Realm, dazu kann es dann halt noch keine im Cache gespeicherten Daten geben.
Im Prinzip sollte es ausreichen anhand der Session-Daten zu entscheiden ob der User sich neu einloggen soll oder nicht. Aber da einige Brower wie gesagt auf ein 401 Response nicht so reagieren wie sie IMHO sollten, muss man im Falle eines erneuten Logins im Verlaufe einer Browsersession einen anderen Realm senden. Damit es wenigstens am Anfang immer denselben Realm gibt unterscheide ich noch zwischen einer ganz neuen Session, und einer "relogoin" Session, nur bei letzterer bekommt der User einen unique Realm.
Das Problem mit dem Firebird kann man aber zum Glück doch ausklammern, da er sich ja vor allem mit einem Request in der Session Authentifziert.

Meint Ihr das hätte Potential für einen TuT?
Oder ist das für die "Elite" hier doch eher vergleibar mit einem "Rechtsklick-Verhindern" Beitrag?

Das mit dem Unique-Realm gefällt mir nicht wirklich, ich überlege auch schon mit zusätzlichen Header-Angaben zu arbeiten, z.B. "opaque" scheint mir sehr gut geeignet, mal sehen, und auch mal sehen ob und wie die Clients das unterstützen. Oder hat jemand noch andere Ideen?

Ich verstehe nicht wirklich was es für einen Sinn macht sowas kompexes wie die HTTP-Authentifzierung zu entwickeln, und dann so eine simple Kleinigkeit wie das ausloggen nicht wirklich zu implementieren, denn ein Logout ist ein wichtiges Sicherheitsmerkmal wenn es um Authentifzierung geht. Deswegen wird HTTP-Auth auch so selten eingesetzt(gegenüber HTML-Formularen + Sessions zu Authentifzierung).

Viele Grüße
Andreas

PS: kann das vielleicht mal jemand mit Netscape4 und Opera testen? Den habe ich nämlich gerade nicht hier, Danke!

[Christian Seiler]

Hallo Andreas,

Auch wenn ich gerade nicht den Nerv habe, mich damit ausführlich zu beschäftigen:

Ich verstehe nicht wirklich was es für einen Sinn macht sowas kompexes wie die HTTP-Authentifzierung zu entwickeln, und dann so eine simple Kleinigkeit wie das ausloggen nicht wirklich zu implementieren,

Beschwere Dich: http://bugzilla.mozilla.org/

Viele Grüße,
Christian

[Andreas Korthaus]

Hi Christian!

Auch wenn ich gerade nicht den Nerv habe, mich damit ausführlich zu beschäftigen:

Hat etwas gedauert bis ich da so halbwegs durchgestiegen bin, und mir sicher war wie die Verschachtelungen genau auszusehen haben ;-)

Ich verstehe nicht wirklich was es für einen Sinn macht sowas kompexes wie die HTTP-Authentifzierung zu entwickeln, und dann so eine simple Kleinigkeit wie das ausloggen nicht wirklich zu implementieren,

Beschwere Dich: http://bugzilla.mozilla.org/

Wenn es denn ein Bug ist, ich befürchte fast das ist alles so gewollt.

Ja, das ist das eine, das andere ist dass die Entwicker der RFCs mit zu wenig Nachdruck entsprechendes fordern, am besten extra Logout-Mechanismen, sondrn im Gegenteil wurde den Entwicklern ausgerecvhnet an dieser Stelle Freiraum eingeräumt. Mit einem vernünftigen Logfout was wirklich einfach zu implementieren wäre, würde das mögliche Anwendungsgebiet von HTTP-Auth erheblich anwachsen.

Naja. Mir ist eben aufgefallen, dass "opaque" zu Digest Auth gehört, was man ja nicht ganz so einfach mit PHP zu implementieren ist, aber ich halte auch das für möglich, vermutlich besteht die Hauptschwierigkeit darin das Passwort zu ermitteln, aber dessen Verschlüsselung funktioniert ja mit dokumentierten Verfahren, ich werde es sicher auch ausprobieren ;-)
Denn wenn ich dasrichtig gelesen habe bietet Digest-Authentifzierung ein ganz feines Schmankerl: Man kann sich für mehrere Hosts auf einmal einloggen, das hieße forum.de.selfhtml.org/my selfcomunity.teamone.de/my... das wäre ja nicht schlecht, ich schau mir das jedenfalls mal genauer an.

Wie war das noch mit den Clients und Digest-Auth? IMHO ab 5er Versionen unproblematisch, nur der IE hatte da die ein oder andere Macke, oder?

Grüße
Andreas

[Christian Seiler]

Hallo Andreas,

Beschwere Dich: http://bugzilla.mozilla.org/

Wenn es denn ein Bug ist,

Nein, ein mangelndes Feature. Wenn der Browser die Authentifizierung direkt mit dem Server aushandelt, dann gehört das Logout-Feature direkt in den Browser. IMHO.

ich befürchte fast das ist alles so gewollt.

Ich hoffe es nicht.

das andere ist dass die Entwicker der RFCs mit zu wenig Nachdruck entsprechendes fordern,

ACK.

am besten extra Logout-Mechanismen,

Nein. Was spricht dagegen in einen Browser einfach einen Knopf "HTTP-Logout"  einzubauen?

Wie war das noch mit den Clients und Digest-Auth? IMHO ab 5er Versionen unproblematisch, nur der IE hatte da die ein oder andere Macke, oder?

Ja. Im Archiv gibt es einiges dazu, suche nach Henryk Plötz.

Viele Grüße,
Christian

PS: Ich sehe immernoch keinen Grund, bei Deiner Aufgabenstellung HTTP-Auth zu verwenden. Formular mit Passworteingabe sind inzwischen mehr zur Gewohnheit geworden wie HTTP-Auth-Fenster, daher zieht das Argument "gewohntes Fenster" nicht.

[Sven Rautenberg]

Moin!

PS: Ich sehe immernoch keinen Grund, bei Deiner Aufgabenstellung HTTP-Auth zu verwenden. Formular mit Passworteingabe sind inzwischen mehr zur Gewohnheit geworden wie HTTP-Auth-Fenster, daher zieht das Argument "gewohntes Fenster" nicht.

Insbesondere fällt mir der Widerspruch auf, der in Andreas' Argumentation liegt. Einerseits will er einen Logout hinkriegen, damit hinterher keiner anderer User mit demselben Browser mehr reinkommt. Andererseits ist der Unique Realm für ihn angeblich ein Problem, weil sich Browser dann die Anmeldedaten nicht mehr speichern können.

Diese ganze Geschichte mit den gespeicherten Passwörtern ist aber wirklich nur ein Benutzeraufklärungsproblem. Wer nämlich die Passwortspeicherfunktion seines Browsers verwendet (und das geht sowohl für Formulare als auch für HTTP-Auth), der birgt noch ein wesentlich höheres Risiko, als derjenige, der nach dem Nicht-wirklich-Logout eines normalen HTTP-Auth seinen Browser nicht schließt.

Wer aber ohnehin in einer Umgebung arbeitet, in der er seinen eigenen Rechner nicht aus den Augen lassen darf, weil sonst böse Elemente Mißbrauch betreiben können, der hat sowieso ganz andere Probleme, als einen nicht geschlossenen Browser.

Insofern versucht Andreas hier, mit aufwendigsten technischen Mitteln menschliche Probleme zu lösen, die technisch nicht lösbar sind.

- Sven Rautenberg

[Andreas Korthaus]

Hi!

Insbesondere fällt mir der Widerspruch auf, der in Andreas' Argumentation liegt. Einerseits will er einen Logout hinkriegen, damit hinterher keiner anderer User mit demselben Browser mehr reinkommt. Andererseits ist der Unique Realm für ihn angeblich ein Problem, weil sich Browser dann die Anmeldedaten nicht mehr speichern können.

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. Du darfst nicht beides direkt miteinander in Verbindung bringen, User A sitzt alleine im Büro sperrt wenn er geht die Tastatur mit Fingerabdruckscanner, User B sitzt in einem Großraumbüro und teilt sich ein Notebook mit der halben Abteilung...
User A hat sich eine teure Tastatur gekauft um sich nicht allew Passwörter merken zu müssen... udn speichert die gerne ab.
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.

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...)

Diese ganze Geschichte mit den gespeicherten Passwörtern ist aber wirklich nur ein Benutzeraufklärungsproblem. Wer nämlich die Passwortspeicherfunktion seines Browsers verwendet (und das geht sowohl für Formulare als auch für HTTP-Auth), der birgt noch ein wesentlich höheres Risiko, als derjenige, der nach dem Nicht-wirklich-Logout eines normalen HTTP-Auth seinen Browser nicht schließt.

Es kommt immer drauf an wer der "Jemand" ist. Beim einen ist das Speichern unverantwortlich, beim anderen nicht so schlimm, selbiges gilt fürs ausloggen.

Insofern versucht Andreas hier, mit aufwendigsten technischen Mitteln menschliche Probleme zu lösen, die technisch nicht lösbar sind.

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.

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?

Grüße
Andreas

[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

[Andreas Korthaus]

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

[Andreas Korthaus]

Hi!

PS: Ich sehe immernoch keinen Grund, bei Deiner Aufgabenstellung HTTP-Auth zu verwenden. Formular mit Passworteingabe sind inzwischen mehr zur Gewohnheit geworden wie HTTP-Auth-Fenster, daher zieht das Argument "gewohntes Fenster" nicht.

Soll auch vertrauenserweckender wirken als die Formulare die Du ja inzwischen auf fast jeder noch so popeligen Internetseite hast. Naja. Die Arbeit habe ich mir ja jetzt gemacht, daher würde mich interessieren ob auch praktische Argumente dagegensprechen oder nur theoretische.

Viele Grüße
Andreas

[Sven Rautenberg]

Moin!

Denn wenn ich dasrichtig gelesen habe bietet Digest-Authentifzierung ein ganz feines Schmankerl: Man kann sich für mehrere Hosts auf einmal einloggen, das hieße forum.de.selfhtml.org/my selfcomunity.teamone.de/my... das wäre ja nicht schlecht, ich schau mir das jedenfalls mal genauer an.

Wie war das noch mit den Clients und Digest-Auth? IMHO ab 5er Versionen unproblematisch, nur der IE hatte da die ein oder andere Macke, oder?

Vergiß das ganz schnell wieder. Der IE implementiert Digest-Auth falsch. Er berücksichtigt einen eventuellen URL-Parameter nicht in der Berechnung der Hashes, die ausgetauscht werden - und das Forum ist voll mit Hashes. Du müßtest Digest also bewußt falsch implementieren - dann hätte es aber nur noch relativ wenig Sinn.

- Sven Rautenberg

[Andreas Korthaus]

Hi!

Vergiß das ganz schnell wieder. Der IE implementiert Digest-Auth falsch.

Was spricht dagegen dass User die sich einloggen wollen Mozilla verwenden müssen? Einer muss ja mal mit dem "Aufräumen" anfangen!

*SCNR*

Grüße
Andreas

[Henryk Plötz]

Moin,

Naja. Mir ist eben aufgefallen, dass "opaque" zu Digest Auth gehört, was man ja nicht ganz so einfach mit PHP zu implementieren ist, aber ich halte auch das für möglich, vermutlich besteht die Hauptschwierigkeit darin das Passwort zu ermitteln, aber dessen Verschlüsselung funktioniert ja mit dokumentierten Verfahren, ich werde es sicher auch ausprobieren ;-)

Ja, opaque von Digest Auth zu benutzen hätte ich dir als nächstes vorgeschlagen. Ich kann sogar eine fast vollständige (qop=auth-int kriege aufgrund konzeptioneller Probleme mit PHP nicht auf der Serverseite hin, deswegen habe ich es auch nicht für den Client eingebaut, obwohl das wohl nur ein paar Zeilen mehr wären; das Apache-Modul kann das aber auch nicht) Implementierung der Client- und der Serverseite von Digest Auth in PHP bieten.

Wie war das noch mit den Clients und Digest-Auth? IMHO ab 5er Versionen unproblematisch, nur der IE hatte da die ein oder andere Macke, oder?

Nein, Digest Auth ist in allen existierenden IE-Versionen kaputt: Er unterstützt keine Challenges ohne qop, was er eigentlich nach RFC 2617 aus Abwärtskompatibilitätsgründen zu RFC 2069 müsste und er schneidet den Query-Part (Sven: Der Hash-Teil beginnt nach dem # und wird eh nie an den Server gesendet) der URL beim Generieren der Response ab.

Da du aber die Response aber sowieso nur beim ersten Aufruf überprüfen willst (was IMHO eine riesige Verschwendung ist), könnte dir das unter Umständen reichen, wenn du dafür sorgst dass da kein Query-Part bei ist.

[Sven Rautenberg]

Moin!

Nein, Digest Auth ist in allen existierenden IE-Versionen kaputt: Er unterstützt keine Challenges ohne qop, was er eigentlich nach RFC 2617 aus Abwärtskompatibilitätsgründen zu RFC 2069 müsste und er schneidet den Query-Part (Sven: Der Hash-Teil beginnt nach dem # und wird eh nie an den Server gesendet) der URL beim Generieren der Response ab.

Ich habe nie etwas anderes behauptet. Ich habe die bei Digest ausgetauschten Werte als "Hash" bezeichnet - IIRC wird md5 irgendwo mit verwendet, das wäre ein Hash. :)

- Sven Rautenberg

[Henryk Plötz]

Moin,

Ich habe nie etwas anderes behauptet. Ich habe die bei Digest ausgetauschten Werte als "Hash" bezeichnet - IIRC wird md5 irgendwo mit verwendet, das wäre ein Hash. :)

Okok, ich ziehe alles zurück und behaupte das Gegenteil. ... Nun nicht direkt das Gegenteil, also, äh, also ich sollte einfach das nächste mal besser lesen. :-)

[Michael Schröpl]

Hi Andreas,

Wie war das noch mit den Clients und Digest-Auth?

etwa ab Mozilla 0.9.7 - also weder Netscape 4 noch Netscape 6.

Viele Grüße
      Michael

[Sven Rautenberg]

Moin!

Ich verstehe nicht wirklich was es für einen Sinn macht sowas kompexes wie die HTTP-Authentifzierung zu entwickeln, und dann so eine simple Kleinigkeit wie das ausloggen nicht wirklich zu implementieren, denn ein Logout ist ein wichtiges Sicherheitsmerkmal wenn es um Authentifzierung geht. Deswegen wird HTTP-Auth auch so selten eingesetzt(gegenüber HTML-Formularen + Sessions zu Authentifzierung).

Die Antwort liegt schlicht im HTTP-Protokoll begründet. Es gibt in HTTP kein vorher und kein nachher, kein Login, sondern nur unabhängige Requests. Jede Ressource wird über eine neue Verbindung abgerufen, welche einen vollkommen anderen Weg nehmen kann, als alle Verbindungen vorher.

Im Gegensatz dazu haben Protokolle wie FTP, Telnet und SSH den entscheidenden Unterschied, dass hier _einmal_ eine Verbindung zum Server hergestellt und dann dauerhaft benutzt wird, solange bis sie wieder abgebaut wird (was dann der Logout ist).

Mit anderen Worten: Um unter HTTP irgendeine Art von Zugriffsschutz auf Ressourcen zu erhalten, hat man eben das getan, was protokollmäßig möglich ist (und auch bei z.B. Telnet getan wird): Jede neue Verbindung zum Server benötigt Username und Passwort, um Zugriff zu erlangen. Nur hat Telnet den Vorteil, dass die Verbindung üblicherweise solange hält, wie man möchte, während HTTP nach dem Zugriff die Verbindung sofort wieder unterbricht.

Ein neuer Zugriff würde deshalb eigentlich erneut die Eingabe der Benutzerdaten erfordern. Weil man dann aber aus dem Tippen nie mehr herauskommen würde, speichert der Browser diese Daten. Es kommt aber im eigentlichen Sinne nie zu einem Login, also kann es auch nicht zu einem Logout kommen.

Dein Ansatz, die ganze Geschichte mit dahintergesetzten Sessions zu lösen, nur damit du das Browser-Eingabefeld für die Benutzerdaten kriegst, anstatt das in einem Formular zu regeln und eine reine Session-Lösung zu benutzen, ist in meinen Augen absoluter Overkill und total unnütze Arbeit. Wenn die Anforderungen der Aufgabe Login und Logout vorsehen, dann kann man kein HTTP-Auth verwenden - ganz schlicht ausgedrückt. Zumal es ja nicht wirklich irgendwelche zusätzliche Sicherheit bringt, und auch keinerlei Verringerung des Aufwandes bewirkt. Du mußt ja trotzdem an jeder Stelle, wo Zugriffe erfolgen können, die Sessiondaten prüfen, um den Zugriff zu authentifizieren. Wenn du das nicht machst, ließen sich die Anmeldedaten weiterverwenden.

Im Prinzip benutzt du die HTTP-Auth-Dialoge der Browser nur als schlechten Ersatz für Formularfelder. Die dadurch entstehenden Probleme haben dich eine Wahnsinns-Zeit für Workarounds gekostet, mit im Prinzip Null Ergebnis. Und dem unguten Gefühl, dass weitere Browser dieser Welt sich möglicherweise noch ganz anders verhalten könnten und dann neue Schwierigkeiten auftreten würden.

HTTP-Authentifizierung ist ganz einfach - wenn man nicht versucht, Dinge damit zu machen, für die sie nie vorgesehen war. :)

- Sven Rautenberg

[Christian Gerner]

Hallo,

Dein Ansatz, die ganze Geschichte mit dahintergesetzten Sessions zu lösen, nur damit du das Browser-Eingabefeld für die Benutzerdaten kriegst, anstatt das in einem Formular zu regeln und eine reine Session-Lösung zu benutzen, ist in meinen Augen absoluter Overkill und total unnütze Arbeit.

sehe ich genauso.

Was wäre aber, wenn er auch Grafiken vor unberechtigtem Aufruf schützen will. Angenommen er hat sie unter http://server.example/bilder/img0001.jpg, dann könnte der Pfad erraten werden. Manche Programme, mit denen man Bildergalerien erstellen kann, verwenden immer Verzeichnisse / Dateinamen nach gleichem Muster.

Würde er nur PHP mit Sessions benutzen, könnte jeder die Bilder abrufen. Angenommen er möchte jetzt nicht diese umständliche Lösung mit HTTP-Auth dazu, aber sich gleichzeitig auch sicher sein, dass niemand die Dateinamen der Bilder einfach errät, was könnte er dann machen?

Gruß,
Christian

[Christian Seiler]

Hallo Christian,

Angenommen er möchte jetzt nicht diese umständliche Lösung mit HTTP-Auth dazu, aber sich gleichzeitig auch sicher sein, dass niemand die Dateinamen der Bilder einfach errät, was könnte er dann machen?

Ein PHP-Script dazwischenschalten, das die Auslieferung der Bilder übernimmt.

Viele Grüße,
Christian

[Christian Gerner]

Hallo Christian,

Ein PHP-Script dazwischenschalten, das die Auslieferung der Bilder übernimmt.

*autsch*. Ja ist klar, hätte mir auch gleich einfallen können...

Gruß,
Christian

[Christian Seiler]

Hallo Christian,

Ein PHP-Script dazwischenschalten, das die Auslieferung der Bilder übernimmt.

*autsch*. Ja ist klar, hätte mir auch gleich einfallen können...

Betriebsblindheit, kann jedem mal passieren. ;-)

Viele Grüße,
Christian

[Andreas Korthaus]

Hi!

[...] ist in meinen Augen absoluter Overkill und total unnütze Arbeit.

sehe ich genauso.

Ich nicht ;-) Ich fand es zumindst recht interessant für mich. Und es funktioniert wunderbar, die Arbeit habe ich mir einmal machen müssen.

Was wäre aber, wenn er auch Grafiken vor unberechtigtem Aufruf schützen will.

Das kan ich mit meiner Methode ebenso gut oder so schlecht wie ohne HTTP-Authentifzierung, denn da ich die Authentifzierung nur im PHP-Script durchführe, sind auch nur PHP-Scripte geschützt. Ich könnte das zwar mit einer htaccess verbinden, dann habe ich aber keine Kontrolle mehr über die HTTP-Header und kann es somit komplett vergessen(wegen der Logout-Problematik)

Angenommen er hat sie unter http://server.example/bilder/img0001.jpg, dann könnte der Pfad erraten werden.

Das kann man ja von mir aus, an die Grafiken des Designs kommt man auch einfacher. Die interessanten dynamisch generierten Grafiken werden mit PHP erzeugt, sind also ebenfalls geschützt. Im Prinzip sind statische Dateien alle uninteressant, und die die interessant sind speichere ich außerhalb des doc-root und gebe sie mit PHP aus.

Manche Programme, mit denen man Bildergalerien erstellen kann, verwenden immer Verzeichnisse / Dateinamen nach gleichem Muster.

Mag sein, ich programmiere aber keine Bildergalerie ;-)

Angenommen er möchte jetzt nicht diese umständliche Lösung mit HTTP-Auth

"umständlich"? Ach... ;-) Das Überlegen war umständlich, das Resultat ist gar nicht mehr so viel Unständlicher als eine reine Session-Variante.

Grüße
Andreas

[Tim Tepaße]

Hallo Andreas,

unabhängig von tatsächlichem Nutzen (der Overkill, der hier diskutiert wird),
finde ich Deine Lösung und Deine Erklärung schön. Mein Kompliment dafür!

Selbst ich, unbeleckt in Sachen PHP und nicht vertraut mit den tieferen
Feinheiten von HTTP, habe das Gefühl Deine Erklärungen und Deinen Quellcode
verstanden zu haben. Ich bin sehr für ein <I> für ein TuT oder einen FA.

Tim

[Andreas Korthaus]

Hi Tim!

unabhängig von tatsächlichem Nutzen (der Overkill, der hier diskutiert wird),

Die Anwendung hat ca. 50.000 Zeilen Quellcode, ob da die 10-20 Zeilen extra da jetzt der absolute Overkill sind, naja...

finde ich Deine Lösung und Deine Erklärung schön. Mein Kompliment dafür!

Danke ;-)

Selbst ich, unbeleckt in Sachen PHP und nicht vertraut mit den tieferen
Feinheiten von HTTP, habe das Gefühl Deine Erklärungen und Deinen Quellcode
verstanden zu haben.

Ein paar Sachen habe ich zwischendurch falsch erklärt und die Kommentare sind auch nicht 100% aktuell(am Ende war es doch einfacher als zunächst befürchtet), aber schön das Du es trotzdem verstanden hast :)

Ich bin sehr für ein <I> für ein TuT oder einen FA.

Ich werde mal einen Vorschlag einreichen (http://aktuell.de.selfhtml.org/tippstricks/beitrag.htm), abbringen kann mich nur jemand, der mir zeigt dass es doch nicht so gut funktioniert wie Formulare ;-)

Grüße
Andreas