Hallo Tom,

dass Dateien mit . vorneweg ausgeblendet werden, hatte ich auch verstanden. Ich hing noch am Rest.

Damit der eingespielte Schlüssel nicht versehentlich als Skript ausgeführt werden kann, wird mit "engine off" die Skriptausführung deaktiviert.

Da steht "RewriteEngine off" - das lese ich jetzt so: FALLS mod_rewrite aktiv ist, sollen bei Zugriffen in diesen Ordner keine Rewrites durchgeführt werden. Den Bezug zu Skriptausführungen sehe ich nicht - aber ich bin ja auch kein Winnetou.

Den Satisfy Any verstehe ich so: Satisfy stellt einen Bezug zwischen Allow/Deny und Require her (also User-basierende Berechtigungen). Im Normalfall wird also zunächst geschaut, ob es irgendeinen Deny für diesen Ordner gibt, und wenn nicht, wird der Zugriff für alle Herkunftadressen erlaubt. Der Satify Any sorgt dafür, dass Benutzerberechtigungen dann keine Rolle mehr spielen. Jeder kann Dateien ohne Punkt vorneweg lesen, egal ob eingeloggt oder nicht.

Ich kenne das von Let's Encrypt verwendete Schema in acme-challenge Ordner nicht. Aber - ist dieser Allow from all nicht etwas zu großzügig? Muss man das nicht präziser einstellen?

Falls der Dateiname mit einem Punkt beginnt, wird die Order herumgedreht, so dass Deny als letztes kommt und Vorrang vor eventuell anderswo stehenden Allows hat (z.B. dem direkt darüber).

Aber hier kommt, wenn ich das richtig verstehe, der Satisfy Any leicht quer: Der sorgt nämlich dafür, dass eine eventuell irgendwo stehende Require Direktive den Zugriff dennoch erlauben kann. Stünde bspw. irgendwo Require valid-user, dann würde jeder (per HTTP Login) angemeldete User die Schlüsseldateien lesen können.

Das scheint mir jetzt nicht im Sinne des Erfinders zu sein. Muss in den <FilesMatch> nicht noch ein Satisfy All hinein? Okay, solange keine HTTP-Authentication auf der Seite verwendet wird, passt das. Aber wenn irgendwer meint, sowas nutzen zu müssen, könnte das ein Schlüssel-Leak erzeugen.

Rolf