Что делает директива Apache Satisfy?

TLDR;
В большинстве случаев эта строка не является строго необходимой, так как Satisfy All обычно это настройка сервера по умолчанию. В этом случае линия не является строго необходимой.

Строка добавлена ​​в качестве дополнительной защиты, "просто в случае", сервер был настроен на использование Satisfy Any установка по умолчанию.
Если сервер был преднамеренно настроен с использованием параметра "Удовлетворять любого", вы можете переопределить этот параметр, добавив Satisfy All директива для защиты файлов, таких как .htaccess,

Я не уверен, что файл htaccess может переопределить стандартную директиву "Satisfy" сервера для всех папок в или ниже указанного файла htaccess или нет.

Для общего кода, размещенного в Интернете, особенно когда он говорит вам, как правильно обезопасить .htaccess Авторы несут ответственность, не делая никаких предположений о настройках вашего сервера, которые могут подорвать безопасность документа. Включение этой "дополнительной" строки обеспечивает более безопасную настройку ваших файлов htacess. Добавление директивы заставляет блок кода работать 100% времени, вместо того, чтобы случайно раскрыть файлы htaccess для небольшого набора серверов, которые настроены по-разному.

Согласно документации Apache:

Satisfy Any|All:

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

...используется в <Directory>, <Files>, а также <Location> разделы, а также .htaccess

Эта директива полезна, только если доступ к определенной области ограничен как именем пользователя / паролем, так и адресом хоста клиента. В этом случае по умолчанию (Все) требуется, чтобы клиент проходил ограничение доступа к адресу и вводил правильное имя пользователя и пароль. С опцией Любой клиенту будет предоставлен доступ, если он либо пройдет ограничение хоста, либо введет правильное имя пользователя и пароль.

Поскольку значение по умолчанию Satisfy All (единственный другой вариант Satisfy Any), вы можете не заметить разницы при включении этой опции. Однако файл конфигурации вашего сервера (или "возможно, файл.htaccess в родительском каталоге" - я не уверен, возможно ли это или нет) может переопределить это значение по умолчанию.

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

В ссылке на документ упоминаются некоторые случаи использования, когда вы можете вместо этого использовать Satisfy Any,

Я бы с вами согласился, удовлетворить все, ничего не делая - без него эти файлы все равно были бы опровергнуты.

Поскольку я не могу комментировать, я добавлю здесь, что ответ @SherylHohman - лучший ответ, потому что он важен для дополнительной безопасности. Таким образом, технически неверно утверждать, что без него это никак не повлияет (в отличие от принятого ответа), поскольку вам все равно придется учитывать остальную часть конфигурации сервера. Однако я хотел бы добавить к ответу @SherylHohman:

1. Файл конфигурации сервера (например, /etc/httpd/conf/httpd.conf) мог бы иметь более обобщенный Satisfy Any заявление. Например, это важно, поскольку кто-то может потребовать имя пользователя / пароль для доступа ко всем сайтам на своем сервере (например, через Require group [name), а затем разрешить обход с определенного IP-адреса или набора IP-адресов через Allow from [ip] так что если бы это было опущено, .htaccess будет открыт, потому что Satisfy Any должен был быть объявлен.

2. Каталоги в или выше определенного .htaccess файл не будет иметь влияния, если они не <Files> раздел, который также специально соответствует .htaccess это тогда переопределило бы это правило, наряду с конфигурацией сервера, также содержащей необходимый AllowOverride директивы (например, Limit или же All). Я говорю, что это должно быть <File> потому что это то, что используется в конфигурации сервера, и те, которые обрабатываются после <Directory> уровень (т.е. уровень корня .htaccess). Это потому что <File> разделы объединяются позже, и мне кажется, что .htaccess конечно обрабатывается после конфига сервера.

Что касается меня, когда я пытался ограничить доступ к самому файлу .htaccess, где мое приложение работает на AWS Elastic Beanstalk, я использовал приведенный ниже фрагмент кода в файле конфигурации:

<Files ~ "^.*.([Hh][Tt][Aa])"> Приказать разрешить, запретить Запретить от всех

Это ограничило полный доступ. Но мой веб-сайт начал давать сбой, и я не смог получить доступ к индексу или странице входа. После использования «Удовлетворить всех» все работало отлично.

<Files ~ "^.*.([Hh][Tt][Aa][Cc][Cc][Ee][Ss][Ss])"> Приказать разрешить, запретить Запретить все Удовлетворить все

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