Alles anzeigen was im Verzeichnis ist ?!?

[Marco]

Hallo zusammen,

nun ich muss einen passwortgeschützten Bereich machen wo einfach alle Dateien welche sich in dem Ordner befinden anzeigen. Also auch Word & Excel Dokumente. Das mit dem Passwortschutz ist kein Problem mache ich einfach mit .htaccess aber was ich nicht ganz verstehe ist wenn doch keine index.html Datei in dem Ordner ist sollten doch einfach die Daten angezeigt werden...

Bei mir kommt aber dann eine Meldung dass ich keine Rechte habe diesen Order anzuzeigen.

Hier die Meldung:

Forbidden
You don't have permission to access /intranet/ on this server.

Muss ich jrgendwas in der .htaccess Datei ändern oder was muss ich machen damit es mir alle Dateien Anzeigt ?!?

Freue mich auf Eure Antworten

Gruss Marco

[Anleitungsstubser]

wenn doch keine index.html Datei in dem Ordner ist sollten doch einfach die Daten angezeigt werden...

Forbidden
You don't have permission to access /intranet/ on this server.

http://httpd.apache.org/docs/mod/mod_autoindex.html

[Marco]

Ups kannst Du mir das nicht rasch erklären !! Verstehe da nur Bahnhof ;o)

[MADU]

hallo,

Ups kannst Du mir das nicht rasch erklären !! Verstehe da nur Bahnhof ;o)

http://spotlight.de/zforen/web/m/web-1033648378-8093.html

lg
MADU

[Uschi Renziehausen]

Hallo MADU,
Das hilft ihm doch *SO* nicht, wenn er auf die Konfig seines virtual hosts beim Provider keinen Einfluß hat. Dann muss er das doch irgendwie in der .htaccess notieren, oder nicht?
gruß, uschi

[MADU]

Hallo MADU,

hallo uschi,

Das hilft ihm doch *SO* nicht, wenn er auf die Konfig seines virtual hosts beim Provider keinen Einfluß hat. Dann muss er das doch irgendwie in der .htaccess notieren, oder nicht?

wenn es sich um einen virtuellen host bei einem provider handelt, dann hätte das wohl in der fragestellung erwähnt gehört.
davon abgesehen ist "Options Indexes" im .htaccess-kontext kein problem - sofern die konfiguration des webservers (AllowOverride) es zulässt.

gruß, uschi

lg
MADU

[Marco]

wenn es sich um einen virtuellen host bei einem provider handelt, dann hätte das wohl in der fragestellung erwähnt gehört.
davon abgesehen ist "Options Indexes" im .htaccess-kontext kein problem - sofern die konfiguration des webservers (AllowOverride) es zulässt.

Uii kannst Du mir mal ein Beispiel schreiben wie dan meine .htaccess aussehen sollte das es funktioniert wäre echt klasse nett !!

Danke für die Bemühungen !!

Achja, gibts nicht evt. einen PHP-Befehl der das auch kann alle Dateien in einem Verzeichnis anzeigen... Gibts doch sicher oder...

Wäre noch fast besser..

Grüsse Marco

[MADU]

hallo,

[...] Achja, gibts nicht evt. einen PHP-Befehl der das auch kann alle Dateien in einem Verzeichnis anzeigen... Gibts doch sicher oder [...]

versuch's mal hier: http://de.php.net/manual/de/ref.filesystem.php
auch im abschnitt "user contributed notes" gibt's sicher einiges, worauf du aufbauen kannst.

Grüsse Marco

lg
MADU

[Uschi Renziehausen]

gugucks,

Achja, gibts nicht evt. einen PHP-Befehl der das auch kann alle Dateien in einem Verzeichnis anzeigen... Gibts doch sicher oder...

Die Frage habe ich gestern schon mal beantwortet. Vgl.:
http://forum.de.selfhtml.org/?m=139021&t=25372

Liebe Grüße, Uschi

[Marco]

Liebe Uschi,

vielen Dank für die Bemühungen aber habe immer noch ein Problem, ich möchte, dass ich dann die Dateinamen anklicken kann und sich dann z.b das Wordokument öffnet verstehst Du was ich meine.

Also nicht das es einfach die Dateien auflistet. Habe mich wohl etwas  zu ungenau ausgedrückt...

Geht das jrgendwie.

Küsschen Marco ;o)

[Uschi Renziehausen]

Geht, indem wir einfach um jeden Dateinamen ein <a href malen.

<?php
// ne variable mit dem realen pfad zum gewünschten directory
$myDir = $DOCUMENT_ROOT ."/forumshelper";

