Lénskilyrt notandanöfn í proxy-skírteinum
Aðgreindu ógagnsætt reikningsheiti frá API-viðmótum með aðskildum lénafeltum, og forðist að breyta auðkenni reiknings eingöngu til að uppfylla URL-málskipan.
Eitt svar segir að fjarlægja DOMAIN\. Annað segir að bæta því við. Báðar breytingar geta verið rangar fyrir proxyið þitt.
Tvær spurningar eru til: hvaða auðkenni þjónustan væntir, og hvernig valið API táknar það auðkenni.
| Viðmót | Hvað á að staðfesta |
|---|---|
| Eitt reikningsheiti-reitur | Nákvæm reikningsmálskipan sem rekstraraðilinn samþykkir |
| Skírteina-API með lénafelt | Hvort lén og notandanafn eigi að gefa aðskilið |
| Skírteinahlutar innan URI | Hvernig á að kóða fyrirhuguð gildi fyrir þá gámmá |
Til dæmis býður .NET upp á NetworkCredential-smið með aðskildum rökum fyrir notandanafn, lykilorð og lén. Að setja lén í tvo reiti án greinarmunar er ekki flutningshæfur háttur til að stilla samþætta auðkenningu.
Basic-auðkenning er annað tilvik: þjónninn túlkar uppgefið reikningstexta samkvæmt eigin stefnu. Að vera á sama neti sannar ekki að lénsforskeyti sé gefið í skyn. Lénskilyrt nafn er heldur ekki sjálfkrafa önnur auðkenningarregla.
URL-escaping ætti að varðveita fyrirhugaðan reikning frekar en að breyta honum. Öfug skástrik í streng upprunamáls, öfug skástrik í reikningsheiti og prósentukóðuð framsetning þess innan URI eru aðskilin lög.
Fáðu samþykkta auðkennisformið og skemað frá rekstraraðilanum og notaðu síðan samsvarandi skírteinaviðmót. Tilviljanakennd skipst á stuttu nafni, lénsheiti og tölvupóstslíku heiti gefur veikar sannanir um upprunalega 407.