Імёны карыстальнікаў з даменам у ўліковых даных проксі
Адрознівайце непазнавальнае імя ўліковага запісу ад API з асобнымі палямі дамена і не змяняйце ідэнтычнасць запісу толькі дзеля сінтаксісу URL.
Адзін адказ кажа выдаліць DOMAIN\. Другі — дадаць яго. Абодва змяненні могуць быць няправільнымі для вашага проксі.
Ёсць два пытанні: якую ідэнтычнасць чакае служба і як выбраны API прадстаўляе гэтую ідэнтычнасць.
| Інтэрфейс | Што трэба ўстанавіць |
|---|---|
| Адно поле імя ўліковага запісу | Дакладны сінтаксіс запісу, які прымае аператар |
| API ўліковых даных з полем дамена | Ці трэба падаваць дамен і імя карыстальніка асобна |
| Кампаненты ўліковых даных унутры URI | Як мэтавыя значэнні павінны быць закадзіраваны для гэтага кантэйнера |
Напрыклад, .NET прапануе канструктар NetworkCredential з асобнымі аргументамі імя карыстальніка, пароля і дамена. Змяшчаць дамен у два палі без розніцы — не пераносны спосаб наладзіць інтэграваную аўтэнтыфікацыю.
Базавая аўтэнтыфікацыя — іншы выпадак: сервер інтэрпрэтуе пададзены тэкст запісу паводле ўласнай палітыкі. Знаходжанне ў той жа сетцы не даказвае, што прэфікс дамена маецца на ўвазе. І імя з даменам не азначае аўтаматычна іншы пратакол аўтэнтыфікацыі.
Экранаванне URL павінна захоўваць мэтавы запіс, а не змяняць яго. Зваротная каса ў радку зыходнай мовы, зваротная каса ў імені запісу і яго працэнтнае кадаванне ўнутры URI — гэта асобныя ўзроўні.
Атрымайце прынятую форму ідэнтычнасці і схему ў аператара, затым выкарыстайце адпаведны інтэрфейс уліковых даных. Выпадковае чаргаванне кароткага імя, даменнага імя і імя, падобнага да адраса электроннай пошты, дае слабыя доказы пра зыходны 407.