Назад | Перейти на главную страницу

Почему не работает базовая аутентификация Apache?

Я только что обновил Apache с его сборки 2003 года до совершенно новой сборки 2.4.1. Все выглядит неплохо, за исключением одной вопиющей вещи:

В моем файле httpd.conf у меня есть следующее:

<Directory />
    AllowOverride none
    Options FollowSymLinks
    AuthType      Basic
    AuthName      "Enter Password"
    AuthUserFile  /var/www/.htpasswd
    Require     valid-user
</Directory>

Это должно разрешить доступ к серверу только пользователям в указанном файле аутентификации - так же, как это было в более старой версии Apache. (Правильно?)

Однако это не работает. Запросы предоставляются без аутентификации. Когда я переключаю ведение журнала на LogLevel Debug для доступа, он говорит:

[Sat Mar 24 21:32:00.585139 2012] [authz_core:debug] [pid 10733:tid 32771] mod_authz_core.c(783): [client 192.168.1.181:57677] AH01626: authorization result of Require all granted: granted
[Sat Mar 24 21:32:00.585446 2012] [authz_core:debug] [pid 10733:tid 32771] mod_authz_core.c(783): [client 192.168.1.181:57677] AH01626: authorization result of <RequireAny>: granted

Я действительно не знаю, что это означает - и у меня (насколько мне известно) нет никаких утверждений «Требовать все разрешено» или «» ни в одном из моих файлов.

Есть идеи, почему это не работает или где отлаживать ??

ОБНОВИТЬ:

У меня есть виртуальный хост на порт SSL, который позволяет проксировать. Когда я поставил тем же записи внутри 

<proxy *>

в конфигурации виртуального хоста, это работает. Кажется, это не работает в 

 <Directory>

пункт. Затем я попытался поместить в другие разделы каталога (специфичные для других каталогов), и что не сделал работать тоже.

ТАКЖЕ

Из приведенных ниже вопросов Шейна - я попытался скопировать корневой блок «/» в каталог «/ tmp». Каталог / tmp работает ПРАВИЛЬНО !! Итак - эта проблема характерна только для корневого каталога ???

У меня была аналогичная проблема с дайджест-аутентификацией при новой установке 2.4. Если внимательно присмотреться к документации на сайте Apache, похоже, что директивы аутентификации должны быть в <Location> тег, а не <Directory> тег. Документацию для директива AuthBasicProvider.

Я столкнулся с той же проблемой, и ничего из этого сообщения мне не помогло, поэтому я добавлю свои 2 цента. В моем случае (apache 2.4) проблема заключалась в последовательном Требовать директивы.

По умолчанию, если у вас более одного Требовать директивы, они считаются <RequireAny>

В моем <Directory> у меня было 

Require ip 192.168.100.0/24 10.9.8.0/24
Require valid-user

Таким образом, запрос аутентификации не появлялся, если IP был правильным. Мне пришлось переключиться Требовать логика от <RequireAny> к <RequireAll> и вроде теперь все работает правильно.

   <Directory /var/www>

      DirectoryIndex index.html
      Options -Indexes

      AuthType Basic
      AuthName "hidden data"
      AuthBasicProvider    file
      AuthUserFile /opt/httpaswd
      <RequireAll>
        Require ip 192.168.100.0/24 10.9.8.0/24
        Require valid-user
      </RequireAll>
    </Directory>

jscott ответ неверен. Apache 2.4 наверняка делает разрешить директивы аутентификации в <Directory> контейнеры. Более того, это единственный безопасный способ реализации аутентификации, так как <Location> Доступ к контейнерам можно получить разными способами, что позволяет обойти вашу аутентификацию, если вы не будете осторожны. Для справки, вот образец контейнера, который я использую в производственной системе:

<Directory "/srv/http/my_domain.org/html/secret-stuff"> Options Indexes Multiviews FollowSymLinks AuthType Digest AuthName "staff" AuthUserFile /etc/httpd/private/secret-stuff.htaccess Require valid-user </Directory>

Кажется, вам не хватает поставщика AuthBasic. Попробуйте добавить такую ​​строку:

AuthBasicProvider    file

Как только у вас будет эта работа, вы можете посмотреть на Satisfy директива. Это можно использовать для разрешения локального доступа без пароля, но при этом требуется пароль для доступа в Интернет.

РЕДАКТИРОВАТЬ: Я использую включаемый файл для BasicAuth, чтобы включить удаленный доступ на основе пароля к контенту, который обычно недоступен из Интернета. Вы можете не захотеть Satisfy директива. Это мое /etc/apache2/basicauth.conf файл:

# Basic authorization configuration include file 
# Enable basic auth access for remote users
AuthName             "Authentication Required"
AuthType             Basic
AuthBasicProvider    file
AuthUserFile         /etc/apache2/httpd.passwd
Require              valid-user
Satisfy              any

У меня также есть /etc/apache2/allow_local.conf включаемый файл для аутентификации на основе IP.

# Common local access block - Allow all local addresses
Order deny,allow
Deny  from all
Allow from 127.0.0.0/255.0.0.0 ::1/128
Allow from 192.168.1.0/24

Чтобы включить их, я использую эти включения. 

Include /etc/apache2/allow_local.conf
Include /etc/apache2/basicauth.conf

Вы можете попробовать добавить в спецификацию авторизации. Это работает с моей тестовой конфигурацией. 

Order deny,allow
Allow from all

У меня была та же проблема, и, скорее всего, это ошибка Apache; в моем случае проблема появилась после обновления и исчезла после последующего обновления, но мне пришлось добавить это внизу:

Deny from all

Страшно, что Apache может открывать такие дыры в безопасности :(

Пытаться:
<Directory "/"> ... </Directory>

Вместо того:
<Directory /> ... </Directory>

Значение: заключите корневой символ в двойные кавычки. В противном случае вы можете закрыть тег косой чертой.

Также проверьте, нет ли случайно другого

    Require all granted

в другом месте той же конфигурации Каталога. это может перекрыть ваш

    Require     valid-user

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

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

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