Apache2 - авторизуйте пользователей для Location с помощью BasicAuth, но ТОЛЬКО для пользователей вне локальной подсети

В моей конфигурации Apache 2 у меня есть VirtualHost примерно такой вид:

<VirtualHost *:80>
  ServerName sub.domain.com

  # username:password sent on to endpoint
  RequestHeader set Authorization "Basic dXNlcm5hbWU6cGFzc3dvcmQ=="

  ProxyPass        /xyz http://192.168.1.253:8080/endpoint
  ProxyPassReverse /xyz http://192.168.1.253:8080/endpoint

  <Location /xyz>
    # This needs to let users through under the following circumstances
    #   * They are in 192.168.1.0/24
    #   * They have a valid user in a htpasswd file

    # So what goes here?
  </Location>
</VirtualHost>

Я использую виртуальный хост в качестве обратного прокси-сервера для другого сервера (который я буду называть конечной точкой) в сети.

Я пытаюсь выяснить конфигурацию, которая позволила бы пользователям внутри сети sub.domain.com автоматически обслуживать конечную точку. Однако пользователям за пределами сети следует запрашивать учетные данные.

Конечная точка требует пароль, который я скрыл с помощью RequestHeader (который мне нужен). Пароль для внешних пользователей должен быть запрошен с помощью DIFFERENT и должен быть BasicAuth, получая список пользователей из htpasswd файла.

Ответов (3)

Решение
<Location /xyz>
  # This needs to let users through under the following circumstances
  #   * They are in 192.168.1.0/24
  #   * They have a valid user in a htpasswd file

Прямо из http://httpd.apache.org/docs/2.2/mod/core.html#satisfy :

  Require valid-user
  Order allow,deny
  Allow from 192.168.1
  Satisfy any

Конечно, вам также необходимо включить свой AuthUserFile или любые другие директивы

  AuthType basic
  AuthName "yadayadayada"
  AuthUserFile /foo/bar/blah/.htpasswd
</Location>

Вы можете создать два хоста, один из которых прослушивает внешний интерфейс, а другой - локальный. Настройки авторизации будут прежними.

Я думаю, что Дэвид довольно хорошо рассмотрел конфигурацию Apache2, но также часто используется разделенный DNS для предоставления различных услуг вашим внутренним и внешним пользователям. У ваших внутренних пользователей действительно нет причин делать запрос с вашего прокси, поскольку они (якобы) имеют прямой доступ к «конечной точке».

Бывают случаи, когда вы действительно можете столкнуться с задержками маршрутизации и перегрузкой, если ваши внутренние пользователи подключаются к одному из ваших общедоступных IP-адресов. Изначально мне нравилось иметь отдельное оборудование для двух DNS-серверов, но недавно я переключился на использование «представлений» привязки, чтобы предоставить разные зоны двум моим классам пользователей.