Apache2 - авторизация пользователей в соответствии с местоположением с использованием 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 (который я хочу). Пароль для внешних пользователей должен запрашиваться ОТЛИЧНЫМ, и он должен быть BasicAuth, получая список пользователей из файла htpasswd.


apache basic-authentication apache2 apache-config
person Bo Jeanes    schedule 24.02.2009    source источник
comment
Хорошо, теперь я вижу, что вы хотели. :) Ответ Дэвида на 100% правильный, он меня опередил (были проблемы с Wi-Fi при редактировании ответа).   -  person vladr    schedule 24.02.2009

Ответы (3)


arrow_upward
6
arrow_downward 

<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>
person David Z    schedule 24.02.2009
comment
хм... просто случайная мысль, изменится ли что-нибудь, если вы поместите директиву Allow перед директивой Require? - person David Z; 24.02.2009
comment
Блин, я удалил свой комментарий, прежде чем увидел твой. Я заработал, просматривая логи. Похоже, он не учитывал наши запросы из локальной подсети, а с нашего общедоступного статического IP-адреса. Я также внес это в белый список, и теперь он, кажется, работает отлично! Большое спасибо - person Bo Jeanes; 24.02.2009
comment
И я также переместил «Разрешить» перед «Требовать» на том же шаге, так что, возможно, это тоже было так. - person Bo Jeanes; 24.02.2009

arrow_upward
0
arrow_downward

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

person Dana the Sane    schedule 24.02.2009
comment
Существует только один IP-адрес привязки и один интерфейс. Мне нужно основывать его на Remote_Addr - person Bo Jeanes; 24.02.2009

arrow_upward
0
arrow_downward

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

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

person Steve Moyer    schedule 24.02.2009
comment
Внутри sub.domain.com разрешается во внутренний IP-адрес. Смысл прокси-сервера в том, чтобы не выдавать основной пароль, поскольку конечная точка поддерживает только один пароль, который я не хочу распространять. Кроме того, URL смехотворно глупо запоминать. Нагрузка небольшая (всего 6-7 пользователей) - person Bo Jeanes; 24.02.2009
comment
Похоже, тогда вы будете золотыми с конфигурацией Дэвида! - person Steve Moyer; 24.02.2009