Domenekvalifiserte brukarnamn i proxy-legitimasjon
Skil eit ugjennomsiktig kontonamn frå API-ar med separate domenefelt, og unngå å endre ein kontoidentitet berre for å tilfredsstille URL-syntaksen.
Eitt svar seier at du skal fjerne DOMAIN\. Eit anna seier at du skal leggje det til. Begge endringane kan vere feil for proxyen din.
Det er to spørsmål: kva identitet tenesta ventar, og korleis den valde API-en representerer den identiteten.
| Grensesnitt | Kva som må fastslåast |
|---|---|
| Eitt enkelt kontonamnfelt | Den nøyaktige kontosyntaksen som operatøren godtek |
| Ein legitimasjons-API med domenefelt | Om domene og brukarnamn skal oppgivast separat |
| Legitimasjonskomponentar i ein URI | Korleis dei tiltenkte verdiane skal kodast for den behaldaren |
Til dømes eksponerer .NET ein NetworkCredential-konstruktør med separate argument for brukarnamn, passord og domene. Å setje eit domene i to felt utan skilje er ikkje ein flyttbar måte å konfigurere integrert autentisering på.
Basic-autentisering er eit anna tilfelle: tenaren tolkar den oppgjevne kontoteksten etter si eiga retningslinje. Å vere på same nettverk beviser ikkje at eit domeneprefiks er underforstått. Eit domenekvalifisert namn er heller ikkje automatisk ein annan autentiseringsprotokoll.
URL-escaping bør ta vare på den tiltenkte kontoen i staden for å endre han. Ein omvend skråstrek i ein streng på kjeldespråket, ein omvend skråstrek i eit kontonamn og den prosentkoda framstillinga hans i ein URI er skilde lag.
Skaff den godtekne identitetsforma og skjemaet frå operatøren, og bruk deretter det tilsvarande legitimasjonsgrensesnittet. Tilfeldig veksling mellom kortnamn, domenenamn og e-postliknande namn gjev svake prov om den opphavlege 407.