Zmieniono hasło proxy. Jeden build nadal ma starą kopię.

Nowe hasło działa w przeglądarce. Projekt A się buduje. Projekt B zwraca 407. Proxy nie musi wybierać losowo: jeden z jego klientów może nadal przedstawiać stare poświadczenie.

Śledź konsumentów, nie tylko pliki

Plik właściwości specyficzny dla projektu może różnić się od domyślnego użytkownika. Wartość środowiska może zostać przechwycona przy starcie launchera. Pomocnik poświadczeń może mieć własny zapisany wpis. Żaden z nich nie jest aktualizowany tylko dlatego, że inna aplikacja zaakceptowała nowe hasło.

Zrób krótki spis konsumentów, którzy naprawdę używają konta: narzędzia interaktywne, usługi budowania, zadania zaplanowane i klienci aplikacji. Dla każdego zapisz, skąd pochodzi wartość i kiedy jest odczytywana. Samą wartość trzymaj poza spisem.

Porównaj proces, który zawodzi, z działającym

Sprawdź konto, katalog roboczy, wybraną konfigurację i źródło poświadczeń. Dwa projekty o podobnych zależnościach mogą używać różnych plików lokalnych. Długo działający agent może zachować dane wejściowe sprzed rotacji, nawet gdy nowy terminal widzi zaktualizowane środowisko.

Używaj celowego restartu lub udokumentowanego odświeżenia konfiguracji tylko tam, gdzie dany klient tego potrzebuje. Restart wszystkiego naraz ukrywa, który konsument był nieaktualny, i może przerwać niezwiązaną pracę.

Nie mieszaj odświeżenia klienta z unieważnieniem

Aktualizacja klientów i uczynienie starych poświadczeń bezużytecznymi to osobne operacje. Proxy może mieć pamięć podręczną uwierzytelniania, a ustanowione połączenie może mieć inny cykl życia niż plik hasła. Postępuj zgodnie z polityką unieważniania operatora, zamiast zakładać, że jedno udane żądanie dowodzi zniknięcia starego materiału konta.

Przy następnej rotacji włącz listę konsumentów do zmiany. Sukcesem jest to, że każdy zamierzony klient używa zamierzonego źródła i konta, a nie tylko zamknięcie okna hasła na jednej stacji roboczej.