Domeingekwalifiseerde gebruikersname in proxy-aanmeldgegewens
Onderskei 'n ondeursigtige rekeningnaam van API's met afsonderlike domeinvelde, en vermy om 'n rekeningidentiteit te verander net om URL-sintaksis te pas.
Een antwoord sê jy moet DOMAIN\ verwyder. 'n Ander sê jy moet dit byvoeg. Albei veranderinge kan verkeerd wees vir jou proxy.
Daar is twee vrae: watter identiteit die diens verwag, en hoe die gekose API daardie identiteit voorstel.
| Koppelvlak | Wat om vas te stel |
|---|---|
| Een enkele rekeningnaamveld | Die presiese rekeningnotasie wat die operateur aanvaar |
| Bewysings-API met 'n domeinveld | Of domein en gebruikersnaam afsonderlik verskaf moet word |
| Bewysingskomponente binne 'n URI | Hoe die bedoelde waardes vir daardie houer geënkodeer moet word |
Byvoorbeeld, .NET bied 'n NetworkCredential-konstruktor met afsonderlike gebruikersnaam-, wagwoord- en domeinargumente. Om 'n domein sonder onderskeid in twee velde te plaas, is nie 'n draagbare manier om geïntegreerde verifikasie op te stel nie.
Basiese verifikasie is 'n ander geval: die bediener interpreteer die verskafde rekeningteks volgens sy eie beleid. Om op dieselfde netwerk te wees, bewys nie dat 'n domeinvoorvoegsel geïmpliseer word nie. 'n Domeingekwalifiseerde naam is ook nie outomaties 'n ander verifikasieprotokol nie.
URL-escaping moet die bedoelde rekening bewaar eerder as om dit te verander. 'n Backslash in 'n brontaalstring, 'n backslash in 'n rekeningnaam en die persent-geënkodeerde voorstelling daarvan binne 'n URI is aparte lae.
Kry die aanvaarde identiteitsvorm en -skema by die operateur en gebruik dan die ooreenstemmende bewysingskoppelvlak. Om lukraak tussen 'n kort naam, 'n domeinnaam en 'n e-posagtige naam te wissel, lewer swak bewyse oor die oorspronklike 407.