von Einen geschützten Bereich einer Webseite zu erstellen ist dank des Webservers, z. B. einem Apache, relativ einfach möglich. Dank SSL lässt sich auch die Passwortübertragung absichern. Zur Nutzung sind lediglich einige Einträge in der Konfiguration des Servers nötig. Leider ist das ganze nur optisch nicht besonders ansprechend, da eine unseriös wirkende Anmeldemaske des Browsers zum Einsatz kommt. Das muss sich doch ändern lassen, oder? Jedenfalls gibt es im Internet viele Fragen in diese Richtung.
Problem
In meinem Fall soll ein bestehender Mitgliederbereich, der aus tausenden html- und Bilddateien besteht und per htaccess abgesichert ist, eine schönere zeitgemäßere Login-Seite bekommen.
Viele Nutzer verstehen die Funktion aus irgendeinem Grund nicht (kein Scherz!) und auch die Fehlerseite bei einer Fehleingabe ist alles andere als nutzerfreundlich und lässt den unbedarften Nutzer ohne Hilfestellung zurück. Diese ließe sich noch einfach per Eintrag in der htaccess-Datei auf eine selbst erstellte Seite umleiten.
Hier verschenkt man bei einem bezahlten Mitgliederbereich auch das Potenzial bei nich nicht registrierten Nutzern die Loginpage noch als Werbung zu nutzen, falls sie sich dorthin verirren.
Die htaccess-Lösung war vor vielen Jahren eher verbreitet, aber ist zum grundsätzlichen Absichern eines Verzeichnisses zu nutzen als für einen schönen Zugang für einen Endanwender.
Einfache Lösung mittels URL und Redirects?
Die naheliegendste Idee ist es, die Logindaten vom Benutzer abzufragen und direkt in der URL einzubauen.
Hierzu muss der Benutzer diese in einem entsprechenden HTML-Formular eingeben und PHP-seitig wird die URL zusammengebaut und ein Redirect zu dieser durchgeführt.
Die URL und der Redirect könnten dann so aussehen:
|
1 |
header("Location: https://user:password@irgendeineschrottdomain.de/sicher/sichereseite.html") |
Zwar wurden in meinem Test die Benutzerdaten nicht mehr in der Adresszeile angezeigt, allerdings habe ich um einer solchen Anzeige im Klartext in alten Browsern vorzubeugen einen weiteren Redirect zwischengeschaltet.
Dies könnte dann so aussehen:
|
1 |
header("Location: https://user:password@irgendeineschrottdomain.de/sicher/redirect.php") |
In die redirect.php würde man dann folgendes packen:
|
1 |
header("Location: https://irgendeineschrottdomain.de/sicher/sichereseite.html") |
Bei einer Fehleingabe, dachte ich, könnte man auf eine angepasste Version der eigenen Login-Seite mit Hilfe des 403 oder 401 Errors per htaccess umleiten. Da aber gefühlt hundert mal immer wieder nach den Benutzereingaben gefragt wird bevor eine solche Fehlerseite auftaucht, hatte ich mir eine umständliche Lösung mittels PHP gebaut, welche das eingegebene Passwort mit dem gehashten Passwort in der htpasswd-Datei abgleicht. Dies kommt aber nun nicht zum Einsatz und würde hier den Rahmen sprengen und ist eher für einen eigenen Artikel geeignet.
Kurz und knapp: Es funktioniert mehr schlecht als recht. Es gibt da ein paar unschöne Probleme. In modernen Browsern ist diese Nutzung von Benutzerdaten innerhalb der URL eigentlich nicht mehr gewünscht. Im Chrome soll dies eine ganze Weile nicht funktioniert haben, wurde aber wieder freigeschaltet. Im Internet Explorer soll dies nicht mehr möglich sein. Im Firefox konnte ich keine Probleme feststellen. Leider kommt allerdings trotzdem eine zu bestätigende Info bzgl. der Übertragung der Logindaten. Dies soll Phishing-Versuchen vorbeugen.
Da diese Funktionalität also „deprecated“ ist und in der Zukunft vielleicht sogar komplett verschwinden wird, ist von einer Nutzung wohl eher abzuraten. Schade, denn es funktionierte grundsätzlich.
Komplexe Lösung mit JavaScript oder PHP?
Da die erste Idee eine Finte gewesen ist, dachte ich, man könnte den Login auf der Client-Seite vielleicht mit JavaScript vornehmen. Nach Stunden langer Recherche fand ich heraus, dass dies auch grundsätzlich möglich ist. Hierzu muss man die gesendeten HTTP-Header „manipulieren“.
Das einzige Problem an der Sache ist, dass diese Anmeldung leider nicht grundsätzlich für den Browser gilt. Diese Anmeldung ließ sich in meinen Tests dann nur für den Zugriff mittels JavaScript auf den geschützten Bereich nutzen. So kann dann zwar z. B. der Inhalt einer im gesicherten Ordner liegenden html-Datei ausgegeben werden, aber nicht die Erlaubnis für den Browser erteilt werden selbständig auf diese Dateien zuzugreifen.
Zugegebenermaßen macht dies aus sicherheitstechnischen Gründen mit Sicherheit Sinn, dass man mittels JavaScript also nicht den Login durch den Browser beeinflussen kann
Es müssten dann also alle geschützten Dateien mittels JavaScript-Anfragen vom Server geladen werden. Dies ist leider auch nicht die gewünschte Lösung 🙁
Das gleiche Problem hat man dann auch wenn man sich aus PHP mittels Header anmeldet. Man ist dann halt aus der PHP-Session angemeldet, nicht jedoch der Browser des Clients. Dies bringt auch eigentlich nur etwas wenn man sich bei einer anderen Webseite anmelden möchte, da man ja auf die eigenen Ordner PHP-seitig sowieso Zugriff hat.
Kurz und knapp: Ein Anmelden mittels JavaScript oder PHP ist möglich, aber in dieser Form eher nur für Downloads von Dateien aus einem geschützten Bereich brauchbar.
Reine Lösung per PHP?
Statt der Basic Authentication des Webservers könnte man natürlich den kompletten Login in PHP abbilden und mit PHP-Session-Cookies arbeiten. Hierzu müssten allerdings alle vorhandenen html-Dateien angepasst werden.
Nachteil einer reinen PHP-Lösung ist natürlich, dass nicht einfach der Zugang zu einem ganzen Ordner, indem sich alte html-Dateien und Bilder etc. befinden, gewährt werden kann. Zumindest die Bilder und auch z. B. JavaScript-Dateien müssten dann in einem Ordner „public“ zugänglich sein oder umständlich durch das PHP-Skript eingelesen und ausgegeben werden. Auf einem Shared-Hosting ist so etwas performance-technisch eher nicht zu empfehlen.
Fazit
Man kann mit diesem Thema viel Zeit verschwenden. Eine wirklich brauchbare Lösung um die Basic Authentication des Webservers mit einem eigenen Loginskript clientseitig zu nutzen und die Standard-Dialogfenster des Browsers zu umgehen wird man wohl vergeblich suchen.
Auch wenn es kein wirklicher Trost ist, fand ich es lustig und zum Abschluss noch erwähnenswert, dass auch die Fernuni Hagen für den „virtuellen Studienplatz“ immer noch keine schönere Anmeldemaske hat 😀
Die Vor- und Nachteile der Login-Varianten habe ich der Vollständigkeit halber hier nochmals zusammengetragen:
Nachteile des .htaccess-Logins
- nur Standard-Login-Maske vom Browser
- Kennwort und Benutzernamen müssen vom Administrator gepflegt werden
- keine „Passwort vergessen“-Funktion für den Nutzer möglich
Vorteile des .htaccess-Logins
- keine Fehler möglich bei der Programmierung des Logins
Nachteile des WordPress-Plugin-/Eigenentwicklung-Logins
- fehlerhafte Programmierung des Logins ist möglich
- Dateien sind nicht direkt geschützt (aber durch den Trick aus diesem Artikel ist das kein wirkliches Problem!)
Vorteile des WordPress-Plugin-/Eigenentwicklung-Logins
- optisch ansprechender Login
- Funktionen wie „Passwort vergessen“ sind möglich
- Passwort und Benutzername könnten durch den Nutzer geändert werden
