|Integrert proxyautentisering: tenestekontoar og identitetsovertaking
|Undersøk tryggleikskonteksten bak integrert proxyautentisering når same applikasjon fungerer interaktivt, men feilar som netteneste eller planlagd prosess.
“Bruk Windows-legitimasjonen min” treng eit subjekt. I eit skrivebordsprogram kan det vere personen som køyrer det. I ei teneste kan det vere kontoen til tenesta. I ein nettapplikasjon erstattar ikkje ei vellukka pålogging for ein vitjande automatisk tryggleikskonteksten til den utgåande førespurnaden.
Dette forklarer kvifor ein nettlesar og tenarsidekode på same maskin kan få ulike resultat frå ein proxy med integrert autentisering. Dei presenterer kanskje ulike identitetar.
Namngi identitetane før du endrar koden
- Personen som er pålogga skrivebordsnettlesaren.
- Kontoen som er vert for applikasjonsprosessen.
- Kvar identitetsovertaking som er aktiv for den utgåande operasjonen.
- Kontoen som proxyen faktisk godtok eller avviste.
På dei støtta stiane til .NET for integrert autentisering gjeld DefaultCredentials gjeldande tryggleikskontekst. Det er ikkje eit globalt alias for alle som har opna ei side på ei anna maskin.
Viss produktet med vilje opptrer som ein brukar, treng identitetsovertaking og eventuelle krav om nettverksdelegering sitt eige støtta design. Å slå på ein generisk brytar for bruk av standardlegitimasjon etablerer ikkje det designet. Motsett bør ein bakgrunnsjobb som er meint å køyre som ein tenesteidentitet, ikkje vere avhengig av at nokon opnar ein nettlesar først.
Samanlikn den interaktive og den utrulla oppstarten utan løyndommar: kontokontekst, proxyendepunkt, annonsert metode og avvist identitet. Unngå å kopiere eit skrivebordspassord inn i applikasjonen berre fordi det fekk ein einskild førespurnad til å lukkast. Konfigurer kontoen applikasjonen skal bruke, og hald deretter det eigarskapet synleg i utrullingsposten.