Чому пароль каталогу Apache не захищає прямий проксі
Захищена сторінка привітання й авторизований запит прямого проксі використовують різні контексти конфігурації. Розмістіть політику проксі в конфігурації сервера або віртуального хоста.
Запит пароля на головній сторінці Apache захищає лише цей локальний ресурс. Він не доводить, що довільні запити прямого проксі потребують того самого входу.
.htaccess стосується підтримуваної конфігурації каталогу; це не остаточний фільтр для кожного запиту. Розділи ProxyRequests і <Proxy> належать конфігурації сервера або віртуального хоста. Розмістіть авторизацію прямого проксі там, використовуючи синтаксис авторизації Apache 2.4 і потрібне налаштування автентифікації.
Для приватного сервісу свідомо поєднайте передбачувані вимоги до джерела клієнта й облікового запису. Потім перевірте віртуальний хост, який вибирає кожен слухач, включно з типовими хостами й успадкованою конфігурацією. Доступ до одного захищеного імені хоста не доводить, що інший активний хост має ті самі обмеження проксі.
ProxyPass виконує іншу роль — зазвичай зіставляє локальний простір імен із бекендом. Його додавання не дозволяє довільні цілі пересилання.
Якщо ви можете редагувати лише файли документів одного сайту, вам може бракувати адміністративного обсягу, щоб установити межу доступу цього сервісу. Отримайте зміну конфігурації сервера або використовуйте схвалений наявний проксі; пароль каталогу не може його замінити.