Domeingekwalificeerde gebruikersnamen in proxy-inloggegevens
Onderscheid een ondoorzichtige accountnaam van API's met afzonderlijke domeinvelden, en vermijd het wijzigen van een accountidentiteit alleen om aan de URL-syntaxis te voldoen.
Het ene antwoord zegt DOMAIN\ te verwijderen. Het andere zegt het toe te voegen. Beide wijzigingen kunnen onjuist zijn voor jouw proxy.
Er zijn twee vragen: welke identiteit de dienst verwacht, en hoe de gekozen API die identiteit voorstelt.
| Interface | Wat vast te stellen |
|---|---|
| Eén accountnaamveld | De exacte accountsyntaxis die de operator accepteert |
| Een inloggegevens-API met een domeinveld | Of domein en gebruikersnaam afzonderlijk moeten worden opgegeven |
| Inloggegevenscomponenten binnen een URI | Hoe de bedoelde waarden voor die container moeten worden gecodeerd |
Bijvoorbeeld: .NET biedt een NetworkCredential-constructor met afzonderlijke argumenten voor gebruikersnaam, wachtwoord en domein. Een domein zonder onderscheid in twee velden zetten is geen draagbare manier om geïntegreerde verificatie te configureren.
Basic-verificatie is een ander geval: de server interpreteert de aangeleverde accounttekst volgens zijn eigen beleid. Op hetzelfde netwerk zitten bewijst niet dat een domeinprefix impliciet is. Een domeingekwalificeerde naam is ook niet automatisch een ander verificatieprotocol.
URL-escaping moet het bedoelde account behouden in plaats van het te wijzigen. Een backslash in een tekenreeks van de brontaal, een backslash in een accountnaam en de procentgecodeerde weergave daarvan binnen een URI zijn afzonderlijke lagen.
Vraag de geaccepteerde identiteitsvorm en het schema op bij de operator en gebruik dan de bijbehorende inloggegevensinterface. Willekeurig wisselen tussen een korte naam, een domeinnaam en een e-mailachtige naam levert zwak bewijs over de oorspronkelijke 407.