Назад | Перейти на главную страницу

Как мы можем добиться отказа в разрешении 403 для поддомена?

У нас есть мультисайт, установленный в корневом каталоге (multisite.com), а также единичная установка WordPress на поддомене (help.multisite.com)

в корень .htaccess мы разместили:

#START Security: Disallow access to folders
Options All -Indexes
# END Security

На основном сайте (как и положено получаем)

«403 Permission Denied. У вас нет разрешения для этого запроса /wp-content/blogs.dir/83/»

Ницца. :)

НО. Мы только что заметили, что при попытке получить доступ к папкам поддоменов мы получаем:

Внутренняя ошибка сервера. Сервер обнаружил внутреннюю ошибку или неправильную конфигурацию и не смог выполнить ваш запрос .... Кроме того, ошибка 500 Internal Server Error ...

Это то, чего мы НЕ хотим.

Итак, вопрос:

Как мы можем избежать вышеуказанного результата и сделать так, чтобы сообщение для поддоменов было "403 Permission Denied" (то же, что и для основного сайта, а НЕ "внутренняя ошибка сервера 500" (как сейчас)? Что ставим, куда?

Я наконец нашел ответ на свой вопрос

После нескольких дней недоумения кто-то (за пределами этих форумов) дал ответ. На самом деле это довольно просто. Единственное действие, которое нужно предпринять, - это опустить слово: Все

#START Security: Disallow access to folders
Options -Indexes
# END Security

Лучше всего то, что если (как мы) вы поместите указанное выше в корневой каталог, он «позаботится» обо всех (если есть) каталогах во всех поддоменах, которые могут быть у вас на сервере. !!!

Для тех, кто хочет знать: Причина, по которой первая попытка (Параметры Все -Индексы) не работает, потому что файл .htaccess применяет правила к каталогу, в котором он в, поэтому вы НЕ должны снова включать этот каталог.

Самое смешное, что мы пытались убедить хозяина дать нам ответ на этот вопрос последние три дня, и все, что они придумали, было «Приносим извинения. Мы НЕ поддерживаем подобные вопросы». Они утверждали, что "это специальное правило для программного обеспечения Wordpress", хотя мы продолжали говорить им, что это не связано с самим Wordpress, а с конфигурацией сервера.

В любом случае ... Проблема решена. :)