nicht angemeldet
re eddi
Irgendwie verlieren wir uns im Kleinen und reden sicherlich auch teilweise aneinander vorbei. Wir wissen wenig zur genauen Situation des OP und unsere allgemeinen Herangehensweisen kommen nur nach und nach zum Vorschein. Deswegen stelle ich mal lieber meinen Gedankengang zu Problematik im Ganzen vor.
Ich denke, dass eine solche Struktur sinnvoll ist:
docroot-+-- allgemeiner Bereich
|
+-- Member-Bereich, geschützt
|
+-- (Moderatoren-Bereich, geschützt)
|
+-- Admin-Bereich, geschützt
Ob es einen Moderatoren-Bereich gibt, kommt auf die Größe der User-Gemeinde an. Ebenfalls ist zu erwägen, ob die Moderatoren eher Member mit Extra-Rechten (zur Userverwaltung) sind - dann ist evtl. kein Moderatoren-Bereich erforderlich - oder eher mehr Administratoren mit eingeschränkten Rechten.
Ähnliches gilt für den Admin-Bereich: Gibt es aufgrund der auszuführenden Aufgaben eigenständige Admin-Skripte oder werden dafür nur Member-Scripte mit ein paar mehr, an bestimmte Rechte gekoppelte Funktionen verwendet?
Wenn ich davon ausgehe, dass die Bereiche (und die Scripte) klar voneinander getrennt sind, wäre die folgende Konfiguration mein Favorit:
Die Anzahl der Administratoren ist ziemlich klein, Admins Auth-Daten sind im Admin-Verzeichnis "fest" in der .htuser[1] eingestellt. Kein Script kann daran was ändern. Für den Admin gibt es eigene Kennung für den Zugriff auf die Nutzdaten der Anwendung und die Userdaten in der DB.
Auth-Daten der Member werden in einem von den Admin-Auth-Daten getrennten System vorgehalten.
(Moderatoren-Auth-Daten werden entweder zusammen mit den Memberdaten verwaltet oder in einer getrennten Datenhaltung - je nach den oben erwähnten Erfordernissen.)
Nun kommt es auf die Größe der Gemeinschaft an, ob zur Verwaltung selbiger die Daten einfach (mit nicht vorhandenem(?) Lockingmechanismus) in Konfigurationsdateien geschrieben werden können und Konflikte bei konkurrierendem Zugriff ignoriert werden können, oder ob nicht eine "richtige" Datenbank dafür genutzt werden sollte. [2]
Mit getrennten Verzeichnissen (s.o.) und entsprechend fein eingestellten Zugriffsrechten auf die Tabellen/Felder der DB für die jeweiligen Admin/Moderatoren/...-Scripte bzw. für das Auth-Modul des Apachen stelle ich mir das sicherer und robuster vor.
dedlfix
P.S: Der ganze Gedankengang mit der DB ist natürlich dann hinfällig, wenn man keinen eigenen Server hat in dem man sich die entsprechenden Apache-Module einbinden kann.
[1] oder wie auch immer die genannt wird.
[2] Den DBM-Gedanken verwerfe ich wieder, der ist auch nicht besser als die htpasswd-Methode. Ich ging am Anfang davon aus, dass das PHP-Script direkt die .htuser-Datei bearbeitet wird (z.B. mit http://pear.php.net/manual/en/package.fileformats.file-passwd.php@File_Passwd_Authbasic). Apaches htpasswd ist da ja hoffentlich schneller mit Schreiben fertig, als es ein PHP-Script könnte.