Domenekvalifiserte brukernavn i proxy-legitimasjon
Skill et ugjennomsiktig kontonavn fra API-er med separate domenefelt, og unngå å endre en kontoidentitet bare for å tilfredsstille URL-syntaksen.
Ett svar sier at du skal fjerne DOMAIN\. Et annet sier at du skal legge det til. Begge endringene kan være feil for proxyen din.
Det er to spørsmål: hvilken identitet tjenesten forventer, og hvordan den valgte API-en representerer den identiteten.
| Grensesnitt | Hva som må fastslås |
|---|---|
| Ett enkelt kontonavnfelt | Den nøyaktige kontosyntaksen som operatøren godtar |
| En legitimasjons-API med domenefelt | Om domene og brukernavn skal oppgis separat |
| Legitimasjonskomponenter i en URI | Hvordan de tiltenkte verdiene skal kodes for den beholderen |
For eksempel eksponerer .NET en NetworkCredential-konstruktør med separate argumenter for brukernavn, passord og domene. Å sette et domene i to felt uten skille er ikke en portabel måte å konfigurere integrert autentisering på.
Basic-autentisering er et annet tilfelle: serveren tolker den oppgitte kontoteksten etter sin egen policy. Å være på samme nettverk beviser ikke at et domeneprefiks er underforstått. Et domenekvalifisert navn er heller ikke automatisk en annen autentiseringsprotokoll.
URL-escaping bør bevare den tiltenkte kontoen i stedet for å endre den. En omvendt skråstrek i en streng på kildespråket, en omvendt skråstrek i et kontonavn og dens prosentkodede representasjon i en URI er adskilte lag.
Skaff den godtatte identitetsformen og skjemaet fra operatøren, og bruk deretter det tilsvarende legitimasjonsgrensesnittet. Tilfeldig veksling mellom kortnavn, domenenavn og e-postlignende navn gir svake bevis om den opprinnelige 407.