Passwortabfrage & mod_rewrite -> wer kommt zuerst?
Felix Riesterer
- webserver
Liebe Selfer,
ich habe auf meinem Webspace (Apache) ein geschütztes Unterverzeichnis (root/a/b/c) in welchem sich eine index.html befindet. Diese index.html enthält einen meta-refresh auf eine script.php im selben Verzeichnis. Die Ausgabe der script.php muss unbedingt Passwort-geschützt sein, daher habe ich sie in ein solches Verzeichnis abgelegt.
Mein mod_rewrite biegt alle Requests auf HTML-Dateien um. Diese landen dann bei einer zentralen index.php, die den Request-Pfad auswertet, um entsprechend zu reagieren. Bei index.html-Dateien, in welchen ein meta-refresh enthalten ist, wird anhand einer Liste geprüft, ob diese sich in einem geschützten Unterverzeichnis befinden, um im gegebenen Fall eine Seite mit einem entsprechenden Hinweis auszugeben, unter dem dann der Link auf die im refresh angegebene Datei steht. In diesem speziellen Fall geht es um script.php.
Übersicht der drei Dateien:
root/a/index.php
root/a/b/c/index.html
root/a/b/c/script.php
Wenn jetzt meine "root/a/b/c/index.html" im Browser aufgerufen wird, dann kommt sofort die Passwortabfrage, die ja genau dann _nicht_ sein soll, da über die zentrale index.php erst ein Hinweis auf ein solches Passwort ausgegeben werden soll. Die index.html wird ja auch nicht ausgegeben, sondern der Request landet per mod_rewrite bei der index.php, die - nach erfolgter Passworteingabe - dann auch brav den nun obsoleten Hinweis auf das Passwort ausgibt.
Es war mir schon einmal gelungen, dass ein Hinweis ohne Passwortabfrage ausgegeben wurde, aber da ich nicht sicher weiß, ob am Server etwas geändert wurde, oder ob es an einer Änderung meiner Scripte liegt, möchte ich gerne mehr über die innere Funktionsweise des Apachen wissen.
Daher meine Frage: Was wird beim Request auf eine Datei zuerst ausgeführt? Die Prüfung auf Passwörter oder mod_rewrite?
Die Doku-Seite zu mod_rewrite ist so komplex, dass ich dort von alleine nicht durchsteige. Daher danke ich allen, die mir hier weiterhelfen können.
Liebe Grüße aus Ellwangen,
Felix Riesterer.
hi,
Die Doku-Seite zu mod_rewrite ist so komplex, dass ich dort von alleine nicht durchsteige.
hast du dort insb. mal den abschnitt Internal Processing durchgeschaut?
"First you have to understand that when Apache processes a HTTP request it does this in phases. A hook for each of these phases is provided by the Apache API. Mod_rewrite uses two of these hooks: the URL-to-filename translation hook which is used after the HTTP request has been read but before any authorization starts and the Fixup hook which is triggered after the authorization phases and after the per-directory config files (.htaccess) have been read, but before the content handler is activated.
So, after a request comes in and Apache has determined the corresponding server (or virtual server) the rewriting engine starts processing of all mod_rewrite directives from the per-server configuration in the URL-to-filename phase. A few steps later when the final data directories are found, the per-directory configuration directives of mod_rewrite are triggered in the Fixup phase."
heißt, nach meinem verständnis, folgendes:
zuerst mal werden die (eventuellen) RewriteRules abgefrühstückt, die in der server-konfiguration hinterlegt sind.
anschließend wird im jeweiligen verzeichnisbaum (dessen erreichen jetzt schon durch "URL-to-filename"-umschreibungen passiert sein kann) nach anweisungen in .htaccess-dateien geschaut.
dort hinterlegte RewriteRules werden jetzt aber erst berücksichtigt, _nachdem_ eine evtl. für diesen verzeichniszweig erforderliche Authentifizierung durchgeführt wurde.
Die Ausgabe der script.php muss unbedingt Passwort-geschützt sein, daher habe ich sie in ein solches Verzeichnis abgelegt.
reicht es für dein vorhaben evtl. aus, _nur_ diese script-datei per HTTP Auth zu schützen? (und nicht das gesamte verzeichnis)
die dafür notwendigen anweisungen kannst du innerhalb der .htaccess-datei nämlich auch innerhalb einer <Files>- oder <FilesMatch>-direktive unterbringen.
gruß,
wahsaga
Lieber wahsaga,
heißt, nach meinem verständnis, folgendes:
zuerst mal werden die (eventuellen) RewriteRules abgefrühstückt, die in der server-konfiguration hinterlegt sind.
anschließend wird im jeweiligen verzeichnisbaum (dessen erreichen jetzt schon durch "URL-to-filename"-umschreibungen passiert sein kann) nach anweisungen in .htaccess-dateien geschaut.
dort hinterlegte RewriteRules werden jetzt aber erst berücksichtigt, _nachdem_ eine evtl. für diesen verzeichniszweig erforderliche Authentifizierung durchgeführt wurde.
Jetzt sehe ich _definitiv_ klarer. Vielen Dank! Dieses englische Fachchinesisch fällt mir noch sehr schwer zu verstehen...
Die Ausgabe der script.php muss unbedingt Passwort-geschützt sein, daher habe ich sie in ein solches Verzeichnis abgelegt.
reicht es für dein vorhaben evtl. aus, _nur_ diese script-datei per HTTP Auth zu schützen? (und nicht das gesamte verzeichnis)
Das wäre durchaus eine Überlegung wert. Da ich in meinen Admin-Tools aber eine <Files>-Direktive (noch) nicht integriert habe, bleibe ich (vorerst) beim Passwortschutz per-Directory. Meine Lösung ist jetzt, dass ich einfach einweiteres Unterverzeichnis erstellt habe, in welchem ich den Passwortschutz aktiviert habe, so dass die Index-Datei ohne Passwort erreicht werden kann.
Die Situation sieht jetzt so aus:
root/a/index.php
root/a/b/c/index.html (ohne .htaccess, enthät Link auf "d/script.php")
root/a/b/c/d/script.php (mit .htaccess)
Vielen Dank für Deine wirklich erhellenden Ausführungen! Ich werde mich ab sofort etwas genauer mit der Files-Direktive beschäftigen. :-)
Liebe Grüße aus Ellwangen,
Felix Riesterer.
Hallo Felix,
Jetzt sehe ich _definitiv_ klarer. Vielen Dank! Dieses englische Fachchinesisch fällt mir noch sehr schwer zu verstehen...
Mir geht es meistens umgekehrt: Die deutsche Übersetzung ist oft so kraus und durcheinander, dass ich die englische Originalfassung vorziehe. Auch bei Bedienungsanleitungen von Technikprodukten ist die englische Version (auch wenn sie eventuell schon aus dem Japanischen übersetzt ist) meist leichter verständlich, zumindest weniger konfus als die deutsche.
So long,
Martin