У меня есть веб-сервер, публикующий разные службы через один и тот же SSL VirtualHost, два из которых наиболее часто используются - PhpMyAdmin и Cacti. Они (и другие) используют аутентификацию в стиле cookie, запрашивая пользователя и пароль в форме HTML (таким образом, не используя аутентификацию HTTP).
Находясь на том же имени хоста, браузер Safari не справлялся с хорошо сохраненными паролями: если я войду в одно приложение с пользователем foo, а затем перейду в приложение два, он предложит мне пользователя foo и его пароль в форме входа. Раньше достаточно было изменить только имя пользователя для запрета, чтобы Safari автоматически вводил правильный пароль в поле формы. Раздражает, но я могу смириться с этим - имена пользователей короткие и легко запоминаются по сравнению с паролями, которые мы используем.
После обновления до safari5 это, похоже, больше не соответствует действительности: если я сохраню в сафари (фактически, пользовательскую цепочку ключей на OSX) учетные данные для https://www.foobarbaz.com/app1 И учетные данные для https://www.foobarbaz.com/app2 похоже, нет возможности для автозаполнения обоих на основе URL-адреса. Даже редактирование связки ключей для добавления пути (по умолчанию в ней будет храниться только имя хоста) не помогает.
Могу ли я что-нибудь сделать, чтобы все работало так, как я хочу, сохраняя при этом все на одном имени хоста? Конечно, можно изменить что-либо на стороне сервера, но я не могу переключить приложения на HTTP Auth (и не все будут поддерживать его в любом случае), чтобы использовать разные «области».
Насколько я понимаю вещи, в URI HTTP-запроса хост - это все, что находится между схемой (т.е. http: //) и концом домена верхнего уровня (т.е. .com/), а все справа от хоста - это запрос на обработку хостом.
Лучшее решение вашей проблемы - использовать поддомены. https://app1.foobarbaz.com/ и https://app2.foobarbaz.com. Вам нужно будет поместить поддомены в зону DNS для foobarbaz.com домен и настроить виртуальные хосты на веб-сервере для обработки запросов с помощью /app1 и /app2. И Apache, и IIS могут делать именно то, что вам нужно, без необходимости перенастраивать приложения. Вероятно, вам придется получить (или создать) новые сертификаты, чтобы SSL работал без ошибок безопасности браузера.
По-видимому, это запрещено согласно (ИМХО глупой) организационной политике. OP должен работать, чтобы изменить эту политику, потому что это противоречит тому, как работает Интернет.
Тем не менее, другой альтернативой является изменение каждого приложения для развертывания определенного файла cookie для себя, а затем просмотр всех возвращенных файлов cookie, чтобы найти его для себя. Как это делается, зависит от платформы и является вопросом StackOverflow.
Если вы имеете в виду аутентификацию с использованием HTTP-аутентификации (в отличие от HTML-формы), это работает: вы можете заставить ее работать, установив разные области аутентификации вместе с URL-адресом. Как это:
<Location /abc/>
AuthType Basic
AuthName "Realm for ABC"
AuthUserFile /var/www/html/domain.org/abc/.htpasswd
require valid-user
</Location>
<Location /xxx/>
AuthType Basic
AuthName "Realm for XXX"
AuthUserFile /var/www/html/domain.org/xxx/.htpasswd
require valid-user
</Location>
Интересная часть - это AuthName. Затем Safari запоминает / автоматически заполняет диалоговое окно HTTP-аутентификации для каждой области, а не только для домена.