После авторизации в /b-docs при первом обращении к /cgi-bin/b-bin браузер, который пока не «знает», что обращается к закрытой зоне, отправит обычный запрос. Дальше всё будет происходить по уже известному сценарию. Сервер выдаст ответ об ошибке 401 с сообщением о том, что данная директория принадлежит к зоне Realm-B. Тогда браузер автоматически сформирует новый запрос с заголовком Authorization. Для пользователя весь этот диалог останется не заметен, вводить имя и пароль повторно не потребуется – браузер уже располагает всей идентификационной информацией для работы в зоне Realm-B.

Самая экзотическая ситуация создана в директории a-docs. В ней находится файл .htaccess, приписывающий её к закрытой зоне Realm-A. Если бы этим дело ограничивалось, то и её поддиректории – sub-a и sub-b – принадлежали бы к этой зоне. Так и происходит с директорией /adocs/sub-a: она не содержит собственного .htaccess и просто наследует все свойства директории a-docs. Однако в директории /a-docs/sub-b имеется собственный .htaccess, согласно которому она принадлежит к зоне Realm-B. По каким правилам взаимодействуют зоны в подобном случае, когда они перекрываются? Безусловно, доминировать будет зона Realm-B. То есть, чтобы получить доступ к директории/adocs/sub-b, не надо быть авторизованным в зоне RealmA, требуется только право доступа к зоне Realm-B.

В заключение заметим, что и basic-авторизация тоже допускает использование зон, но в этом случае клиент не сообщает серверу имя зоны и привязка пользователя к зоне не производится. Фактически информацию о зоне может использовать только клиент.

Группы пользователей

Как и basic-авторизация, аппарат digest-авторизации позволяет организовывать пользователей в группы. Для этого существует директива:

htdigest -c passwd Realm-A a

Она задаёт путь к файлу, описывающему группы. Его структура очень проста, и никаких специальных инструментов для его создания не существует. Это просто текстовый файл, каждая строка которого описывает одну группу и имеет следующую структуру:

имя_группы: пользователь ещё_пользователь ...

После того как файл с группами создан и путь к нему указан, можно использовать директиву Require следующим образом:

Require group имя_группы ещё_имя_группы ...

Доступ будет разрешён только членам перечисленных групп.

Однако следует помнить, что просмотр текстового файла с описанием групп – достаточно непроизводительная операция. Возможно, лучшим решением будет прямое указание списка пользователей, имеющих доступ к ресурсу, непосредственно в директиве Require. Делается это аналогично:

Require user имя_пользователя ещё и_ещё ...