Потребителски имена с домейн в прокси идентификационните данни
Различавайте непрозрачното име на акаунт от API с отделни полета за домейн и не променяйте идентичността на акаунта само заради синтаксиса на URL.
Един отговор казва да премахнете DOMAIN\. Друг казва да го добавите. И двете промени могат да са грешни за вашия прокси.
Има два въпроса: каква идентичност очаква услугата и как избраният API представя тази идентичност.
| Интерфейс | Какво да установите |
|---|---|
| Едно поле за име на акаунт | Точният синтаксис на акаунта, който операторът приема |
| API за идентификационни данни с поле за домейн | Дали домейнът и потребителското име трябва да се подават отделно |
| Компоненти на идентификационните данни в URI | Как целевите стойности трябва да се кодират за този контейнер |
Например .NET предоставя конструктор NetworkCredential с отделни аргументи за потребителско име, парола и домейн. Поставянето на домейн в две полета безразборно не е преносим начин за настройка на интегрирана автентикация.
Basic автентикацията е друг случай: сървърът тълкува подадения текст на акаунта по своя собствена политика. Това, че сте в същата мрежа, не доказва, че префиксът с домейн се подразбира. Нито пък име с домейн е автоматично различен протокол за автентикация.
Екранирането на URL трябва да запази целевия акаунт, а не да го промени. Обратната наклонена черта в низ на езика източник, в името на акаунта и процентното ѝ кодиране в URI са отделни слоеве.
Вземете приетата форма на идентичност и схема от оператора, след което използвайте съответния интерфейс за идентификационни данни. Случайното редуване между кратко име, име с домейн и име, подобно на имейл, дава слаби доказателства за първоначалния 407.