// directory öffnen und in den zurückgegebenen handler in variable
// speichern
$dirHandler = opendir($myDir);
// mit readdir durchs directory schleifen und den jeweiligen
// Dateinamen in $file speichern
 while($file = readdir($dirHandler)) {
    // hier wirds rausgeblasen
    echo "<a href="$file">$file<a><br />";
 }
// und das directory wieder schließen
closedir($dirHandler);
?>

[Marco]

Hallo Uschi,

Wow Du hast es ja voll im Griff ! Es klappt. Jetzt muss ich nur noch ein Login machen, dass habe ich schon oft gemacht, aber ich frage mich einfach wie sicher das eigentlich ist. Ich benutze dazu die Sessions-ID und ein Benutername.

Schau mal hier www.gottardiprint.ch/beta/login.php

Sowas ist doch sehr sicher oder?!?

Freue mich auf Deine Antwort !!

Supi...

[Uschi Renziehausen]

der link stimmt nicht
www.gottardiprint.ch/beta/login.php

schicke seite übrigens. ist das dein eigener laden oder ist das für die liebe kundschaft?
zwei dinge:

1. Öffnungszeiten und Standort gehören unter KONTAKT, nicht unter HOME. Home ist in meinen und wahrscheinlich vieler User Augen eben die Startseite und sonst nix.
2. Dein Kontaktformular ist zu winzig. Wenn ich darüber wirklich eine etwas ausführlichere Anfrage schicken möchte, kriege ich ja einen Pips. Auch für die Adresse könntest du ein paar mehr Felder anlegen.

Wow Du hast es ja voll im Griff !

Leider nicht, und was glaubst du, woran ich gerade bastele: Einem Benutzermanagement. Und genau davon habe ich leider keine Ahnung, bin sozusagen gerade dabei, mir die zu verschaffen.

gruss, uschi

[Marco]

Hallo und guten Morgen Uschi,

ich bin auch gerade daran ein Benutzermanagement zu machen, d.h einfach so einen wo Sich die Leute einloggen können und Datei hochladen Datein löschen usw.

Achja der Link :o) habe ich falsch sorry hier der richtige

www.gottardiprint.ch/beta/CMS/login.php

dort mache ich auch das Passwort mit MD5 verschlüsselt übergeben.

Danke noch für das Kompliment der Seite, ich habe noch einige mehr erstellt, aber die kann ich Dir ja später mal zeigen wenn es Dich intressiert.

Übrigens, für mich gibts Du immer sehr kompetente Antworten und mega lieb für das einfach mal eine riiiiese Blume für Dich !!

Danke und ich freue mich auf Deine Antwort oder schreib mir doch ein Mail an: [e-mail]

freue mich !!

[Uschi Renziehausen]

Gugucks,

www.gottardiprint.ch/beta/CMS/login.php

Dir ist aber klar, dass ich da nur sehen kann, was dein php-script so an html auswirft, oder?

» Danke noch für das Kompliment der Seite, ich habe noch einige mehr erstellt, aber die kann ich Dir ja später mal zeigen wenn es Dich intressiert.
oki, machen wir demnächst mal eine besichtigungstour.

Übrigens, für mich gibts Du immer sehr kompetente Antworten und mega lieb für das einfach mal eine riiiiese Blume für Dich !!

Oh, vielen lieben Dank auch.

Schönes Restwochenende, Uschi

[Michael Schröpl]

Hallo Uschi,

Wow Du hast es ja voll im Griff !

finde ich irgendwie auch. Du entwickelst Dich langsam aber Sicher zu Allzweckwaffe. ;-)

Leider nicht, und was glaubst du, woran ich gerade
bastele: Einem Benutzermanagement.
Und genau davon habe ich leider keine Ahnung, bin
sozusagen gerade dabei, mir die zu verschaffen.

Was genau willst Du denn erreichen?
Mit welchen Browsern muß es funktionieren?
Was davon erfüllt
     http://aktuell.de.selfhtml.org/artikel/server/htaccess/
nicht?

Viele Grüße
      Michael

[Uschi Renziehausen]

Hallo Michael,

finde ich irgendwie auch. Du entwickelst Dich langsam aber Sicher zu Allzweckwaffe. ;-)

knix :-))

Was genau willst Du denn erreichen?

