Home > Apache > Расследование странного глюка с HTTP Basic авторизацией

Расследование странного глюка с HTTP Basic авторизацией

February 10th, 2010

Иногда бывают такие ситуации, когда несколько глюков наложившись один на другой составляют проблему весьма и весьма загадочную на первый взгляд.
Ситуация была такая:
Проводился перенос сайтов с ВПС-а (на LAMP платформе) на дедик с таким же LAMP только еще с DirectAdmin-ом. Контент сайтов и базы данных были перенесены на новый хост. На одном из сайтов был установлен WordPress и в подпапке /st/ некий скрипт доступ к которому был ограничен в файле .htaccess лежащем в той же папке. Вот содержимое того .htaccess

Order allow,deny
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 ответы. Все пути проверены и перепроверены. Авторизационные модули апача точно присутствуют:

apachectl -M |grep auth
 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} -f [OR]
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 – не помогало. Да и на старом ВПС-е все работало. Очень странно.
Для уточнения работы правил реврайта пришлось в виртуалхост добавить директивы:

RewriteLog "/var/log/httpd/rewrite.log"
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 файлов вернуло все в работающее состояние.
Мораль: изменять дефолтные настройки всяких сложных панелей нужно очень аккуратно.

Apache

  1. timon
    April 28th, 2010 at 14:22 | #1

    хммм…похоже аналогичная пролема. спасибо!

  1. No trackbacks yet.
Бесплатные автоматы игровые автоматы играть онлайн бесплатно - typforum.ru .