Domenekvalifiserte brukernavn i proxy-legitimasjon
Skille et ugjennomsiktig kontonavn fra API-er med separate domenefelt, og unngå å endre en kontoidentitet bare for å tilfredsstille URL-syntaksen.
Ett svar sier at du må fjerne DOMAIN\. Et annet sier at du må legge det til. Begge endringene kan være gale for proxyen din.
Det finnes to spørsmål: hvilken identitet tjenesten forventer, og hvordan den valgte API-en representerer denne identiteten.
| Grensesnitt | Hva som må avklares |
|---|---|
| Ett kontonavnfelt | Den eksakte kontosyntaksen som operatøren aksepterer |
| En legitimasjons-API med domenefelt | Om domene og brukernavn må oppgis hver for seg |
| Legitimasjonskomponenter inne i en URI | Hvordan de tiltenkte verdiene må kodes for den beholderen |
For eksempel tilbyr .NET en NetworkCredential-konstruktør med separate argumenter for brukernavn, passord og domene. Å plassere et domene i to felt uten å skille er ikke en flyttbar måte å konfigurere integrert autentisering på.
Basic-autentisering er et annet tilfelle: serveren tolker den oppgitte kontoteksten etter sin egen policy. At du er 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 den prosentkodede representasjonen i en URI er atskilte lag.
Hent den aksepterte 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.