Авторизация прямого прокси в Apache: Require и AuthMerging
Проследите глобальную авторизацию прокси и авторизацию на виртуальном хосте через правила объединения секций Apache, а не рассматривайте proxy.conf как отдельный слой политики.
Правило в proxy.conf — не особый класс правил. Apache читает включённую конфигурацию в своё дерево конфигурации; охватывающая глобальная секция, VirtualHost или соответствующая секция определяет, как участвует директива.
Начните с прослушивателя и виртуального хоста, обслуживающих запрос прямого прокси. Затем соберите соответствующие секции Proxy из этого контекста и основной конфигурации. Важен порядок обработки секций, а не только то, какой файл был изменён последним.
Авторизация не всегда суммируется
При поведении по умолчанию AuthMerging Off авторизация наследуется, пока более поздняя применимая секция не предоставит собственную логику авторизации. Эта новая логика может заменить предыдущие требования, а не добавить ещё одно ограничение.
| Настройка | Сочетание с ближайшей предыдущей секцией авторизации |
|---|---|
| Off | Новая авторизация может переопределить унаследованную логику |
| And | Оба набора должны авторизовать |
| Or | Любой из наборов может авторизовать |
Сам AuthMerging локален для секции, в которой он находится. Не думайте, что однократная установка And изменит каждую последующую секцию.
Где возможно, держите предполагаемую политику явной. Две строки Require без охватывающего контейнера авторизации неявно являются альтернативами, поэтому правило IP плюс valid-user — это не автоматически «IP и пользователь». Используйте RequireAll, когда оба условия относятся к одному решению.
Просмотрите полную соответствующую конфигурацию, прежде чем менять учётную запись прокси или открывать доступ. Затем проверьте разрешённые и запрещённые случаи на работающем прослушивателе. Запрос может быть отклонён—или неожиданно разрешён—потому что действующую авторизацию предоставила другая секция.