Кориснички имиња со домен во прокси акредитивите
Разликувајте нетранспарентно име на сметка од API со одделни полиња за домен и избегнувајте менување на идентитетот на сметката само за да се задоволи синтаксата на URL.
Еден одговор вели отстранете DOMAIN\. Друг вели додајте го. Двете промени можат да бидат погрешни за вашиот прокси.
Има две прашања: кој идентитет го очекува услугата и како избраниот API го претставува тој идентитет.
| Интерфејс | Што треба да се утврди |
|---|---|
| Едно поле за име на сметка | Точната синтакса на сметката што ја прифаќа операторот |
| API за акредитиви со поле за домен | Дали доменот и корисничкото име треба да се дадат одделно |
| Компоненти на акредитивите во URI | Како предвидените вредности треба да се кодираат за тој контејнер |
На пример, .NET изложува конструктор NetworkCredential со одделни аргументи за корисничко име, лозинка и домен. Ставањето домен во две полиња без разлика не е пренослив начин за конфигурирање интегрирана автентикација.
Основната автентикација е друг случај: серверот го толкува доставениот текст на сметката според сопствената политика. Тоа што сте на истата мрежа не докажува дека префиксот на домен е имплицитен. Ниту пак името со домен автоматски е различен протокол за автентикација.
URL escaping треба да ја зачува предвидената сметка наместо да ја менува. Обратна коса црта во низа на изворниот јазик, обратна коса црта во името на сметката и неговото процентно кодирање во URI се одделни слоеви.
Добијте ја прифатената форма на идентитет и шемата од операторот, потоа користете го соодветниот интерфејс за акредитиви. Наизменичното менување меѓу кратко име, име со домен и име налик на е-пошта дава слаби докази за оригиналниот 407.