Ich möchte alle WordPress-Admin-Schnittstellen (wp-login.php/wp-admin) auf meinem Server schützen. Dazu möchte ich eine globale Konfiguration in Apache erstellen, die nach einem festen Benutzer/Passwort (HTTP-Basisauthentifizierung) fragt, bevor ich die eigentliche WordPress-Anmeldeseite erreiche. Dadurch wird eine Überlastung von PHP durch Passwort-Scan-Bots vermieden.
<FilesMatch "wp-login.php">
AuthUserFile /etc/wordpress.passwd
AuthName "TYPE USER wp AND PASSWORD wp"
AuthType Basic
require valid-user
</FilesMatch>
Funktioniert, jede Datei mit dem Namen wp-login.php fragt nach dem Passwort.
Aber wenn ich es auf einer Wordpress-Site ausführe, ist es.htaccesshat eine Art „Priorität“ gegenüber der globalen Konfiguration. Wenn ich auf wp-login.php zugreife, erhalte ich nur einen 404-Fehler. Wenn ich .htaccess entferne/umbenenne, funktioniert FilesMatch, aber ich verliere die notwendige „Pfadmasken“-Funktion.
Wordpress .htaccess ist:
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
Ich suche nach einer Möglichkeit, der FilesMatch-Direktive Vorrang vor .htaccess (Rewrite-Modul) zu geben: nach dem Passwort fragen, nicht die URL umschreiben (was 404 ergibt).
Irgendwelche Ideen?
Antwort1
Gelöst
Wordpress .htaccess schreibt alles neu, einschließlich der ErrorDocument-Direktiven, die von der HTTP-Basisauthentifizierung verwendet werden, sowie der Rückgabecodes 401 und 403. Ich hatte personalisierte SHTML-Dateien für ErrorDocument (Standard in cPanel-Servern). Anstatt also nach einem Passwort zu fragen, schreibt es die HTTP-Header neu und fragt nach dem PasswortUndgleichzeitig wird eine 404-Fehlerseite angezeigt, wodurch der Webbrowser verrücktspielt.
Um das Problem zu beheben, habe ich einfach die standardmäßigen ErrorDocument-Meldungen erzwungen:
ErrorDocument 401 default
ErrorDocument 403 default