Я держу на сервере некоторые служебные/вспомогательные файлы, используемые в Server-Side Includes (SSI), и хочу запретить Apache отдавать их наружу по запросам.

В общем случае запрет отдачи файлов рекомендуется делать через Files/FilesMatch и Allow/Deny, но Allow/Deny работают для любых файлов, запрашиваемых при обработке запроса. Если я запрещаю эти файлы через Deny, они перестают быть доступны и самому серверу при обработке SSI.

Другой часто рекомендуемый способ — через RewriteRule, но тогда соответствующие правила придется включать в .htaccess каждого каталога, а это чертовски неудобно.

Что еще можно придумать без извращений, чтоб файлы были доступны самому апачу для SSI, но недоступны для получения по прямому запросу?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> Что еще можно придумать без извращений, чтоб файлы были доступны самому апачу для SSI, но недоступны для получения по прямому запросу?

Поставить nginx перед apache и запретить на нем.

Здравствуйте, Anton Batenev, Вы писали:

AB>Поставить nginx перед apache и запретить на нем.

Я ж не зря указал, что это нужно сделать именно в Apache и через .htaccess. Подсказка: сервер контролирую не я.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> Другой часто рекомендуемый способ — через RewriteRule, но тогда соответствующие правила придется включать в .htaccess каждого каталога, а это чертовски неудобно.

Укажи RewriteBase на нужный каталог и правила будут действовать на все дочерние тоже.

Здравствуйте, rudzuk, Вы писали:

R>Укажи RewriteBase на нужный каталог

Который из них "нужный", если я хочу, чтоб это действовало на все каталоги?

R>правила будут действовать на все дочерние тоже.

Каким образом? По умолчанию правила не наследуются, и действуют только те, что указаны в .htaccess конкретного каталога.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> R>Укажи RewriteBase на нужный каталог

ЕМ> Который из них "нужный", если я хочу, чтоб это действовало на все каталоги?

Значит укажи корень: RewriteBase /

ЕМ> R>правила будут действовать на все дочерние тоже.

ЕМ> Каким образом? По умолчанию правила не наследуются, и действуют только те, что указаны в .htaccess конкретного каталога.

Наследуются. Далее (в дочерних каталогах) можно перекрыть правила вложенным .htaccess

Здравствуйте, rudzuk, Вы писали:

R>Значит укажи корень: RewriteBase /

Я, честно говоря, вообще не понимаю, при чем тут RewriteBase. Судя по описанию, оно задает базу для второго параметра RewriteRule, а на кой в решаемой задаче нужен изменяемый второй параметр?

R>Наследуются. Далее (в дочерних каталогах) можно перекрыть правила вложенным .htaccess

Для всего, кроме RewriteCond/RewriteRule. А если наследовать и их, то придется попрощаться с per-directory rules, я тогда вообще вздернусь.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> Я, честно говоря, вообще не понимаю, при чем тут RewriteBase. Судя по описанию, оно задает базу для второго параметра RewriteRule, а на кой в решаемой задаче нужен изменяемый второй параметр?

Это я чего-то протупил. За давностью лет уже забыл нафиг включил ее в файл.

ЕМ> Для всего, кроме RewriteCond/RewriteRule.

Все наследуется. У меня так сделана блокировка файлов по имени начинающегося с точки и некоторые модификации урлов (прописывать такое в каждом каталоге... дурнее не придумаешь).

ЕМ> А если наследовать и их, то придется попрощаться с per-directory rules, я тогда вообще вздернусь.

.htaccess и сделан для per-directory

Здравствуйте, rudzuk, Вы писали:

R>У меня так сделана блокировка файлов по имени начинающегося с точки и некоторые модификации урлов (прописывать такое в каждом каталоге... дурнее не придумаешь).

Хм, как именно у Вас это сделано? Судя по описанию mod_rewrite, до него доходит дело только после того, как URL отображен на файловую систему — то есть, найден путь в ФС, соответствующий наиболее длинному пути в URL. Я отлаживаю локальную копию сайта в локальном сервере Apache 2.4.38, и по логам вижу, что он не просматривает все .htaccess, начиная от корня, как это делает core, а сразу берет .htaccess из последнего существующего каталога.

Если включить наследование, то он тупо добавляет все родительские правила до/после правил из этого файла, в том же виде, в каком они указаны в родительских каталогах. А там они, как правило, указываются для конкретного контекста в URL. Делать в каждом каталоге правила, работающие в любом другом — еще дурнее.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> R>У меня так сделана блокировка файлов по имени начинающегося с точки и некоторые модификации урлов (прописывать такое в каждом каталоге... дурнее не придумаешь).

