Zugriff auf Dateien ohne htacess blockieren?

[Pragma]

Warum hältst du Sessions hier für einen guten Ort der Ablage?
Wenn eine Datei dazu gekommen ist seit dem letzten Listen, muss der User sowieso erst die Liste aktualisieren lassen. Dabei wird dann Verzeichnis-Array in der Session gelöscht und ein neues aufgebaut.
Halten wir fest: Statt nur zu scannen und auszugeben, muss bei Ausgabe der Liste jedes mal das Scanergebnis zusätzlich in die Session gedumpt werden. Für jeden Client!
a) Derartige Aktionen würde ich ohne Authentifizierung sowieso nicht zulassen.

Okay, entspricht ja auch der OP Anforderung. Die Problematik bleibt allerdings bestehen, nur die potentielle Anzahl der Clients wird reduziert.

b) Für die Authentifizierung beiten sich nur HTTP Basic Auth und Sessions (mit Cookies) an. Ich tendiere hier zu Sessions.

Allgemein präferiere ich auch Sessions via Cookies, halte es bzgl. der Fragestellung aber nicht für relevant. Für deinen Ansatz ist es Bedingung.

c) Wenn eine Session eröffnet ist, wird das $_SESSION-Array ohnehin beim Script-Exit in die Sessiondatei zurückgeschrieben.
d) ein $_SESSION['filesearch'] = glob( ...); ist der einfachste Weg, das Ergebnis der (gefilterten) Suche abzulegen, um es dann anschließend der Ausgabefunktion zu übergeben (Listenelemente für HTML aufbauen)

Dass zur Ablage einer gefilterten Suche ein Dump in die Session zunächst als _einfachster_ Weg erscheint, _kann_ sein. Im konkreten Fall bedeutet es, höchst redundante Daten(immer wieder) zu erzeugen. Ich halte das für schlechtes Design und bei hinreichend vielen Dateien(evtl. in weiteren Unterordner) / Clients wird das ein Problem.

Der Eintrag in der Session ist praktisch, weil dadurch eine Transformation zur Entkopplung der wahren Dateipfade von den dem Browser gelieferten Ressourcennamen möglich ist...

Auf den ersten Blick womöglich praktisch, ich halte es für den falschen Weg. BTW: "Tansformation zur Entkopplung" = B.....bingo? ;-)

Abseits der Frage, ob es sinnvoll ist: Es gibt viele Möglichkeiten, um von dir beschriebenes zu erreichen, das ist keine Frage des Speicherorts.
Hier irrst Du. Der praktischste Speicherort für eine Übersetzungsliste in einem authentifizierten Client-Server-Dialog ist die Sessiondatei. Über die Sessiondatei sind diese Daten dann automatisch kit dem Client in Verbindung zu bringen.

Sehe ich natürlich anders ;-) Sofern du unterstellst, die Erzeugung einer Übersetzungliste pro Client sei hier sinnvoll, ist ein Dump womöglich auf den ersten Blick praktisch, einige Nachteile habe weiter oben skizziert.

Ich sehe zwei Möglichkeiten, wie die "Übersetzungsliste" enstehen kann:

1. Der vielbesagte Scan, ein Abbild der Ordnerstruktur. Das pro Client zu speichern, ist schlechtes Design - egal wo! Wenn ich es seperat speichere, dann zentral. Ein Grund hierfür könnten sehr viele Dateien plus etwaiges Paging sein. Sonst sehe ich bei besagter Aufgabenstellung den Scan "Just in time" zur Generierung der Liste. Also genau wie du, nur eben ohne das Ergebnis in die User-Session zu klatschen.

2. Womöglich sogar individuell, feinkörnig gesteuert? Wenn ich sowas brauche, muss ich es auch irgendwo pflegen. Die Session wäre ein ziemlich doofer Ort dafür.

WIr erinnern uns: HTTP ist von Haus aus zustandslos,