Ich bin gerade dabei, das zu formulieren, damit aber noch keineswegs fertig. Ich bastele also noch nicht, ich hirne noch rum. Sobald das in verständliche Form gegossen ist, würde ich dich schrecklich gern damit belästigen.
Der Grundsatz ist erstmal der:
Ich habe auf der einen Seite Seiten. In diesen Seiten befinden sich irgendwelche Objekte. Seiten wie darin enthaltene Objekte können angeguckt, geändert, gelöscht und sonst noch was werden.
Auf der anderen Seite habe ich User und Nutzergruppen:
Manche User dürfen die Seite gar nicht sehen, andere dürfen nur bestimmte Objekte auf der Seite sehen, andere, zum Beispiel ich, dürfen alles sehen. Das meiste davon ist gruppenbezogen, manchmal darf aber nur der owner.

Damit dürfte auch klar sein, warum ich mit deinem schönen .htaccess-Artikel hier nicht weiterkomme: Die .htaccess bezieht sich ja immer auf ein Verzeichnis.

Mit welchen Browsern muß es funktionieren?

Ich habe innerlich beschlossen, Netscape 4.x draußen zu lassen. Ich bin ein Fan des DOM, seitdem funzen meine JS-Scripts endlich :-))
Also Browser, die DOM1 unterstützen.
An manchen Stellen wäre es gut, diese Editor-Komponente des IE nutzen zu können. Das ist aber leider proprietär.

Ich hoffe, das war jetzt nicht zu allgemein. Ich möchte das nämlich allgemein halten, um nicht für jede Spezialanwendung die Welt (oder auch die Admintools) neu erfinden zu müssen.

Wenn ich mit den allgemeinen Überlegungen durch bin, wollte ich mit ein paar ziemlich verschiedenen Beispielanwendungen (die ich auch benötige) experimentieren.

liebe Grüße, Uschi

[Michael Schröpl]

Hallo Uschi,

Ich bin gerade dabei, das zu formulieren, damit
aber noch keineswegs fertig. Ich bastele also noch
nicht, ich hirne noch rum.

hervorragende Einstellung. :-)

Sobald das in verständliche Form gegossen ist,
würde ich dich schrecklich gern damit belästigen.

Fein. Nur zu!

Ich habe auf der einen Seite Seiten. In diesen
Seiten befinden sich irgendwelche Objekte.
Seiten wie darin enthaltene Objekte können
angeguckt, geändert, gelöscht und sonst noch was
werden.

Sind "Objekte" eigene URLs?
Also etwas, das im HTTP-Universum eine Identität hat?

Manche User dürfen die Seite gar nicht sehen,
andere dürfen nur bestimmte Objekte auf der Seite
sehen,

Oh. Das klingt so, als müßtest Du die Seiten dynamisch mit serverseitiger Intelligenz bauen. (Die aber durchaus auf HTTP-Authentication-Informationen zugreifen kann - REMOTE_USER würde helfen, die Gruppenzugehörigkeit müßtest Du allerdings selbst herausfinden.)
Eine Zugriffskontrolle mit broken images wird Deine Anwender alleine nicht glücklich machen.

andere, zum Beispiel ich, dürfen alles sehen.
Das meiste davon ist gruppenbezogen, manchmal darf
aber nur der owner.

Ist "der owner" gleich dem UNIX owner der Datei?
Hast Du Namensgleichheit zwischen der HTTP-Identität und der UNIX-Identität?
Leitet sich die Authentifizierungskonfiguration der HTTP-Seite aus derjenigen der UNIX-Seite ab?
(Gemeinsames Skript zum Anlegen eines Benutzers?)

Damit dürfte auch klar sein, warum ich mit deinem
schönen .htaccess-Artikel hier nicht weiterkomme:
Die .htaccess bezieht sich ja immer auf ein
Verzeichnis.

Ja - aber innerhalb derselben kannst Du mit <Files> beliebig fein Deine Objekte berechtigen. Daran alleine scheitert die Sache also nicht.

Dein Problem ist eher, daß HTTP Authentication Dir keine hinreichend flexiblen Fehlerreaktionen erlaubt, wenn Du Seiteninhalte dynamisch entitlement-basiert aufbauen mußt, ohne daß man dabei sehen kann, daß die Seite für andere Anwender anders aussehen würde.
Das sieht dann also eher nach einem CGI-Skript etc. aus, welches ggf. basierend auf ENV{'REMOTE_USER'} per Dateizugriff (Gruppen-Definitionen) seine Authentifizierung selbst macht und das Ergebnis verwendet, um aus den verfügbaren Objekten (deren Relation zu den Gruppen-Rechten ebenfalls gelesen werden muß) die anzeigbaren herauszusuchen und anschließend die Ausgabe zusammenzukleben.

