Hi

Ich mache gerade eine Webapp, zu welcher sich aber anmelden muss.
Das einfachste und sicherste wäre, den Login via .htaccess zu erledigen.
Allerdings finde ich dieses "Anmeldepopup" ziemlich unattraktiv.

Kann ich ein Formular machen das schön gestaltet ist (vgl. zB iCloud.com) und die Credentials dann dem Server übergibt und dieser (evt. mit PHP) die Authentifizierung erledigt?

Kann ich ein Formular machen das schön gestaltet ist (vgl. zB iCloud.com) und die Credentials dann dem Server übergibt und dieser (evt. mit PHP) die Authentifizierung erledigt?
Ja

Peter

Gut also dass es irgendwie geht dachte ich mir.
Ich habe es mal etwa so gelöst:
<?PHP
header("LOCATION: http://max:maxpws@www.domain.com/web/login.php");
?>

Die Frage ist für mich, wie sicher das ist.
Ist es gleich unsicher wie http:// Logins allgemein (Wireshark etc) oder ist es unsicherer als sonst?

Passwörter in der URL durchschleifen? Untersteh dich.

Peter

Naja, Passwörter werden so oder so zu oft im Klartext übertragen.
Eine ARN-Spoofer via Broadcast verschicken im Netzwerk und man kann sehr viele Passwörter im Klartext bekommen.
Das von PHP-Resource übrigens auch.

Aber wie kann ich das nun lösen?
Ich finde im Internet immer nur umgekehrte Ansätze, wie man via PHP eine HTTP Authentifizierung auslösen kann, also über header() dieses unschöne Fensterchen aufrufen kann.

Hallo,

ich glaube, Kropff meinte, dass du bei einer Umleitung per Location-Header dafür sorgst, dass der Browser sich direkt bei der entsprechenden Seite anmeldet und ggf. die Anmeldedaten in der Adressleiste zu sehen sein könnten. Kannst du dich nicht mit PHP bei dem Server anmelden und gewissermaßen als Proxy agieren?

Gruß,

Amica

Naja, Passwörter werden so oder so zu oft im Klartext übertragen.
Eine ARN-Spoofer via Broadcast verschicken im Netzwerk und man kann sehr viele Passwörter im Klartext bekommen.
Das von PHP-Resource übrigens auch.
Darum gehts auch gar nicht. Schlimmer ist die Tatsache, dass jemand der dem Benutzer auf den Bildschirm schaut die Zugangsdaten einfach mitlesen kann. Ohne Zugriff aus das Netzwerk. Und Jede eingebettete Resource. Und jeder Tracking Dienst. Alle. Und ganz abgesehen davon, und das finde ich viel schlimmer (weil den Hack nutze ich hier und da auch mal, wenn es nicht anders geht): Die allermeisten Browser mögen das gar nicht, geben eine Betrugswarnung aus oder naggen den Benutzer mit anderen nervigen Abfragen. Lass es lieber.

Um zurück zur Frage zu kommen:
Kann ich per PHP nun einen Header aussenden, welcher den Browser authentisiert für einen Bereich?
Und wenn ja, welchen Header muss ich nun konkret nutzen.

So wie ich das auf Stackoverflow gelesen habe geht das nicht, aber Kropff hat da auf die erste Frage mit einem eindeutigen "Ja" geantwortet.

Hi

Nachdem ich wohl nicht via einem schönen HTML/CSS Formular mich bei einem htaccess anmelden kann, muss ich mich weiter umschauen.

Der Login sollte folgende Funktionen bieten:
- via HTML/CSS Formular anmeldbar
- keinen Zugriff (auch auf JPG/PNG/...) innerhalb des geschützten Verzeichnis zulassen
- Bilder danach direkt auslesbar und nicht durch ein PHP Script durchgeschleift


Ich habe ein Verzeichnis mit ~2000 Fotos welche absolut nicht zugänglich sein dürfen ohne Login.
Aus Performance Gründen ist es aber auch nicht optimal diese Bilder ausserhalb des httpdocs zu speichern und durch ein PHP Script auszugeben.