Danke für den Hinweis. Ich gebe dir Recht: Man kann es nicht oft genug sagen.

ein gestaffelter Dialog ist aber zustandsorientiert.

Gestaffelter Dialog? Noch nie gehört. Ist das ein spezifizierter Begriff?

Durch die Session wird diese Zustandsorientierung herbeigeführt.

Yes yes.

Man spart sich damit einen Filesystem-Scan, der ja zur Erstellung der Liste notwendig wäre.
das sollte heißen: ...der ja bei der Erstellung der Liste ohnehin durchgeführt wurde und daher beim Request zum Download nicht unbedingt ein zweites Mal durchgeführt werden muss.
Liest sich gut, stimmt aber nicht(siehe oben)!
Wieso stimmt das nicht?

Es stimmt(e) nicht, weil dein nachgereichter Hinweis "das sollte heißen:..." fehlte?!

Wieso soll eine Information weggeschmissen werden, die ich später nochmal benötige?

Sie ist nur unter dem von dir gewählten Modell "später benötigt". Du skizzierst also einen Vorteil der _einen_ Nachteil _einer_ Phase des von dir als "good practice" beschriebenen Modells abmildert!

Der Ablauf ist:
   Dokument 1:
      bietet das Scannen von Dateien an.

Dokument 2 (überschreibt Dokument 1):
      bietet die gescannte Liste an für den Download
      und. einen Zurück-Link oder z.B. die Standardnavigation

Dokument 3 (eigenes Fenster für den Download-Dialog):
      liefert das angeforderte File aus

Die Liste (Dokument 2) kann dabei solange stehen bleiben, bis der User meint, sie neu einlesen lassen zu müssen, weil sich etwas geändert haben könnte.

Mir war das von dir entworfene Modell soweit schon klar, trotzdem danke für die Skizze. Sie bringt mich auf einen weiteren Punkt: Die Weitergabe von Direktlinks (z.B. via E-Mail, Messenger) á la "Hey du! Unter http://www.example.org/secure.php?file=hammer.pdf liegt das neue PDF!" für bereits eingeloggte Clients ist so unmöglich, bzw. erfordert den Hinweis: "Bevor der Link funktioniert, aktualisiere bitte zuerst die Übersicht". Ich finde das ziemlich uncool.

und zur Feststellung, ob die angeforderte Datei wirklich im erlaubten Verzeichnis liegt, sonst notwendig wäre.
Dafür braucht es keinen Scan, sondern einen simplen Test.
So, nun möchte ich den _einfachen_ Test sehen, mit dem festgestellt wird, ob die Datei dem User zusteht!

Gerne. Um es noch simpler zu halten, zwinge ich den Request in den erlaubten Bereich. Folgender Pseudocode ist zwar Perl, dürfte aber für PHP analog abbildbar sein:

<pseudocode>
...
my $erlaubterOrdner = '/var/www/secure/';
my $gewuenschteDatei = $ENV{'gewuenschteDatei'};

# Nur erlaubte Zeichen zulassen - Slash erlauben, vielleicht sind ja Unterordner relevant
$gewuenschteDatei =~ s/[^a-zA-Z0-9./]//g;

# "dir escape" entfernen - wg. erlaubtem Slash
$gewuenschteDatei =~ s/..///g;

# Zieldatei bestimmen
my $zielDatei = $erlaubterOrdner . $gewuenschteDatei;

# Datei verarbeiten
open($zielDatei)
...
</pseudocode>

Um das nochmals in Erinnerung zu bringen:
Mein obiger Vorschlag ist nur für sessionorientierte Rechteverwaltung (Login/Rechteprüfung bei  Sessionstart) sinnvoll, nicht jedoch bei requestbasierten (Login/Rechteprüfung bei jedem Request).

Auch wenn mir nicht 100% klar ist, worauf du hinaus willst: würdest du diese Einschränkung bei meinem Vorschlag auch machen?