Domenu kvalifikuoti naudotojų vardai proxy kredencialuose
Atskirkite nepermatomą paskyros pavadinimą nuo API, turinčių atskirus domeno laukus, ir venkite keisti paskyros tapatybę vien dėl URL sintaksės.
Vienas atsakymas sako pašalinti DOMAIN\. Kitas sako jį pridėti. Abiejų pakeitimų jūsų proxy atveju gali būti neteisingi.
Yra du klausimai: kokios tapatybės tikisi paslauga ir kaip pasirinkta API pateikia tą tapatybę.
| Sąsaja | Ką nustatyti |
|---|---|
| Vienas paskyros pavadinimo laukas | Tiksli paskyros sintaksė, kurią priima operatorius |
| Kredencialų API su domeno lauku | Ar domenas ir naudotojo vardas turi būti pateikiami atskirai |
| Kredencialų komponentai URI viduje | Kaip numatytos reikšmės turi būti užkoduotos tam konteineriui |
Pavyzdžiui, .NET siūlo NetworkCredential konstruktorių su atskirais naudotojo vardo, slaptažodžio ir domeno argumentais. Dėti domeną į du laukus neatskiriant nėra perkeliamas būdas konfigūruoti integruotą autentifikavimą.
Basic autentifikavimas yra kitas atvejis: serveris pateiktą paskyros tekstą interpretuoja pagal savo politiką. Buvimas tame pačiame tinkle neįrodo, kad domeno priešdėlis numanomas. Be to, domenu kvalifikuotas vardas nėra automatiškai kitas autentifikavimo protokolas.
URL escapinimas turėtų išsaugoti numatytą paskyrą, o ne ją keisti. Atgalinis brūkšnys šaltinio kalbos eilutėje, atgalinis brūkšnys paskyros pavadinime ir jo procentinis kodavimas URI viduje yra atskiri sluoksniai.
Gaukite priimtiną tapatybės formą ir schemą iš operatoriaus, tada naudokite atitinkamą kredencialų sąsają. Atsitiktinis kaitaliojimas tarp trumpo vardo, domeno vardo ir el. paštą primenančio vardo duoda silpnus įrodymus apie pirminį 407.