n  Deny – принадлежит к группе Limit. Она запретит доступ к документу, если установлена переменная ssi_part. Напомню, что для правильной работы этих настроек вам может понадобиться директива Order Allow,Deny, описание которой выходит за рамки этой статьи. Если у вас нет опыта использования директив Order, Allow и Deny, обратитесь к документации на Apache.

Переменную ssi_part можно использовать в обработчике ошибки 403. Именно эта ошибка будет возникать при срабатывании директивы Deny.

Как видите, мы вернули документам прежний, предельно простой вид и решили поставленную задачу по ограничению доступа.

Можно поступить ещё проще. Создать отдельную директорию для SSI-«кирпичиков» и разместить в ней файл .htaccess следующего содержания:

SetEnv ssi_part

Deny from env=ssi_part

Теперь все файлы, находящиеся в этой директории, будут недоступны, так сказать, безусловно – независимо от расширения файла и прочего.

Такой подход оправдан, если вы оперируете с большим количеством SSI-компонентов. Тогда действительно удобно обособить их в отдельной директории. Если же таких компонентов один-два, то, возможно, и не стоит «городить огород». Выбор за вами.

Промежуточные решения

На базе двух предложенных решений можно составить множество промежуточных подходов. Скажем, если по правилам хостинга изменять настройки группы Limit запрещено (то есть директива Deny недоступна), но вы имеете право использовать директиву SetEnvIf (она, напомню, принадлежит к группе FileInfo), то устанавливать флаг можно средствами сервера, а проверять его значение – средствами SSI. Это позволит упростить код включающего документа.

Средствами SSI можно проверять и адрес документа, но здесь надо быть осторожным. Дело в том, что переменная REQUEST_URI содержит и строку запроса. То есть если вы проверяете, заканчивается ли REQUEST_URI подстрокой .inc, то злоумышленник может обмануть вашу проверку, запросив ресурс head.inc?index.sthml. Кроме того, возможны недоразумения при передаче строки запроса. Например, такие: index.sthml?var=head.inc. Пользователь запросил обычный STHML-документ, но REQUEST_URI всё-таки заканчивается на .inc, и в доступе будет отказано.

Этого недостатка лишена переменная DOCUMENT_URI; используйте её.

Однако даже использование DOCUMENT_URI не избавляет от проблем с trailing-путями, которые являются головной болью обоих подходов (и, естественно, любых комбинаций этих подходов). Давайте рассмотрим этот наиболее сложный момент на примере второго подхода – ограничение доступа средствами сервера.

Trailing-пути, <Files> и <FilesMatch>

Обработка Request_URI не справляется с trailing-путями. Например, к файлу head.inc можно обратиться, как head.inc/index.shtml. Именно эта строка окажется в переменной Request_URI и в переменной DOCUMENT_URI. При этом наша проверка не сработает, а документ head.inc будет выдан клиенту.

Своеобразное решение этой проблемы предлагает Apache версии 2.0. Дело в том, что по умолчанию Apache 2.0 теперь не обслуживает trailing-пути и переменную PATH_INFO для SSI-документов. 1.3-образное поведение можно вернуть с помощью специальной директивы AcceptPathInfo. Для надёжного решения в Apapche 1.3 так и хочется использовать секцию <Files> или <FilesMatch>:

<FilesMatch ".(inc|ssi)$">

 Deny from all