nicht angemeldet
Hallo Uschi,
Schade, daß dieser Thread schon soweit unten steht.
ist doch schön. ;-) Wir beide lesen ihn, und der Archivierungsmechanismus ist Dir ja wohl bekannt?
Denn ich stelle, wie schon öfter fest, daß die
Kommunikation mir Dir hilft, sich über den eigenen
Wust im Hirn klar zu werden.
Dafür werde ich auch in unserer Firma bezahlt. ;-)
Sind "Objekte" eigene URLs?
Also etwas, das im HTTP-Universum eine Identität hat?
Nicht immer, würde ich sagen.
Aha. Das macht die erforderliche Intelligenz noch unverzichtbarer.
Sieht so aus, als ob Du von HTTP Authentication bestenfalls die Benutzerkennung auswerten kannst, ansonsten aber alles dynamisch zusammenkleben mußt.
Ich mache seit etwa zwei Jahren etwas sehr Ähnliches, nämlich Suchmaschinen (basierend auf dem, was Du aus dem Self-Archiv kennst), mit Perl statt PHP, und inzwischen ebenfalls mit mySQL-basierter eigener Authentifizierung. (Häßlicherweise bekomme ich die Benutzerkennung nicht via HTTP Authentication, sondern als Cookie ... der Rest der Anwendung kann es nicht besser ...)
(Die aber durchaus auf HTTP-Authentication-
Informationen zugreifen kann - REMOTE_USER würde
helfen, die Gruppenzugehörigkeit müßtest Du
allerdings selbst herausfinden.)
Meinst du das so: Ich regele die eigentliche
Zugriffskontrolle über die HTTP_Authentication,
lese dann mit $_SERVER['REMOTE_USER'] aus, ob und
welches Userlein am Start ist.
Wenn ein registriertes Userlein am Start ist, dann
gleiche ich den mit einer Datenbank-Tabelle oder
auch mit einem authGroupFile ab?
Gemeint hatte ich das ursprünglich ungefähr so.
Was allerdings voraussetzt, daß für den grundsätzlichen Aufruf Deiner Seite in jedem Fall eine Benutzer-Identität erforderlich ist - nur dann ist mein Ansatz so brauchbar.
Nachdem der Benutzer sich also zwangsweise ausgewiesen hat, kannst Du wie beschrieben seinen Namen abgreifen.
Ob Du diesen gegen eine Datenbanktabelle oder gegen ein AuthGroupFile abgleichst, hängt davon ab, ob Dir ein AuthGroupFile irgend etwas bringt.
Falls es komplette Seiten gibt, die nur die Benutzer einer Gruppe überhaupt betreten dürfen, dann würde das GroupFile den anderen schon auf HTTP-Ebene eine Abfuhr erteilen, während Du andernfalls selbst die Fehlerbehandlung machen müßtest.
Hast Du aber nur Seiten, die jeder sehen darf (wenngleich mit unterschiedlichem Inhalt), dann wird Dir das Gruppenkonzept der HTTP-Authentifizierung nichts nützen.
Dasselbe gilt auch, falls Deine Berechtigungsstruktur komplizierter ist, als ein GroupFile das abbilden kann. "Basic" Authentication heißt nun mal so, weil sie nicht viel kann.
Ist "der owner" gleich dem UNIX owner der Datei?
Nein, denn es kann sich ja auch um einen Datensatz
oder einen Teil davon handeln.
Diese Antwort macht mehrere nachfolgende Fragen meines vorherigen Postings hinfällig.
Kannst du nicht noch ein paar mehr so schöne Artikel wie http://aktuell.de.selfhtml.org/artikel/server/htaccess/index.htm schreiben, bitte?
Dir ist aber hoffentlich bewußt, wie unstrukturiert, didaktisch mangelhaft und veraltet der ist? Das war halt mein erster Versuch ... ich denke, die anderen Feature-Artikel sind weniger holperig. Gerade diesen müßte ich eigentlich dringend mal wegwerfen und neu schreiben.
Mit welchen Browsern muß es funktionieren?
Meine Frage bezog sich auf Netscape 6.2, der noch kein AuthType Digest kann.
Unter Netscape 6.2 muss es funktionieren, aber bis
das fertig ist, kann der bestimmt auch AuthType
Digest
Eben nicht. Nachdem Netscape 7 heraus ist, wird Netscape 6.2 (der auf Mozilla 0.9.4.1 basiert) wohl kaum weiter entwickelt. Digest Authentication ist aber erst ab Mozilla 0.9.7 oder so ähnlich eingebaut worden - Netscape 7 kann das also.
wobei mir unklar ist, was der da eigentlich verdaut,
ich lese das hier zum ersten Mal.
AuthType Basic überträgt die Kennworte im Klartext, AuthType Digest würde sie MD5-codiert übertragen. Also ein Security-Aspekt. Ist so etwas wichtig für Dich?
Mir ist prinzipiell unklar, worin die Vor- und
Nachteile einer Authentifizierung via DB und
.htaccess liegen.
".htaccess" ist nur eine Datei. Das, worauf ich mich beziehe, ist der Transport der Informationen.
Wenn der Client sich einmal erfolgreich beim Server eingelogt hat, dann sendet er in Form eines HTTP-Headers automatisch bei jedem Zugriff wieder die erforderlichen "credentials" (Benutzername und Kennwort) mit - und das _nicht_ innerhalb der URLs, so daß diese Angaben in den meisten Server-Logs und in den HTTP-Referrern nicht auftauchen.
Du mußt Dir also um das ganze Handling der _Weitergabe_ der erfolgreichen Anmeldung keine Gedanken mehr machen, und auch kaum welche um die Fehlerbehandlung. Das macht alles die HTTP-Schicht um Dich herum - die will nur ein paar Pfade und URLs gesagt bekommen, die Logik dagegen versteht der Apache selber.
Wenn Du PHP und das dortige Session-Konzept verwendest, bekommst Du ungefähr dasselbe. Wenn Du damit umgehen kannst, ist es womöglich sogar geschickter, alles aus einer Hand zu nehmen, als verschiedene Technologien zu kombinieren.
Wenn ich das im Moment richtig sehe, dann sollte
zumindest die Frage, was eine Gruppe mit einem
bestimmten "Objekt" machen darf, in einer DB
gespeichert werden. Oder?
Ich habe noch keinen Eindruck von der Komplexität Deiner Berechtigungsstruktur. Ich kann mir die Baumartigkeit des Gesamtkonzepts nicht im Detail vorstellen.
(Wahrscheinlich würde das auch hier den Thread sprengen ... ich maile Dich da mal lieber direkt an.)
Und noch was: Ich habe schlicht keine UNIX-
Kenntnisse.
Das ist vermutlich gar nicht schlimm. Nachdem ich nun glaube, verstanden zu haben, daß Du mit den UNIX-Berechtigungen nichts am Hut hast, sondern ein eigenes Universum baust, reichen Dir PHP- und Datenbank-Kenntnisse aus, um praktisch alles zu machen. (Es kann höchstens sein, daß Du irgendwas tun willst, wofür es in PHP bereits eine fertige Funktion gibt, deren Namen Du sofort als passend identifizieren würdest, wenn Du das entsprechende UNIX-Kommando gekannt hättest ...)
Was ich zum Beispiel gerne möchte ist, daß ich
jemandem Lese- und Schreibrechte in einem Container
gebe, aber zum Beispiel nicht das Recht, unterhalb
dieses Containers weitere anzulegen.
Tja, so etwas mußt Du bei der Modellierung Deiner Berechtigungsstrukturen berücksichtigen.
Offensichtlich sind "Erzeugen eines Objekts innerhalb von Container X" und "Erzeugen eines Containers innerhalb von Container X" bei Dir unterschiedliche Berechtigungen.
In UNIX oder Windows erfordern "Erzeugen einer Datei" und "Anlegen eines Verzeichnisses" dieselbe Berechtigung (nämlich Schreibrecht auf das übergeordnete Verzeichnis), während _Ändern_ eines Datei-Inhalts jeweils das Schreibrecht auf das Objekt selbst erfordert, nicht aber dasjenige auf den Container drum herum. Du kannst also in UNIX - nur so als Beispiel - das Recht haben, den Inhalt einer Datei auf 0 Byte zu reduzieren, nicht aber das Recht, diese Datei zu löschen - und das macht sogar Sinn, weil Du durch das Vernichten des Inhalts nicht andere Leute daran hinderst, wieder neuen Inhalt hinein zu schreiben, während Du durch das Löschen der Datei bewirken würdest, daß der nächste Besucher diese Datei wieder neu anlegen müßte und _dafür_ ein _anderes_ Recht bräuchte, nämlich das Schreibrecht auf das übergeordnete Verzeichnis ...
Also: Definiere Deine Objekte, definiere die erlaubten Operationen auf diesen Objekten, und dann überlege Dir, ob Du für jede Operation auf jedem Objekt ein eigenes Recht brauchst (das ist maximal mächtig, aber auch am meisten Verwaltungsarbeit) oder ob Du bestimmte Operationen zu Klassen zusammenfassen kannst, welche über ein gemeinsames Recht gesteuert werden sollen.
Und überlege Dir das _gründlich_ - denn die Struktur Deiner Recht wird das Format der Datenstruktur festlegen, in welcher diese Rechte gespeichert sein werden. Und diese nachträglich ändern zu müssen, das wäre ziemlich häßlich (Speichermodell anpassen, Konfigurationsanwendungen anpassen, bestehende Daten migrieren ...).
Und noch eine Überlegung: Webprojekte sind ja sehr
unterschiedlich. Wenn es zum Beispiel einfach nur
darum geht, Guckrechte zu vergeben, dann reicht
.htaccess mit Sicherheit aus.
Du kannst das, was erlaubt sein soll, beispielsweise auch von der verwendeten HTTP-Methode abhängig machen. (GET zum Gucken, aber POST zum Schreiben?)
Direktive: <Limit>
(http://httpd.apache.org/docs/mod/core.html#limit)
Vielleicht sollte ich das von vornherein so basteln,
daß es pro Projekt einen Schalter gibt: $authentType
= "htaccess" oder eben $authenType =
"ichweissnichtwiedaskindheissensoll"?
Klingt in Version 1.0 irgendwie nach Overkill. ;-)
Aber je sauberer Du modular programmierst, d. h. die gesamte Autentifizierung in eigene Module auslagerst, desto einfacher kannst Du später diese Funktion austauschen bzw. erweitern, ohne daß der Rest Deiner Programme etwas merkt.
Deine eigentliche Logik für die Berechtigungsprüfung _darf_ nicht wissen, ob Du die Benutzerkennung aus REMORE_USER oder aus einem Cookie oder aus einer PHP-Session-Kennung hast.
Je dünner die Kanten zwischen Deinen Modulen sind, desto leichter kannst Du einen von ihnen austauschen, ohne daß die anderen das mitkriegen.
Viele Grüße
Michael