Расследование странного глюка с HTTP Basic авторизацией
Иногда бывают такие ситуации, когда несколько глюков наложившись один на другой составляют проблему весьма и весьма загадочную на первый взгляд.
Ситуация была такая:
Проводился перенос сайтов с ВПС-а (на LAMP платформе) на дедик с таким же LAMP только еще с DirectAdmin-ом. Контент сайтов и базы данных были перенесены на новый хост. На одном из сайтов был установлен Wordpress и в подпапке /st/ некий скрипт доступ к которому был ограничен в файле .htaccess лежащем в той же папке. Вот содержимое того .htaccess
Allow from all
AuthType Basic
AuthName "admin"
AuthUserFile /home/username/domains/domain.com/public_html/st/.htpasswd
Require valid-user
Вроде все очень просто и правильно. Но, при попытке доступа к domain.com/st/ мы стабильно получаем ошибку “404 – File Not Found” и отсутствие какого либо запроса на авторизацию. В логах этого виртуалхоста никаких ошибок, только 404 ответы. Все пути проверены и перепроверены. Авторизационные модули апача точно присутствуют:
authn_file_module (static)
Syntax OK
authn_default_module (static)
authz_host_module (static)
authz_groupfile_module (static)
authz_user_module (static)
authz_default_module (static)
auth_basic_module (static)
В конфигах апача точно разрешено переопределение директив для этой папки AllowOverride All.
Расследование вывело на .htaccess лежащий в корне этого сайта и строки от вордпресса:
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule . - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-.*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]
Комментируя последнюю строчку мы получали работающую авторизацию. Но при чем тут она?! =)
Пытался отключать наследование работы mod_rewrite прописывая в “нижний” .htaccess директив RewriteEngine Off – не помогало. Да и на старом ВПС-е все работало. Очень странно.
Для уточнения работы правил реврайта пришлось в виртуалхост добавить директивы:
RewriteLogLevel 3
Оказалось, что при открытии проблемного УРЛ mod_rewrite пытался преобразовать адрес uri ‘401.shtml’. Что и указало на суть проблемы. А проблема на самом деле была в том, что при переносе сайта из ДиректАдминовского каталога /public_html были удалены дефолтные файлы – обработчики ошибок:
400.shtml, 401.shtml, 403.shtml … которые были назначены в конфиге апача обработчиками соответствующих ошибок. И происходило следующее: при запросе проблемного урла апач отвечал 401 – как и должен был, и пытался отдать страницу 401.shtml, но так как она была удалена .htaccess из корня сайта преобразовывал запрос на вордпрессовый index.php отдавая 404 из-за отсутствующего 401.shtml.
Возвращение на место *.shtml файлов вернуло все в работающее состояние.
Мораль: изменять дефолтные настройки всяких сложных панелей нужно очень аккуратно.