Mit welchen Browsern muß es funktionieren?
Ich habe innerlich beschlossen, Netscape 4.x draußen zu lassen.
Also Browser, die DOM1 unterstützen.

Meine Frage bezog sich auf Netscape 6.2, der noch kein AuthType Digest kann - falls Kennwort-Übertragung im Klartext Dich nicht stört, würde allerdings AuthType Basic auch reichen.

Ich hoffe, das war jetzt nicht zu allgemein.

Ein allgemeiner Ansatz ist prima - das hält den Kopf frei für die wichtigen Entscheidungen und verhindert, daß Du Dich zu früh auf die Details stürzt.
Sollte eine Design-Entscheidung in dieser Allgemeinheit nicht umsetzbar sein, dann merkt man das spätestens bei der Modellierung der Daten und Algorithmen.

Viele Grüße
      Michael

[Uschi Renziehausen]

Gugucks Michael :-))

Sobald das in verständliche Form gegossen ist,
würde ich dich schrecklich gern damit belästigen.

Fein. Nur zu!

Weißt du auch wirklich, worauf du dich einläßt *grinsel*? Aber danke! Schade, daß dieser Thread schon soweit unten steht. Denn ich stelle, wie schon öfter fest, daß die Kommunikation mir Dir hilft, sich über den eigenen Wust im Hirn klar zu werden. Und im Moment habe ich soviele Knoten im Kopf, daß ich dankbar bin, wenn einer sie aufzudröseln hilft.

Ich habe auf der einen Seite Seiten. In diesen
Seiten befinden sich irgendwelche Objekte.
Seiten wie darin enthaltene Objekte können
angeguckt, geändert, gelöscht und sonst noch was
werden.

Sind "Objekte" eigene URLs?
Also etwas, das im HTTP-Universum eine Identität hat?

Nicht immer, würde ich sagen. Vielleicht sollte ich versuchen, den Begriff "Objekt", wie ich ihn innerhalb dieses Konzepts verstehe, wenn schon nicht zu definieren, so doch näher zu beschreiben, um das Kind mal einzukreisen.
Jedes Webprojekt ist ist in meien Augen ein baumartig strukturiertes Gebilde miteinander kommuzierender Bestandteile der unterschiedlichsten Art. Dazu gehören auch Verzeichnisse und einzelne Seiten, wobei diese im HTTP-Universum existieren. Was nun aber auf den einzelnen Seiten steht, kann (und wird) ja ganz oder in Teilen auch aus einer Datenbank kommen. Zumindest in dem Moment, wo ich meinen Nutzer autentifiziere, wird er zum Bestandteil des Baumes und damit zum Objekt (der Arme), der unter Umstanden mit einem Datensatz oder auch nur bestimmten Feldern desselben kommuniziert.

Manche User dürfen die Seite gar nicht sehen,
andere dürfen nur bestimmte Objekte auf der Seite
sehen,

Oh. Das klingt so, als müßtest Du die Seiten dynamisch mit serverseitiger Intelligenz bauen.

Das ist mit Sicherheit so, und bei manchen Sachen wird es sehr dynamisch. Das was ich im letzten Jahr so gebastelt habe, war immer eine Kombi aus PHP und MySQL. Vorletzte Woche wurde ich ein wenig fortgebildet in Sachen XML-XSLT, wobei da aber noch ein Schwein-Uhrwerk-Verhältnis besteht.

(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?

Eine Zugriffskontrolle mit broken images wird Deine Anwender alleine nicht glücklich machen.

Nicht wirklich ;-)

andere, zum Beispiel ich, dürfen alles sehen.
Das meiste davon ist gruppenbezogen, manchmal darf
aber nur der owner.

Ist "der owner" gleich dem UNIX owner der Datei?

Nein, denn es kann sich ja auch um einen Datensatz oder einen Teil davon handeln. Zum Beispiel so: Alle Redaktionsmitglieder dürfen die E-Mail-Adressen der anderen Redaktionsmitglieder sehen, aber nur der Eigentümer -- oder irgendeiner mit höheren Rechten -- darf die ändern.

Hast Du Namensgleichheit zwischen der HTTP-Identität und der UNIX-Identität?

Nein, es ist mir an der Uni nicht gegeben, auf UNIX-Identitäten zuzugreifen.

Leitet sich die Authentifizierungskonfiguration der HTTP-Seite aus derjenigen der UNIX-Seite ab?
(Gemeinsames Skript zum Anlegen eines Benutzers?)

Nein. Vielleicht verstehe ich dich auch nicht richtig. Was meinst du genau, mal so für DAUS erklärt :-))

