Как я могу избежать ошибки в этом .htaccess файле?
Я не уверен, является ли паранойя необходимой чертой..., но она, вероятно, помогает. Но я думаю, что важно, чтобы кто-то смог определить потенциальные проблемы безопасности, векторы нападения/нарушения, и т.д.
Существует уровень доверия между сотрудником и работодателем, но в то же время я - большой поклонник наименьшего количества модели обеспечения безопасности полномочия. Так доверяйте, только идет до сих пор. После того, как все несчастные случаи действительно происходят..., пользователи случайно удалят или переместят целые деревья каталогов, если у них будут полномочия сделать так.
Но равновесие должно быть установлено между безопасностью и уходить с дороги людей, делающих их задание.
Я подозреваю, что Вы смогли избегать бесконечного цикла в своем втором ruleset путем помещения директив перезаписи в основную виртуальную конфигурацию хоста, не в .htaccess файл. Это - обычно хорошая практика так или иначе, начиная с перезаписи выполнений намного быстрее, когда Вы помещаете ее в виртуальный хост, и можно извлечь дальнейшую пользу скорости, если можно сказать Apache игнорировать .htaccess файлы в целом.
Логика позади этого объяснена в mod_rewrite технической документации. Вот суть: как Вы знаете, переписываете правила, может измениться, какому имени файла данный запрос соответствует, и даже в каком каталоге получающийся файл находится. На самом деле, Ваш
RewriteRule ^$ /blog/
идеальный пример, который изменяет корень документа на blog каталог. Но Apache должен знать каталог для выяснения который .htaccess файлы для проверки на запрос. Возможно, Вы видите проблему здесь: к тому времени, когда Apache достигает Вашего .htaccess файл, это уже определило название файла, к которому это должно получать доступ, что означает, что это слишком опаздывает в Ваши правила перезаписи применяться.
Apache внутренне решает эту проблему путем создания нового подзапроса, который начинает обрабатывать с начала и введения правил от Вашего .htaccess файл в поток обработки, таким образом, они будут относиться к запросу. Как побочный эффект этого, все применимые переписывают правила, применяются снова, и это означает что [L] флаг, своего рода лежат, когда Вы используете его в a .htaccess файл. Таким образом даже при том, что Вы помещаете [L] на Вашем правиле попытаться вынудить это быть последним примененным правилом, это действительно не; все правила применяются снова, когда Apache обрабатывает свой внутренний подзапрос.
Если у Вас нет доступа к основной конфигурации сервера, Вы смогли делать это:
RewriteRule ^/blog/?$ / [R,L,NS]
NS флаг препятствует правилу быть примененным к подзапросам.
После прочтения комментариев я думаю, что самое простое решение состоит в том, чтобы переписать корневую страницу в фактический файл (index.html, Я предполагаю?).
RewriteRule ^blog/$ / [R,L]
RewriteRule ^$ /blog/index.html [L]
Таким образом, цикличного выполнения можно избежать. Одна проблема остается хотя - /blog/index.html все еще доступно внешне. Если это не опция, я думаю, что Ваш лучший выбор следует совету David и перемещает конфигурацию, которую каждый выравнивает.
Некоторые альтернативы, которые прибыли по моему мнению:
- Отпуск
/blog/index.htmlдоступный и использование связываются канонический (не лучшее, но легкий) - Если сценарии сервера (PHP, вероятно) доступны, перенаправление
/blog/index.phpкому:/на уровне сценария
NSвещь попытка. К сожалению, I' m на общем хосте так я can' t изменяют основной конфигурационный файл хоста.:( – mipadi 19 May 2010 в 18:54