Ви змінили пароль проксі. Одна збірка досі має стару копію.

Новий пароль працює в браузері. Проєкт A збирається. Проєкт B повертає 407. Проксі не зобов'язаний вибирати випадково: один із його клієнтів може досі подавати старі облікові дані.

Стежте за споживачами, а не лише за файлами

Файл властивостей конкретного проєкту може відрізнятися від типового для користувача. Значення середовища може бути захоплене під час запуску лаунчера. Помічник облікових даних може мати власний збережений запис. Ніщо з цього не оновлюється лише тому, що інший застосунок прийняв новий пароль.

Складіть короткий перелік споживачів, які справді використовують обліковий запис: інтерактивні інструменти, служби збірки, заплановані завдання та клієнти застосунків. Для кожного запишіть, звідки береться значення і коли воно читається. Саме значення тримайте поза переліком.

Порівняйте невдалий процес із робочим

Перевірте обліковий запис, робочий каталог, вибрану конфігурацію та джерело облікових даних. Два проєкти з подібними залежностями можуть використовувати різні локальні файли. Довготривалий агент може зберігати вхідні дані до зміни навіть після того, як новий термінал бачить оновлене середовище.

Використовуйте навмисний перезапуск або задокументоване оновлення конфігурації лише там, де цьому клієнту це потрібно. Перезапуск усього одразу приховує, який споживач застарів, і може перервати не пов'язану роботу.

Не плутайте оновлення клієнта з відкликанням

Оновлення клієнтів і знецінення старих облікових даних — окремі операції. Проксі може мати кеш автентифікації, а встановлене з'єднання може мати інший життєвий цикл, ніж файл пароля. Дотримуйтеся політики відкликання оператора, а не припускайте, що один успішний запит доводить зникнення старого матеріалу облікового запису.

Для наступної зміни зробіть список споживачів частиною змін. Успішний результат — кожен передбачений клієнт використовує передбачене джерело й обліковий запис, а не просто закриття діалогу пароля на одній робочій станції.