Damit dürfte auch klar sein, warum ich mit deinem
schönen .htaccess-Artikel hier nicht weiterkomme:
Die .htaccess bezieht sich ja immer auf ein
Verzeichnis.

Ja - aber innerhalb derselben kannst Du mit <Files> beliebig fein Deine Objekte berechtigen. Daran alleine scheitert die Sache also nicht.

DAS wusste ich nicht, der Indianer und ich stehen immer noch auf Kriegsfuß. Kannst du nicht noch ein paar mehr so schöne Artikel wie http://aktuell.de.selfhtml.org/artikel/server/htaccess/index.htm schreiben, bitte? Der hat mir wirklich geholfen, wenigstens einen Einstieg zu kriegen.

Mit welchen Browsern muß es funktionieren?
Meine Frage bezog sich auf Netscape 6.2, der noch kein AuthType Digest kann - falls Kennwort-Übertragung im Klartext Dich nicht stört, würde allerdings AuthType Basic auch reichen.

Unter Netscape 6.2 muss es funktionieren, aber bis das fertig ist, kann der bestimmt auch AuthType Digest, wobei mir unklar ist, was der da eigentlich verdaut, ich lese das hier zum ersten Mal. Wie gesagt, ich stecke wirklich noch in den Anfängen, und ich weiß entschieden zu wenig.

Mir ist prinzipiell unklar, worin die Vor- und Nachteile einer Authentifizierung via DB und .htaccess liegen. Ich überlege im Moment nur, was eigentlich alles möglich sein muß.
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?

Und noch was: Ich habe schlicht keine UNIX-Kenntnisse. Wenigstens im Ansatz blicke ich bei Novel durch.
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.

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.

Vielleicht sollte ich das von vornherein so basteln, daß es pro Projekt einen Schalter gibt: $authentType = "htaccess" oder eben $authenType = "ichweissnichtwiedaskindheissensoll"?

Liebe Grüße, Uschi
(die jetzt leider mal was zu essen machen und zuvor noch ein paar lebende töpfe töten muss)

[Michael Schröpl]

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

[Sönke Tesch]

davon abgesehen ist "Options Indexes" im .htaccess-kontext kein problem - sofern die konfiguration des webservers (AllowOverride) es zulässt.

Uii kannst Du mir mal ein Beispiel schreiben wie dan meine .htaccess aussehen sollte das es funktioniert wäre echt klasse nett !!

"Automatic index generation is enabled with using Options +Indexes. See
  the Options directive for more details."
  http://httpd.apache.org/docs/mod/mod_autoindex.html

Also

options +indexes

in die .htaccess. Die dann ausgegebene Liste kannst Du mit IndexOptions weiter anpassen, den Abschnitt lese ich jetzt aber nicht vor (http://httpd.apache.org/docs/mod/mod_autoindex.html#indexoptions).

Achja, gibts nicht evt. einen PHP-Befehl der das auch kann alle Dateien in einem Verzeichnis anzeigen... Gibts doch sicher oder...

Nein, aber das hat Uschi ja schon erklärt.

Wäre noch fast besser..

Das bezweifle ich, solange es sich wirklich nur um eine reine Verzeichnisliste handelt.

Gruß,
  soenk.e

[Uschi Renziehausen]

Moin Marco,
ich kann dir leider nicht wirklich aus der Klemme helfen, weil ich von Apache-Konfiguration via .htaccess zu wenig Ahnung habe. Immerhin weiss ich aber, warum nicht funktioniert, was du da möchtest.
Was passiert, wenn keine index.html oder was sonst in der Webserver-Konfiguration als automatisch zu öffnende Datei eingetragen ist, wenn einfach nur ein Verzeichnis angefordert wird, ist abhängig davon, welche Optionen für dieses Verzeichnis gesetzt sind.
Sollen die Dateien in dem Verzeichnis angezeigt werden, muß die Option +Indexes aktiviert sein, sonst kommt forbidden.
Ist ja eigentlich auch klar, denn wer möchte schon, dass beliebige User alle Dateien in einem Verzeichnis sehen können. Also ist diese Option standardmäßig nicht eingetragen.
Ich vermute mal, dass du die Indexes für ein bestimmtes Verzeichnis in einer .htaccess freischalten kannst, aber ich kann dir auch nicht sagen, wie das geht. Vielleicht erbarmt sich ja jemand anders :-))
Gruß, Uschi

du irrst, wenn du meinst, dass der DirectoryIndex aut

Ups kannst Du mir das nicht rasch erklären !! Verstehe da nur Bahnhof ;o)

[Uschi Renziehausen]

Schwanzabschneider