Vi ŝanĝis la proksian pasvorton. Unu konstruo ankoraŭ havas la malnovan kopion.

La nova pasvorto funkcias en la retumilo. Projekto A konstruiĝas. Projekto B redonas 407. La proksio ne devas elekti hazarde: unu el ĝiaj klientoj eble ankoraŭ prezentas malnovan legitimilon.

Spuru konsumantojn, ne nur dosierojn

Projektspecifa propraĵa dosiero povas malsami de la uzula defaŭlto. Media valoro povas esti kaptita kiam lanĉilo komenciĝas. Legitimilhelpilo povas havi propran konservitan eron. Neniu estas ĝisdatigata nur ĉar alia aplikaĵo akceptis la novan pasvorton.

Faru mallongan inventaron de la konsumantoj, kiuj efektive uzas la konton: interagaj iloj, konstruaj servoj, planitaj taskoj kaj aplikaĵklientoj. Por ĉiu, notu de kie venas la valoro kaj kiam ĝi estas legata. Tenu la valoron mem ekster la inventaro.

Komparu la malsukcesan procezon kun la funkcianta

Kontrolu la konton, la laboran dosierujon, la elektitan agordon kaj la fonton de legitimiloj. Du projektoj kun similaj dependecoj povas uzi malsamajn lokajn dosierojn. Longdaŭra agento povas reteni enigon de antaŭ la rotacio eĉ post kiam nova terminalo vidas la ĝisdatigitan medion.

Uzu intencan restartigon aŭ dokumentitan agordan refreŝigon nur tie, kie tiu kliento bezonas ĝin. Restartigi ĉion samtempe kaŝas, kiu konsumanto estis malnova, kaj povas interrompi ne ligitan laboron.

Ne konfuzu klientan refreŝigon kun revokado

Ĝisdatigi klientojn kaj igi malnovajn legitimilojn neuzeblaj estas apartaj operacioj. Proksio povas havi aŭtentigadan kaŝmemoron, kaj establita konekto povas havi alian vivociklon ol la pasvorta dosiero. Sekvu la revokan politikon de la funkciiganto anstataŭ supozi, ke unu sukcesa peto pruvas, ke la malnova konta materialo malaperis.

Por la sekva rotacio, faru la konsumantan liston parto de la ŝanĝo. Sukcesa rezulto estas, ke ĉiu celata kliento uzas sian celatan fonton kaj konton, ne nur ke la pasvorta dialogo fermiĝis en unu laborstacio.