Пример использования AuthType Digest для аутентификации пользователя один раз в поддоменах? - PullRequest
4 голосов
/ 11 декабря 2008

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

В домене есть набор установленных приложений, каждый из которых имеет свой собственный поддомен. Например: domain.com, app1.domain.com, app2.domain.com, app3.domain.com

Мне бы хотелось иметь решение с единым входом, чтобы им не приходилось аутентифицировать себя для каждого приложения. Кроме того, приложения написаны на разных языках (PHP, Python и Perl), поэтому аутентификация пользователей через модуль Apache идеальна.

Я новичок в дайджест-аутентификации, но это похоже на хорошее решение. Я использовал htdigest для создания своих пользователей. Я настроил свой домен и субдомены (см. Ниже).

Если я перейду к домену или любому из поддоменов, он запросит имя пользователя и пароль. Если я введу правильное имя пользователя и пароль, он будет аутентифицирован и страница загрузится. Однако, если я перейду на другой поддомен, он попросит меня снова ввести имя пользователя и пароль. Если я введу одно и то же имя пользователя и пароль, он будет работать.

Итак, файл паролей в порядке, аутентификация в порядке, но проблема, похоже, заключается в конфигурации AuthDigestDomain.

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

Я надеюсь, что кто-то здесь может помочь. Я помещаю одну и ту же информацию аутентификации в каждый Directory? Должен ли я использовать Directory или Location или Files? Я что-то пропустил все вместе?

Заранее спасибо!

Ниже приведен пример моей конфигурации Apache для domain.com:

<Directory /var/www>
  AuthType Digest
  AuthName "realm"
  AuthDigestAlgorithm MD5
  AuthDigestDomain / http://domain.com/ http://app1.domain.com/ http://app2.domain.com/ http://app3.domain.com/
  AuthDigestNcCheck Off
  AuthDigestNonceLifetime 0
  AuthDigestQop auth
  AuthDigestProvider file
  AuthUserFile /etc/apache2/.htpasswd-digest
  AuthGroupFile /dev/null
  Require valid-user
</Directory>

А вот пример app1.domain.com:

<Directory /var/lib/app1>
  AuthType Digest
  AuthName "realm"
  AuthDigestAlgorithm MD5
  AuthDigestDomain / http://domain.com/ http://app1.domain.com/ http://app2.domain.com/ http://app3.domain.com/
  AuthDigestNcCheck Off
  AuthDigestNonceLifetime 0
  AuthDigestQop auth
  AuthDigestProvider file
  AuthUserFile /etc/apache2/.htpasswd-digest
  AuthGroupFile /dev/null
  Require valid-user
</Directory>

Чтобы еще больше сбить с толку, это работает при использовании IE6, но не Firefox или Chrome. Это клиенты не отправляют аутентификацию должным образом, или сервер не отправляет правильные учетные данные?

Я также читал RFC 2617 и написал заголовки аутентификации, используя PHP, чтобы убедиться, что запрос / ответ корректен. Это совсем не помогло!

Ответы [ 3 ]

3 голосов
/ 30 декабря 2009

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

Для Opera сервер (ы) должен отвечать одинаковой строкой «realm» для каждого URI в списке доменов. Другими словами, если domain = "/ test / example", сервер должен отправить "Test Realm - example.com" в заголовке WWW-Authenticate для обоих этих URI. Я предполагаю, что Opera делает это, потому что она хранит H (A1) вместо фактического пароля для безопасности. Подробнее об этом читайте в RFC2617.

Вот мое кросс-браузерное решение этой проблемы: http://travisce.com/arest/

0 голосов
/ 22 июня 2009

Может ли подстановочный знак в AuthDigestDomain помочь?

    *.domain.com
0 голосов
/ 13 декабря 2008

У меня нет опыта с чем-то подобным. Но я только что взглянул на документацию Apache и нашел это:

Директива AuthDigestNonceLifetime контролирует, как долго сервер одноразовый действительный. [...] Если секунд меньше 0 тогда одноразовый номер никогда не истекает.

Так что мне кажется, что 0 секунд (значение, которое вы используете) либо недопустимы, либо действительно указывают Apache, что срок действия одноразового номера истекает через 0 секунд, что точно объясняет поведение, которое вы получаете.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...