nicht angemeldet
Hi Andreas,
Ich meine dass ich bei machen Hostern nicht die Möglichkeit habe,
auf andere Verzeichnisse zuzugreifen als die htdocs!
Also _muss_ ich die .htpassw in einem für Browser erreichbares
Verzeichnis ablegen.
Yep. Kein guter Provider, das.
Ich habe beispielsweise mein eigenes access_log und error_log und
möchte beide sicherlich nicht in den URL-Raum einblenden.
Und wenn ich die im .htaccess geschützen Bereich ablege wird es
wohl OK sein, oder was ist besser?
In Deinem Falle geht es nicht wirklich zuverlässig. Du mußt darauf
vertrauen, daß Dein Provider keinen Unfug treibt. (Das Self-Portal hat
mit einem früheren Provider genau diesen Un-Fall schon erlebt.)
"Basic" ebenso wie jede formularbasierte Methode sendet die Daten im
Klartext (bzw. Base64-codiert) über die Leitung. (Es sei denn, Du
legst eine SSL-Schale um die gesamte Kommunikation herum.)
Gilt das auch für HTACCESS?
Diese Frage verstehe ich nicht.
.htaccess ist ein Mechanismus innerhalb der Webserver-Konfiguration;
SSL ist eine Schale um den HTTP-Dialog zwischen Server und Browser.
Falls Du meintest: "Kann man auch Server Authentication in SSL einschalen?",
lautet meine Antwort: "Genau das hatte ich gerade vorgeschlagen, damit die
in HTTP im Klartext gesendeten Passworte von SSL verschlüsselt werden".
Also einfach ein php Script, welches die .htpasswd öffnet und den Inhalt mit
explode() aufschlüsselt, den Inhalt in einer Schleife ausgibt und dann mache
ich hinter jede User-Pass kombination 2 Links, einmal bearbeiten und einmal
löschen, der eine löscht die Zeile, der andere schreibt die Daten in ein
Formuler, wo ich die Daten verändern kann, und dazu noch ein Formular welches
eine neue Zeile einfügt, Passwörter mit crypt() verschüsselt. Ginge das so in
etwa?
Völlig richtig. Vor allem ist der Ansatz gut, zuerst die möglichen Werte zu
bestimmen und einen davon auszuwählen - viel schöner, als zuerst ein Eingabefeld
anzubieten und dann eine Fehleingabe mit einer Fehlermeldung zurückzuweisen.
Du kannst auch für die definierten Benutzer ein Dropdown-Menü erzeugen - so
etwas habe ich hier im Büro als Oberfläche für die eingetragenen Benutzer eines
Webhosting-Produkts mal gebaut.
Leider habe ich noch nie was in der Art versucht.
Aber es scheint genau Deine Kragenweite zu sein. Probiere das ruhig mal aus.
Das Prinzip hast Du ja verstanden. Und da es wahrscheinlich nur Dich selbst
als Benutzer geben wird, darfst Du die Synchronisation paralleler Schreib-
zugriffe auf die Passwort-Datei in Version 1.0 erst mal ausklammern. ;-)
Darüber hinaus wäre "Digest" wirklich sicherer als alles, was Du selbst
bauen kannst.
Zum jetzigen Stand der Browser-Entwicklung schließt Du damit allerdings
sämtliche Netscape-Browser aus; Opera 4, M$IE 5, Mozilla 0.9.7 und Amaya
(ich habe 5.3 probiert) spielen bereits mit.
Also fürs erste lieber Basic mit SSL-Verschlüsselung.
Je nachdem. Für SSL brauchst Du wiederum ein Zertifikat ... und SSL im Web-
server, mit entsprechender Konfiguration.
Digest Authentication käme mir wesentlich 'handlicher' vor. Und Mozilla 0.9.7
kann es immerhin - mal sehen, wann der nächste Netscape heraus kommt ...
Gibt es eigentlich die Möglichkeit an Stelle des sich öffnenden Auth-Fensters
eine .htaccess Authentifizierung in ein html-Formular einzubauen?
Jetzt nur wegen der Optik!
Das ist eine oft gestellte Frage. ;-)
Im Prinzip besteht die Frage aus zwei Teilen:
a) Kann ich das Verhalten des Browser beim Eintreffen einer Authentifizie-
rungs-Anforderung beeinflussen?
Antwort: Nein, weil die Browser-Hersteller das nicht vorgesehen haben.
b) Kann ich selbst präventiv eine Authentifizierung anhand von Formular-
werten an den Server senden?
Antwort: Im Prinzip würde das funktionieren. Von HTTP-Seite spricht jeden-
falls nichts dagegen, schon beim ersten Zugriff auf eine geschützte Seite
die "credentials" mitzusenden - Du mußt die Aufforderung zur Authentifi-
zierung nicht erst provizieren.
Das Problem ist aber, daß die Browserhersteller nicht wissen können, daß
Du mit einem HTML-Formular etwas Anderes tun möchtest, als eine der Me-
thoden zu verwenden, die es für Formulare nun mal gibt - also GET oder
POST.
Im Prinzip 'fehlt' hier ein Stückchen HTML-Definition, um dem Browser zu
sagen, den Inhalt eines bestimmten Formular-Elements nicht in den Query-
String oder den POST-Inhalt, sondern in den Authentication Header des
HTTP-Requests zu stecken.
Es ist nicht prinzipiell unmöglich - es gibt nur einfach keinen passenden
HTML-Tag dafür, obwohl HTML mit seinen Formular-Tags über die Grenzen
einer Dokumentstrukturbeschreibungssprache ansonsten weit hinaus geht
und sich gerade mit den Formular-Methoden (ebenso wie mit den URLs) an
die Vorgaben von HTTP bindet.
HTML und HTTP sind in dieser Hinsicht nicht inhaltlich deckungsgleich.
Viele Grüße
Michael
P.S.: Eigentlich wundert es den Betrachter, daß Micro$oft an dieser Stelle
noch keine proprietäre Lösung erfunden hat.
Andererseits: Micro$oft und Sicherheitsbewußtsein ... ;-)