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