Domänkvalificerade användarnamn i proxyinloggningsuppgifter
Skilj ett ogenomskinligt kontonamn från API:er med separata domänfält, och undvik att ändra en kontoidentitet bara för att uppfylla URL-syntaxen.
Ett svar säger att du ska ta bort DOMAIN\. Ett annat säger att du ska lägga till det. Båda ändringarna kan vara fel för din proxy.
Det finns två frågor: vilken identitet tjänsten förväntar sig, och hur det valda API:et representerar den identiteten.
| Gränssnitt | Vad som ska fastställas |
|---|---|
| Ett enda kontonamnfält | Den exakta kontosyntax som operatören accepterar |
| Ett inloggningsuppgifts-API med domänfält | Om domän och användarnamn ska anges separat |
| Inloggningsuppgiftskomponenter i en URI | Hur de avsedda värdena ska kodas för den behållaren |
Till exempel exponerar .NET en NetworkCredential-konstruktor med separata argument för användarnamn, lösenord och domän. Att sätta en domän i två fält utan åtskillnad är inte ett portabelt sätt att konfigurera integrerad autentisering.
Basic-autentisering är ett annat fall: servern tolkar den angivna kontotexten enligt sin egen policy. Att vara på samma nätverk bevisar inte att ett domänprefix är underförstått. Ett domänkvalificerat namn är inte heller automatiskt ett annat autentiseringsprotokoll.
URL-escaping bör bevara det avsedda kontot i stället för att ändra det. Ett omvänt snedstreck i en sträng på källspråket, ett omvänt snedstreck i ett kontonamn och dess procentkodade representation i en URI är skilda lager.
Hämta den accepterade identitetsformen och schemat från operatören och använd sedan motsvarande inloggningsuppgiftsgränssnitt. Slumpmässigt växlande mellan kortnamn, domännamn och e-postliknande namn ger svaga bevis om den ursprungliga 407.