Du byttet proxy-passordet. Én build har fortsatt den gamle kopien.

Det nye passordet fungerer i nettleseren. Prosjekt A bygges. Prosjekt B returnerer 407. Proxyen trenger ikke velge tilfeldig: én av klientene kan fortsatt presentere en gammel legitimasjon.

Følg brukere, ikke bare filer

En prosjektspesifikk egenskapsfil kan avvike fra brukerens standard. En miljøverdi kan fanges opp når en oppstarter begynner. En legitimasjonshjelper kan ha sin egen lagrede oppføring. Ingen av dem oppdateres bare fordi en annen applikasjon godtok det nye passordet.

Lag en kort fortegnelse over brukerne som faktisk bruker kontoen: interaktive verktøy, byggetjenester, planlagte oppgaver og applikasjonsklienter. For hver av dem, noter hvor verdien kommer fra og når den leses. Hold selve verdien utenfor fortegnelsen.

Sammenlign prosessen som feiler med den som virker

Kontroller kontoen, arbeidsmappen, valgt konfigurasjon og legitimasjonskilde. To prosjekter med lignende avhengigheter kan bruke forskjellige lokale filer. En langvarig agent kan beholde inndata fra før rotasjonen selv etter at en ny terminal ser det oppdaterte miljøet.

Bruk en bevisst omstart eller dokumentert konfigurasjonsoppdatering bare der den klienten trenger det. Å starte alt på nytt samtidig skjuler hvilken bruker som var utdatert og kan avbryte urelatert arbeid.

Ikke forveksle klientoppdatering med tilbakekalling

Å oppdatere klienter og å gjøre gamle legitimasjoner ubrukelige er separate operasjoner. En proxy kan ha autentiseringsbuffer, og en etablert tilkobling kan ha en annen livssyklus enn passordfilen. Følg operatørens tilbakekallingspolicy i stedet for å anta at én vellykket forespørsel beviser at det gamle kontomaterialet er borte.

Gjør brukerlisten til en del av endringen ved neste rotasjon. Et vellykket resultat er at hver tiltenkt klient bruker sin tiltenkte kilde og konto, ikke bare at passorddialogen lukkes på én arbeidsstasjon.