nicht angemeldet
Hi!
Wie soll das denn gehen? Bei Authentifizierung über Sessions und Cookies wird i.d.Regel kein Benutzername übertragen.
Und wofür dann die Bezeichnung "Authentifizierung"? Geht es also nicht um einen geschützen Login-Berreich? Wenn man nur prüft ob ein Cookie mit bestimmtem Namen und 32 Zeichen geschickt wird, wozu soll das gut sein? Ich dachte daran man loggt sich in einen privaten Bereich ein, wie auch immer. Und hierfür gibt man dann halt seinen Benutzernamen und Passwort in irgendein Forumlar ein. Ob ich das ganze jetzt mit .htaccess, mit der PHP basic auth. oder mit Sessions mache ist ja eigentlich egal. Die verschiedenen Varianten bieten halt verschiedene Vor- und Nachteile, was man wofür einsetzt kommt auf die Anwendung und auf die Gegebenheiten(PHP-Modul?...) an.
Wenn Du damit meinst, dass das Verfahren mit error401 und Session kombiniert werden soll, dann wird es wohl gehen.
Das ist ja unnötig, denn bei der basic-Authentifizierung braucht man ja gerade _keine_ Session, da der Browser Benutzernamen und Kennwort jedesmal mitsendet. Der Server prüft das dann halt bei jedem Request. Dieses Verfahren ist schön und gut, nur leider steht mir z.B. die Modul-Verison bei weitem nicht überall zur Vefügung, eher selten. Ich meine dagegen, man gibt die Zugangsaden in ein HTML-Formula rein, überträgt die einmal per POST, validiert die Daten und vergibt ggfs. eine SessionID _und_ speichert die Zugangsdaten in der Session, nur zur Sicherheit, falls man vielleicht doch noch eine Sicherheitslücke hat.Dieses Verfahren finde ich persönlich sicherer als basic oder digest Authentifizierung, denn wenn man danach nur noch die SessionID überträgt kann es mit gleicher Wahrscheinlichkeit dazu kommen das sich jemand Zugang verschafft wie bei den HTTP-Authentifizierungs-Verfahren, aber der Unterschied, bei den der SessionID hat der Einbrecher nur einmaligen Zugriff, also solange die Session läuft, was sicher schon schlimm genug ist, aber bei HTTP Authentifizierung hätte der Angreifer die Zugangsdaten und könnte sich damit immer wieder anmelden wie er lustig ist.
Das ich jedesmal in der Session die Zugangsdaten prüfe habe ich mir überlegt, da so auch ausgeschlossen wird, das jemand - wie auch immer - an eine gültige Session ID gekommen ist, den dan muss er immer noch in dieser Session gültige Zugangsdaten haben, wenn dem nicht so ist wird die Session sofort gekillt. Das hat sich bisher gut bewährt. Wenn ich dagegen nur auf Vorhandensein der Session prüfe (was Du in Deinem Beispiel noch nicht mal tust!), dann müßte ich 100%ig sicherstellen, dass man nicht mit irgendwelchen Tricks doch an eine Session auf meinem Server kommt, auch wenn ich annehme das das nicht möglich ist bis ich dennoch relativ sicher das es mittel und Wege dazu gibt. Wenn Du dagegen nur prüfst ob die Session formal richtig ist, dann ist das doch wirklich einfach durch einen kleinen zusätzlichen Header an eine Session zu kommen. Klar, das alles muß man erstmal wissen, aber ich denke viele unerfahrene Programmierer machen oft dieselben Fehler, so dass Profis wissen wo sie gucken müssen, außerdem ist es meiner Meinung nach erst ein gutes Sicherheits-Konzept, wenn der Angreifer trotz Kenntnis der der Interna nicht in den geschützen Bereich gelangen kann, da es duch gute Programmierung (statistisch so gut wie) unmöglich gemacht wird.
Da aber beide Werte immer noch im Klartext übertragen werden, hat das eigentlich keinen Vorteil, außer höherer Serverlast.
Das hatte ich auch nicht vor, aber die so erzeugte Serverlast ist denke ich vernachlässigbar!
Viele Grüße
Andreas