ЕМ> Хм, как именно у Вас это сделано?

Конкретно запрет на имена начинающиеся с точкаи выглядит так:

RewriteEngine On
RewriteBase /

# block any object with leading dot
RewriteCond %{REQUEST_URI} (.*)/\.(.*)
RewriteRule (.*) $1 [R=404,L]

Этот .htaccess лежит в корне сайта и его правила действуют на все подкаталоги. В паре дочерних каталогов есть собственные .htaccess со своими правилами не относящимися к mod_rewrite.

Здравствуйте, rudzuk, Вы писали:

R>Этот .htaccess лежит в корне сайта и его правила действуют на все подкаталоги.

Он не должен действовать на подкаталоги, если не разрешено наследование правил (RewriteOptions Inherit*). У Вас оно включено? Если нет, то какая версия Apache, и Apache ли это?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> R>Этот .htaccess лежит в корне сайта и его правила действуют на все подкаталоги.

ЕМ> Он не должен действовать на подкаталоги, если не разрешено наследование правил (RewriteOptions Inherit*). У Вас оно включено? Если нет, то какая версия Apache, и Apache ли это?

$apache2 -v
Server version: Apache/2.4.52 (Ubuntu)
Server built:   2023-05-03T20:02:51

RewriteOptions вообще нигде не указано. Ни в конфиге модуля mod_rewrite, ни в конфиге сайта, ни в .htaccess.

Здравствуйте, rudzuk, Вы писали:

R>RewriteOptions вообще нигде не указано.

Вы твердо уверены, что Ваши правила действительно работают? Попробуйте, например, сменить 404 на 403 — в результатах запроса ошибка изменится для любых файлов, начинающихся с точки, в любых дочерних каталогах?

Если да, то как это согласуется с описанием технологии работы mod_rewrite? Он не должен так работать.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> Вы твердо уверены, что Ваши правила действительно работают? Попробуйте, например, сменить 404 на 403 — в результатах запроса ошибка изменится для любых файлов, начинающихся с точки, в любых дочерних каталогах?

Проверил. Работает. Сменил на 403 — отдается страница с 403. Закоментировал это правило — стали отдаваться файлы с лидирующей точкой в имени. Проверял в каталогах разной глубины. Конфиг (.htaccess) лежит в корне.

ЕМ> Если да, то как это согласуется с описанием технологии работы mod_rewrite? Он не должен так работать.

Можно цитату, где говорится, что не должен?

Здравствуйте, rudzuk, Вы писали:

R>Проверил. Работает. Сменил на 403 — отдается страница с 403. Закоментировал это правило — стали отдаваться файлы с лидирующей точкой в имени. Проверял в каталогах разной глубины. Конфиг (.htaccess) лежит в корне.

Крайне странно. Я такого не мог добиться никогда, и сейчас тоже — вставил Ваш код, как есть, в корневой .htaccess, и он действует только на корень.

R>Можно цитату, где говорится, что не должен?

Раздел "API Phases":

First, it uses the URL-to-filename translation hook, which occurs after the HTTP request has been read, but before any authorization starts. Secondly, it uses the Fixup hook, which is after the authorization phases, and after per-directory configuration files (.htaccess files) have been read, but before the content handler is called.
...
In per-directory context (i.e., within .htaccess files and Directory blocks), these rules are being applied after a URL has already been translated to a filename.

Поскольку mod_rewrite — это модуль расширения, он может вызываться только через определенные API Hooks, а не в любой момент, когда пожелает. Судя по описанию, такой API Hook первый раз вызывается после того, как будет найдено отображение URL на путь ФС. О том, чтобы mod_rewrite вызывался каждый раз, когда в ФС найден очередной каталог, соответствующий пути URL, я никогда не слышал.

Соответственно, глядя в логи, я вижу там то же самое: обработка запроса в mod_rewrite начинается с применения правил из .htaccess в последнем подходящем каталоге, и им же и завершается. Применить правила из родительских каталогов он может только в порядке наследования, если оно разрешено.

У Вас точно не разрешено наследование правил? Какой порядок обработки запроса отражается в логах?

Здравствуйте, rudzuk, Вы писали:

R>Конкретно запрет на имена начинающиеся с точкаи выглядит так:

Поставил 2.4.58 рядом с 2.4.38, еще раз вставил в корневой .htaccess Ваш код — работает точно так же.

