Нельзя запрашивать HTTP-аутентификацию (будь то обычная аутентификация или встроенная аутентификация Windows), не вызывая всплывающее диалоговое окно аутентификации в случае, когда еще нет учетных данных.
Таким образом, в целом для гибридных подходов HTTP-auth + cookie-auth вы разрешаете анонимный и аутентифицированный доступ для большей части сайта, но разрешаете только аутентифицированный доступ к одному конкретному сценарию.
Когда пользователь заходит на страницу без авторизации, вы выкладываете страницу с формой входа для аутентификации на основе файлов cookie, а также ссылку на один URL, который разрешает только аутентифицированный доступ. Пользователь может заполнить форму для проверки подлинности файлов cookie и форм или перейти по ссылке, чтобы выполнить вход с использованием проверки подлинности HTTP.
Если пользователь перейдет по этой ссылке, он получит ответ 401
и должен будет предоставить HTTP-аутентификацию либо через диалог аутентификации, либо, возможно, автоматически с использованием встроенной аутентификации Windows. Как только это произошло один раз, браузер начнет отправлять одни и те же учетные данные на каждую будущую страницу, поэтому IIS будет декодировать эти учетные данные, чтобы получить ожидаемое REMOTE_USER
при запуске сценариев основного сайта.
Браузеры будут отправлять учетные данные только на страницы в том же каталоге, что и скрипт 401
, или его подкаталоги. По этой причине лучше всего поместить в корневой каталог необходимый сценарий проверки подлинности HTTP, например, /login.aspx
.
Однако есть несколько браузеров, которые не будут автоматически отправлять учетные данные для других страниц и требуют, чтобы каждый HTTP-запрос сначала отвечал 401
, прежде чем отправлять запрос снова с учетными данными. Это делает невозможными схемы произвольной аутентификации и гибридной аутентификации (а также значительно замедляет просмотр защищенных сайтов!). Единственный современный браузер, который делает это, это Safari. Вам может быть все равно, поскольку поддержка Safari встроенной проверки подлинности Windows в любом случае традиционно была шаткой, и он по-прежнему может использовать тип проверки подлинности форм + куки.