Ja, aber welcher Client nun autorisiert ist und welcher nicht ist wiederum Sache des Servers, genauer gesagt vom Apache Server in dem Falle vom htpasswd.
PHP müsste also nur irgendwie dem Apache mitteilen "Hey, der Client ist okay, autorisier ihn".

Von der Autorisierung läuft nix auf dem Client ab, lediglich das Formular welches angezeigt wird.

Kann ich per PHP nun einen Header aussenden, welcher den Browser authentisiert für einen Bereich?
Nein, natürlich nicht.

PHP läuft auf dem Server. Authentifizieren muss sich aber der anfragende Client, und zwar beim Request. Per PHP gesendete Header sind aber Response.

Von der Autorisierung läuft nix auf dem Client ab, lediglich das Formular welches angezeigt wird.
Der Client muss die Zugangsdaten bei jedem Request erneut mitschicken. (Deshalb ist es auch kein „Login“.)

PHP müsste also nur irgendwie dem Apache mitteilen "Hey, der Client ist okay, autorisier ihn".
Kann es aber nicht.

Hallo,

deine Punkte widersprechen sich. Entweder ist ein Verzeichnis geschützt und die Inhalte müssen durchgeschleift werden oder es ist mindestens teilweise offen. Wenn es teilweise offen ist, kommt nur HTTP-Authentifizierung in Betracht und die widerspricht wieder der Forderung nach einem schönen Login.

Das Durchschleifen ist aber kein großes Problem und solange die Dateien auf derselben Maschine liegen auch kein nennenswerter Performanceverlust. Die Dateien müssen auch nicht außerhalb des Document Root liegen, sondern lediglich in einem geschützten Verzeichnis.

Warum du aber jetzt gleich einen neuen Thread anfängst, verstehe ich nicht.

Edit: Themen gejoint

Gruß,

Amica

Wenn du HTTP Auth mit „schönem Login“ willst, bleibt dir eigentlich nur eine Möglichkeit: AJAX.

Du lässt den Nutzer die Zugangsdaten in ein Formular eingeben und erst mal so an den Server schicken, an ein (PHP-)Script außerhalb des geschützten Bereiches. Dieses Script muss dann prüfen, ob die Zugangsdaten stimmen – entweder, in dem es selbst einen HTTP-Request auf eine Ressource innerhalb des geschützten Bereiches macht, oder in dem es die entsprechenden Konfigurationsdateien selber liest und auswertet.
Dann gibt das Script eine entsprechende Antwort an den Client, je nachdem ob die Zugangsdaten gültig sind oder nicht. Wenn sie gültig sind, macht der Client einen AJAX-Request nach einer Ressource aus dem geschützten Bereich, und gibt dabei die Zugangsdaten mit.

Ich habe das vor ca. einem halben Jahr mal durchgespielt, und alle großen Browser bis auf Opera haben brav mitgespielt. (Opera unterscheidet offenbar zwischen AJAX- und „normalen“ Requests in der Hinsicht – das Fenster für die Eingabe der Zugangsdaten kam anschließend beim Aufruf einer geschützten Ressource per Link immer noch, obwohl der AJAX-Request erfolgreich war. Habe damals kurz überlegt, ob ich einen Bugreport verfassen soll, aber es dann doch bleiben gelassen.)

Als Workaround für Opera und Fallback für nicht JS-/AJAX-fähige Browser müsstest du dann mit dem „normalen“ Abfragefenster leben.


Wenn du das nicht als eine akzeptable Lösung ansiehst – dann bleibt dir ggf. noch, den Server-Administrator zu bitten, dir ein Modul wie mod_auth_cookie o.ä. zu installieren. (Die Chancen dafür stehen in einer shared hosting-Umgebund aber vermutlich eher schlecht.)

Danke @wahsaga

Das hilft mir schon sehr viel weiter.
Die Abfrage via PHP ob das Passwort im .htpasswd enthalten ist kann ich machen.


