Yinelenen şifre sıfırlama bağlantıları e-posta teslimatına değil, token oluşturmanın yeniden denenmesine bağlandı

Ne yanlış gitti

dev.to'da yayınlanan bir postmortem, bir mülk yönetim platformunun tek bir kurtarma talebi için sakinlere iki farklı şifre sıfırlama bağlantısı e-postası göndermesine nasıl yol açtığını anlatıyor. Yazarın belirttiğine göre kök neden, yeniden denemelerin yanlış katmana yönlendirilmesiydi: bir e-posta gönderimi belirsiz bir hata (zaman aşımı veya kopan bağlantı gibi) döndürdüğünde, tüm istek işleyicisi basitçe yeniden çalıştırılıyordu. Bu ikinci çalışma ilkinkiyle aynı amacı taşıyordu ama bambaşka bir yeni kimlik bilgisi ve genellikle yeni bir mesaj kimliği üretiyordu; böylece alıcı, ilk mesajın yeniden teslimi yerine ikinci, ayrı ayrı geçerli bir bağlantı almış oluyordu.

Yazar, ortamınriskleri iki yönde artırdığına dikkat çekiyor. Bir sakinin gerçekten ulaşan bir kurtarma mesajına ihtiyacı vardır; aynı zamanda, e-postanın gelmemesiyle ilgili bir iletişim formu şikayeti, kurtarma token'ının o yol üzerinden hiç ifşa edilmemesi koşuluyla doğru mülkün destek kuyruğuna yönlendirilmelidir.

Niyetin teslimattan ayrılması

Önerilen çözüm, sorumlulukların bilinçli bir şekilde ayrılmasıdır. Bir kimlik servisi şifre sıfırlama niyetini ve token üretimini üstlenir ve sürümlü bir şablon sözleşmesi yayınlar. Bir teslimat çalışanı (delivery worker) taşımayı üstlenir: bu sözleşmeyi render edebilir veya önceden render edilmiş bir sonucu kullanabilir; ancak talebi yeniden yorumlayamaz, kimlik bilgisi üretemez veya şablonları sessizce değiştiremez. Teslimat belirsiz bir şekilde başarısız olduğunda yalnızca tek bir değişmez mesaj komutunun gönderimi yeniden denenir ve kimlik bilgisi asla yeniden üretilmez.

Gönderiye göre tasarıma dört değişmez (invariant) temel oluşturur: tek bir kullanıcı eylemi tek bir mantıksal sıfırlama niyeti üretir; her teslimat denemesi aynı mesaj ID'sini, intent ID'sini, şablon sürümünü ve gizli olmayan bir alıcı parmak izini taşır; sert geri dönüş (hard bounce) veya baskılama (suppression) gibi kesin bir alıcı politikası kararı, o niyet için otomatik yeniden denemeleri durdurur; destek yönlendirmesi token'a veya ham şablon değişkenlerine değil, mülk ve kiracılık (tenancy) metadata'sına dayanır.

Nasıl ayıklanır

Yazar, sorun tespitine dört tanımlayıcı üzerinden bir join ile başlamayı öneriyor: intent, mesaj, şablon sürümü ve alıcı parmak izi. Tek bir intent iki mesaj ID'sine eşleniyorsa, yinelenme taşıma döngüsünden önce üretilmiştir. Tek bir mesaj ID'si iki şablon sürümü taşıyorsa, şablon çözümlemesi bir yerde değişkendir. Dört anahtar da denemeler boyunca kararlıysa, dikkat taşıma sonuçlarına ve alıcı politikasına kaydırılır.

Gönderi ayrıca baskılama (suppression) durumunu sıfırlama niyetinden ayırıyor. Bir alıcı baskılama listesinde bulunabilir; ancak o kayıt, başka bir teslimat denemesine izin verilip verilmeyeceğini belirlerken, intent kaydı sakinin gerçekte hangi kurtarma eylemini talep ettiğini belgeler. Yazar, denetim günlüğünün (audit log) olay tabanlı olması gerektiğini yazar; intent oluşturma, mesaj render etme, teslimat denemeleri, sonuç kaydı ve destek vakası yönlendirmesi gibi olayları kapsamalı, kişisel verilerin yerine hash veya opak tanımlayıcılar kullanılmalı ve sıfırlama token'ı asla günlüğe yazılmamalıdır. Yazara göre otomatik baskıyı-kaldır-ve-yeniden-gönder davranışı genel bir retry döngüsüne ait değildir; bir kısıtlamayı kaldırmak, onaylı bir politika altında verilmiş ve kayıt altına alınmış bir karar olmalıdır.

Şablon sahipliği ödünleşimleri

Gönderide üç sahiplik modeli tartışılıyor. Kimlik alanının sürümlü bir sözleşmeye sahip olması, politika ile render edilmiş kanıtı birleştirilebilir kılar; maliyeti ise eşgüdümlü sözleşme sürümleridir. Teslimat çalışanının şablonlara sahip olması, taşıma ekibinin daha hızlı yinelemesini sağlar ama alanın, kimlik bilgisi içeren ifadeler üzerindeki denetimini zayıflatır. Hesap kurtarma için burada reddedilen çağrıcıya ait markup modeli ise uygulama ekiplerine yerel özerklik verir ama denetim kanıtını parçalar ve çağrıcıların değişkenlerde, kaçış davranışında ve dağıtım geçmişinde birbirinden ayrışmasına izin verir.

Uygulama tarafında yazar, Go ile bir yol taslaklandırıyor: bir veritabanı işlemi, intent'i outbox komutuyla birlikte atomik olarak kalıcı hale getirir; böylece sürecin sonlanması birini diğerinden yoksun bırakamaz. Denemeler idempotent bir begin-attempt-once kontrolüyle sınırlandırılır, render işlemi bir şablon sürümüne sabitlenir ve eksik bir şablon değişkeni, göndermeyi yeniden denemek için bir gerekçe değil, kalıcı bir render hatası olarak ele alınır. Önerilen operasyonel test, kaydedilmiş bir komutu sabitlendiği şablonla yeniden oynatıp mantıksal içeriğin özdeş olduğunu doğrulamak, ardından render hataları, belirsiz taşıma hataları, kesin sonuçlar ve baskılamalar enjekte etmektir. Yalnızca belirsiz, kesin olmayan deneme yeniden planlanmalı ve her test tek bir intent ID'si ile mesaj ID'sini korumalıdır.

Neden önemli

Yinelenen sıfırlama bağlantıları genellikle kozmetik bir rahatsızlık olarak görmezden gelinir; ancak her yinelenme, güvenilir olmayan bir kanaldan teslim edilen, aynı hesaba ait ek bir geçerli kimlik bilgisidir. Gönderinin daha geniş dersi şifre sıfırlamanın ötesine genellenir: bir iş komutu ile bir taşıma komutu aynı işleyiciyi paylaştığında, belirsiz bir başarısızlık sistemi, geri alamayacağı yan etkileri yeniden yapmaya davet eder. İş sınırındaki idempotans — tek intent, tek mesaj kimliği ve değişmez render edilmiş içerik olarak ifade edildiğinde — yeniden denemeleri rutin bir işlem haline getirir ve operatörlere, sırrı hiç ifşa etmeden ne olduğunu yeniden yapılandırabilen kalıcı bir kayıt defteri sunar.