Domænekvalificerede brugernavne i proxy-legitimationsoplysninger
Skeln mellem et uigennemsigtigt kontonavn og API'er med separate domænefelter, og undgå at ændre en kontoidentitet blot for at opfylde URL-syntaksen.
Et svar siger, at du skal fjerne DOMAIN\. Et andet siger, at du skal tilføje det. Begge ændringer kan være forkerte for din proxy.
Der er to spørgsmål: hvilken identitet tjenesten forventer, og hvordan den valgte API repræsenterer den identitet.
| Grænseflade | Hvad der skal fastslås |
|---|---|
| Et enkelt kontonavnefelt | Den præcise kontosyntaks, som operatøren accepterer |
| En legitimations-API med et domænefelt | Om domæne og brugernavn skal angives separat |
| Legitimationskomponenter i en URI | Hvordan de tilsigtede værdier skal kodes for den beholder |
For eksempel eksponerer .NET en NetworkCredential-konstruktør med separate argumenter for brugernavn, adgangskode og domæne. At sætte et domæne i to felter uden skel er ikke en portabel måde at konfigurere integreret godkendelse på.
Basic-godkendelse er et andet tilfælde: serveren fortolker den angivne kontotekst efter sin egen politik. At være på samme netværk beviser ikke, at et domænepræfiks er underforstået. Et domænekvalificeret navn er heller ikke automatisk en anden godkendelsesprotokol.
URL-escaping bør bevare den tilsigtede konto i stedet for at ændre den. En omvendt skråstreg i en streng på kildesproget, en omvendt skråstreg i et kontonavn og dets procentkodede repræsentation i en URI er adskilte lag.
Få den accepterede identitetsform og det accepterede skema fra operatøren, og brug derefter den tilsvarende legitimationsgrænseflade. Tilfældig vekslen mellem et kort navn, et domænenavn og et e-mail-lignende navn giver dårligt bevis om den oprindelige 407.