Şifre senkronizasyonu ‘kısmen tamamlandığında’ bir hata: Tek bir standart akışa ulaşmak

Kısa Özet

• İki uygulamanın kendi şifre değiştirme/resetleme mantıkları vardı ve arka uçları etkinleştirip/devre dışı bırakmak için konfigürasyon geçişlerine sahiptiler. Bu durum, kısmi senkronizasyonları sessizce mümkün kıldı.
• Çözüm: tek bir paylaşılan motor, bir kanonik sıra, arka uçlar zorunlu (konfigürasyon devre dışı bırakma yok) ve her deneme bir denetim kaydına yazılacak.
• Öğrenilen ders: birden fazla sistemi kapsayan bir yazım için, “konfigüre edilebilir adımlar” tehlikeli bir durumdur. Akışı sabit tutun ve hatayı belirgin hale getirin.

Kurulum

Bir kullanıcı şifresini değiştirdiğinde, bu şifrenin arka planda birkaç sisteme ulaşması gerekmektedir: bir dizin, bir harici veritabanı ve uygulamanın kendi veritabanı. İki ayrı uygulama, her biri biraz farklı kodla bu işlemleri yapıyordu ve her biri arka uçları açıp kapatmak için sync_oracle => true|false gibi konfigürasyon bayraklarına sahipti.

Esnek görünüyor. Ama aslında bir tuzak.

Neden Konfigüre Edilebilir Arka Uçlar Tehlikeli

Kısa Özet: 3 sistemden 2’sine güncelleme yapan bir şifre, hiçbirine güncelleme yapmaktan daha kötü bir durumdur — çünkü şimdi sistemler arasında uyumsuzluk oluşur ve kimse bir hata almaz.

Bir arka uç isteğe bağlı olarak atlanabilir hale geldiği anda, “atlama” ve “başarısız olma” kavramları birbirine karışır. Bir ortamda bir bayrağı açılınca, diğerinde unutulmuş olabilir ve bu durumda üretim ve test ortamları farklı akışları yürütür. Bir giriş hatasını çözmek için, hangi adımların gerçekten çalıştığını tersine mühendislik yapmak gerekir.

Kanonik Sıra

Sıra, estetik bir unsur değildir. En yetkili olanı önce çalıştırır, böylece bir sonraki adım başarısız olursa, kullanıcının yeni şifresinin çalıştığını belirtmemiş olursunuz.

change/reset request
        |
        v
 [ New Directory ] --ok--> [ External DB ] --ok--> [ Local App store ]
        |                       |                        |
       fail                    fail                     fail
        |                       |                        |
        +----> stop, record per-service status, surface the failure

        

Aynı motor, aynı sıra, iki uygulama. Değişim API’si ve sıfırlama akışı yalnızca iki giriş noktasıdır.

Her Arka Uç için Sürücü

Her hedef sistem, motorun altındaki verinin ne olduğundan bağımsız aynı yapıya sahip bir veri kaynak sınıfının arkasında yer alır:

interface PasswordTarget
{
    public function update(UserIdentifier $user, string $secret): SyncResult}

// Her arka uç bir sürücü: DirectoryTarget, ExternalDbTarget, LocalAppTarget.
// Motor, bunları kanonik sırayla yürütür ve başarısız olduğunda kısa devre yapar.

        

Bir hata durumunu ortaya çıkaran bir durum: ulaşılamayan bir harici arka uç, skipped olarak bildirilmelidir, disabled olarak değil. “Devre dışı” konfigürasyon durumu artık yok; “atlanan” ise bu deneme ile ilgili bir çalışma zamanıdır. Bunları karıştırmak gerçek kesintileri gizler.

Gözlemlenebilir Hale Getirme

Her deneme artık bir denetim kaydı oluşturuyor: hangi hizmetler erişildi, her birinin durumu ne zaman oldu. Bu, “senkronizasyon çalıştı mı?” sorusunu, kabile bilgisi olmaktan çıkarıyor ve üstünde küçük bir yönetici kayıt sayfası oluşturmayı basit hale getiriyor.

test('external backend down is recorded as skipped, not disabled', function () {
    $result = app(PasswordEngine::class)->run($user, 'new-secret');

    expect($result->status())->toBe()
        ->and($result->status())->toBe();
});

        

Sonuç

Eğer tek bir mantıksal yazım birden fazla sisteme yayılıyorsa, her atlamayı konfigüre etme isteğine karşı durun. Sıralamayı sabitleyin, her atlamayı zorunlu kılın ve her birinin sonucunu kaydedin. Gereksiz esneklik, hataları ayıklamayı imkansız hale getiren belirsizlik olur — ve kimlik bilgilerinde belirsizlik, sadece bir rahatsızlık değil, aynı zamanda bir güvenlik problemi olarak ortaya çıkar.