Імена користувачів із доменом в облікових даних проксі
Розрізняйте непрозоре ім'я облікового запису від API з окремими полями домену і не змінюйте ідентичність запису лише заради синтаксису URL.
Одна відповідь радить прибрати DOMAIN\. Інша — додати його. Обидві зміни можуть бути хибними для вашого проксі.
Є два питання: якої ідентичності очікує служба і як вибраний API представляє цю ідентичність.
| Інтерфейс | Що треба встановити |
|---|---|
| Одне поле імені облікового запису | Точний синтаксис запису, який приймає оператор |
| API облікових даних із полем домену | Чи потрібно подавати домен і ім'я користувача окремо |
| Компоненти облікових даних усередині URI | Як кодувати потрібні значення для цього контейнера |
Наприклад, .NET надає конструктор NetworkCredential з окремими аргументами імені користувача, пароля й домену. Вставляти домен у два поля без розбору — не переносний спосіб налаштувати інтегровану автентифікацію.
Базова автентифікація — інший випадок: сервер тлумачить наданий текст запису за власною політикою. Перебування в тій самій мережі не доводить, що префікс домену мається на увазі. І ім'я з доменом не стає автоматично іншим протоколом автентифікації.
Екранування URL має зберігати потрібний запис, а не змінювати його. Зворотна скісна риска в рядку мови джерела, зворотна скісна риска в імені запису та його відсоткове кодування всередині URI — це окремі шари.
Отримайте в оператора прийняту форму ідентичності та схему, потім використайте відповідний інтерфейс облікових даних. Безладне чергування короткого імені, доменного імені та імені, схожого на електронну пошту, дає слабкі докази щодо початкового 407.