Имена пользователей с доменом в учётных данных прокси
Отличайте непрозрачное имя учётной записи от API с отдельными полями домена и не меняйте идентичность учётной записи только ради синтаксиса URL.
Один ответ советует убрать DOMAIN\. Другой — добавить его. Оба изменения могут быть неверными для вашего прокси.
Есть два вопроса: какую идентичность ожидает служба и как выбранный API представляет эту идентичность.
| Интерфейс | Что нужно установить |
|---|---|
| Одно поле имени учётной записи | Точный синтаксис учётной записи, который принимает оператор |
| API учётных данных с полем домена | Нужно ли передавать домен и имя пользователя отдельно |
| Компоненты учётных данных внутри URI | Как следует кодировать нужные значения для этого контейнера |
Например, .NET предоставляет конструктор NetworkCredential с отдельными аргументами имени пользователя, пароля и домена. Помещать домен в два поля без разбора — не переносимый способ настроить интегрированную проверку подлинности.
Базовая проверка подлинности — другой случай: сервер интерпретирует переданный текст учётной записи по собственной политике. Нахождение в одной сети не доказывает, что префикс домена подразумевается. И имя с доменом не становится автоматически другим протоколом проверки подлинности.
Экранирование URL должно сохранять нужную учётную запись, а не менять её. Обратная косая черта в строке исходного языка, обратная косая черта в имени учётной записи и её процентное кодирование внутри URI — это отдельные слои.
Получите у оператора принятую форму идентичности и схему, затем используйте соответствующий интерфейс учётных данных. Беспорядочное чередование короткого имени, доменного имени и имени, похожего на адрес электронной почты, даёт слабые доказательства относительно исходного 407.