Mit dem Satz: "Wenn sie gültig sind, macht der Client einen AJAX-Request nach einer Ressource aus dem geschützten Bereich, und gibt dabei die Zugangsdaten mit."

Meinst du damit dass er danach den Login mit dem https://name:pass@domain.ch Schema per AJAX durchschicken?

Mit dem Satz: "Wenn sie gültig sind, macht der Client einen AJAX-Request nach einer Ressource aus dem geschützten Bereich, und gibt dabei die Zugangsdaten mit."

Meinst du damit dass er danach den Login mit dem https://name:pass@domain.ch Schema per AJAX durchschicken?
Nein.
Benutzername und Passwort lassen sich bei AJAX-Requests als extra Parameter der Methode XMLHttpRequest.open mitgeben.

Nein.
Benutzername und Passwort lassen sich bei AJAX-Requests als extra Parameter der Methode XMLHttpRequest.open mitgeben.

Habe das nun mal so gemacht, ändert aber nichts daran, dass der Request weiterhin mit user:pass@domain geschickt wird, auch bei HTTPS

Habe mal zum Testen einen Ajax Request mit jQuery gestartet und username und passwort übergeben wie bei der jQuery Doc beschrieben.

http://idisk.me.com/fabiopigi/Public/Pictures/Skitch/jquery-20111115-100251.jpg

Wenn ich die Funktion ausführe und dem WebKit Inspector den Request anschaue sehe ich folgendes:
http://idisk.me.com/fabiopigi/Public/Pictures/Skitch/ajax-20111115-095440.jpg

Das ganze läuft auf einem "SSL" Server. Zwar nur ein SSL Proxy von All-Inkl aber es hat ein grünes Schlösschen bei Safari. :)

SSL wird ja bereits auf dem TCP Layer angewendet, also dürften auch die Requests verschlüsselt sein.

Aber wo liegt nun der Unterschied, User und Passwort direkt in der URL beim Ajax anzugeben, anstatt diese via AJAX Setup anzugeben?
Der Request der entsteht ist ja der selbe (siehe oben).

Also ich werde es schon so machen, aber wo genau liegt der Vorteil via AJAX Setup.

Diese Anfrage-URL die du da siehst, wird von dem Inspector zusammengebastelt. Im HTTP gibt es URLs in diesem Sinne nicht. Einzelne Teile der URL ergeben einzelne Teile der HTTP-Anfrage. Der Inspector wandelt die geschickte Anfrage zur Darstellung einfach wieder in eine URL um.

SSL verhindert, dass jemand diese Anmeldedaten (die übrigens als base64-kodiert im Header übertragen werden) ausspähen kann, denn die SSL-Schicht ist im OSI-Modell tiefer als HTTP. Das heißt, die gesamte HTTP-Anfrage (incl. Anmeldedaten im Header) wird verschlüsselt übertragen und erst beim Empfänger wieder entschlüsselt. Die Anmeldedaten sind also sicher.

Die Anmeldedaten sind also sicher.

Super, dann kann ich beginnen, das ganze zu schreiben. :)

Wenn jetzt aber die SSL Verbindung wegfällt, wie es noch bei zu vielen Homepages ist, und man sich über HTTP Anmeldet über ein Formular (zB ein normales Anmeldeformular) kann jeder über Wireshark das Passwort mitlesen?

Wenn jetzt aber die SSL Verbindung wegfällt, wie es noch bei zu vielen Homepages ist, und man sich über HTTP Anmeldet über ein Formular (zB ein normales Anmeldeformular) kann jeder über Wireshark das Passwort mitlesen?

Ja, das kann man aber auch bei einem Login-Formular, wo die Daten i. d. R. per POST im Klartext übertragen werden. Es gibt aber auch ohne SSL eine sichere HTTP-Authentifizierung. Wir haben bisher von der Basic Authentication gesprochen, es gibt aber noch die HTTP Digest Authentication, wo das Passwort ebenfalls verschlüsselt wird.