Еще одно уточнение: когда Вы проверяли его работу, то вводили имена существующих файлов, начинавшихся с точки? Или, хотя бы, несуществующих файлов, но в существующих каталогах? Иначе, если первый же за корневым каталог в URL не существует, то закономерно будет применен корневой .htaccess.

И, надеюсь, проверяли не на именах вида .ht*?

Вообще, такие правила нужно проверять очень аккуратно. Я уже не раз налетал на то, что, не посмотрев в логи, можно спутать 404, возвращаемый сервером для несуществующего файла, с 404, который должно возвращать правило реализации запрета, а 403, который должно возвращать правило для .htaccess — с 403, который Apache возвращает для них по умолчанию (с какой-то версии в httpd.conf появилось Require all denied для ".ht*").

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> R>Проверил. Работает. Сменил на 403 — отдается страница с 403. Закоментировал это правило — стали отдаваться файлы с лидирующей точкой в имени. Проверял в каталогах разной глубины. Конфиг (.htaccess) лежит в корне.

ЕМ> Крайне странно. Я такого не мог добиться никогда, и сейчас тоже — вставил Ваш код, как есть, в корневой .htaccess, и он действует только на корень.

В общем, почитал я доку про наследование в mod_rewrite. Там речь идет о наследовании для дочерних .htaccess со своими правилами перезаписи. Проверил у себя и это действительно так. Если в дочернем каталоге есть свой .htaccess с собственными правилами перезаписи, то родительские правила не применяются.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> Еще одно уточнение: когда Вы проверяли его работу, то вводили имена существующих файлов, начинавшихся с точки? Или, хотя бы, несуществующих файлов, но в существующих каталогах? Иначе, если первый же за корневым каталог в URL не существует, то закономерно будет применен корневой .htaccess.

ЕМ> И, надеюсь, проверяли не на именах вида .ht*?

ЕМ> Вообще, такие правила нужно проверять очень аккуратно. Я уже не раз налетал на то, что, не посмотрев в логи, можно спутать 404, возвращаемый сервером для несуществующего файла, с 404, который должно возвращать правило реализации запрета, а 403, который должно возвращать правило для .htaccess — с 403, который Apache возвращает для них по умолчанию (с какой-то версии в httpd.conf появилось Require all denied для ".ht*").

Да, проверял на существующих файлах. Да, проверял аккуратно. Да, не на .htaccess.

Здравствуйте, rudzuk, Вы писали:

R>Если в дочернем каталоге есть свой .htaccess с собственными правилами перезаписи, то родительские правила не применяются.

Я даже предположить не мог, что у Вас правила перезаписи есть только в корневом .htaccess. У меня они где-то есть, где-то нет, поэтому, за невозможностью управлять этим глобально, остается только вставлять одинаковые правила в каждый .htaccess, что по определению идиотизм.

Каждый раз, когда правлю конфигурацию сервера, задаюсь вопросом: что курили разработчики Apache, чтоб наплодить, с одной стороны, так монументально, а с другой — так бестолково. Ведь самые элементарные приемы (возможность определять переменные в .htaccess, возможность включать в .htaccess другие файлы, возможность для mod_rewrite просматривать .htaccess по мере продвижения по пути, и т.п.) позволили бы радикально упростить управление.

Возможно, эти ребята просто давно забыли, что уних — по определению многопользовательская система, и у администратора конкретного сервера может не быть доступа к корневым конфигам.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> R>Если в дочернем каталоге есть свой .htaccess с собственными правилами перезаписи, то родительские правила не применяются.

ЕМ> Я даже предположить не мог, что у Вас правила перезаписи есть только в корневом .htaccess.

Я об этом почти сразу написал

Автор: rudzuk
Дата: 05.11.23

:

В паре дочерних каталогов есть собственные .htaccess со своими правилами не относящимися к mod_rewrite.

ЕМ> Каждый раз, когда правлю конфигурацию сервера, задаюсь вопросом: что курили разработчики Apache, чтоб наплодить, с одной стороны, так монументально, а с другой — так бестолково. Ведь самые элементарные приемы (возможность определять переменные в .htaccess, возможность включать в .htaccess другие файлы, возможность для mod_rewrite просматривать .htaccess по мере продвижения по пути, и т.п.) позволили бы радикально упростить управление.

ЕМ> Возможно, эти ребята просто давно забыли, что уних — по определению многопользовательская система, и у администратора конкретного сервера может не быть доступа к корневым конфигам.

Я тоже прифигел от конфигурирования апача