Halka Açık Bir SaaS Motoru Geliştirmek: İzleyicileri Dışlamadan Bir Kiracıyı Askıya Alma

Bu hafta LaraFoundry’nin v0.10.0 sürümünü etiketledim: admin şirket konsolu. Bu, birkaç sürüm önce admin kullanıcılar ekranından sonra operator panelinin ikinci ekranıdır ve ana özellik, platform operatörünün bir kiracıyı tamamen askıya alabilmesidir. Şirketin engellenmesi kolay kısım oldu. Ancak yazılması gereken kısım, diğer şirketlere ait olan kişilerin de engellenmemesi gerektiğiydi.

LaraFoundry, canlı bir CRM’den kamuya açık olarak çıkardığım bir SaaS çekirdek yapısıdır; bir modül bir kerede. O CRM’nin daha önceki bir versiyonu zaten üretimde çalışıyor, bu nedenle çoğu aşama “bir özellik icat et”ten ziyade “bir özellik çıkar ve bir uygulama için iyi olan ve tekrar kullanılabilir bir çekirdek için yanlış olan alışkanlıkları fark et” şeklinde geçiyor. Bu aşama oldukça verimli geçti.

Bir Şirketi “Engelleme” Yöntemi

Gerçek cevap doğrudan şirket düzeyinde bir engelleme olmadığıdır. Eğer bir kiracıyı kesmek gerekiyorsa, sahibini yasaklarsınız ve bir middleware ardından sahibinin yasaklandığı kişilerin erişimini engeller. Şirket, bir kişinin ceza alması sonucu kararmış oldu.

Bu, doğru çalışana kadar problem yok. Sahibin yasaklanması ile şirketin askıya alınması, iki farklı operatör eylemi ve iki farklı anlam taşır. Bir sahibi kötü niyetli olabilirken, şirketi çalışan masraflarını karşılamaya devam edebilir. Bir şirket, herhangi bir şey yapmadan askıya alınabilir. İkisini “sahibi yasakla” şeklinde birleştirmek, birinin ifade edilmeden diğerinin ima edilmesine neden olur ve denetim kaydı yanlış bir hikaye kaydeder.

Bu aşamanın kuralı, bir şirket engelini birinci sınıf bir şey haline getirmek, bir kullanıcı engelinden ayrı tutmak ve uygulanmasını gelecekteki benin yanlışlıkla yönlendiremediği bir yere koymaktır.

Tek Sütunla, Tek Bir Sınırda Uygulama

Engellenmiş bir şirket, şirketler tablosunda tek bir nullable timestamp’tır:

public function isBlocked(): bool
{
    return $this->company_blocked_at !== null;
}

Bu sütun $fillable içinde yer almaz, böylece hiçbir kiracı aktif olamaz. Ayarlama, yalnızca operatör eylemi ile yapılabilir ve bir politika arkasında yer almaktadır ve hangi nedenlerle neyin askıya alındığına dair bir kayıt oluşturur.

İlginç olan karar, engelin uygulanmasının nereye yerleştirileceğidir. Cazip yanıt, “önemli denetleyicilere if ($company->isBlocked()) kontrolü eklemek” olacaktır. Bu, tam olarak bağışçının dağınık middleware modelinde yeni bir kaplama yapmaktır ve aynı şekilde çürüyecektir: Birisi yeni bir kiracı kapsamlı rota ekler ve kontrolü unutursa, engelin bir açığı olur.

LaraFoundry, her kiracı kapsamlı isteğin geçmesi gereken tek bir yeri zaten sahip: aktif bir şirketi çözen ve gerektiren middleware. Bu, “bu kiracı askıya alındı” durumunun tüm istek için doğru veya yanlış olması gereken tek bir dar boğazdır. Böylece engel orada yaşar. Tek bir sütun, bir sınırda okunur; tüm kiracı burada aşağı çekilir. Bir sonraki rotada unutulacak bir şey yoktur.

Gerçekten Düşünmeyi Gerektiren Kısım

Burada tuzak. Bir kullanıcı, bir şirkete ait değildir. Birini sahip, iki başka şirkette çalışan olabilir ve bunlardan seçili olan aktif bir şirketi vardır. Eğer bir operatör, kullanıcı için aktif olan şirketi askıya alırsa, naif bir uygulama kontrolü en kötü durumu alır: isteği engeller, kullanıcı atılır ve çünkü aktif şirket hala askıya alınmış, sonraki her istek de atılır. Aksi takdirde hiçbir şey yapmamış olan birini etkili bir şekilde oturum kapatıp dışarıda bırakmış olursunuz ve hala çalışabileceği tamamen geçerli şirketleri vardır.

Bu yüzden uygulama bir duvar değil, bir kendini iyileştirme:

protected function handleBlocked(User $user, Request $request): RedirectResponse
{
    // bloklanmamış bir sonraki şirketi öne çıkar, ardından isteği yeniden oynat
    if ($user->setNextAvailableCompany()) {
        return redirect($request->fullUrl());
    }

    // başka düşecek herhangi bir şirket yok: aktif olanı temizle ve askıya alındı ekranını göster
    // çıkış, yeniden yönlendirme döngüsü yok.
    $user->clearActiveCompany();

    return redirect()->route('larafoundry.tenancy.blocked');
}

Eğer kullanıcı engellenmemiş bir başka şirkete sahipse, middleware sessizce onu o şirkete aktarır ve orijinal isteği tekrar oynatır, böylece çalışır durumda olan bir kiracı üzerinde istediği yere ulaşır. Gerçekten gidecek başka bir yer yoksa, aktif şirketi temizler ve “bu şirket askıya alındı” ekranını gösterir. Bunu asla oturum kapatmadan yapar, çünkü çoklu şirket kullanıcısını bir askıya alınmış şirket nedeniyle çıkarmak yanlıştır ve döngü yaratmaz, çünkü geri dönme durumu istikrarlıdır.

“Bir sonraki erişilebilir şirket” ifadesinin engellenmiş olanları atlayacak şekilde ayarlanması bir satırlık ekleme ile yapılır:

$next = $this->companies()
    ->whereNull('company_blocked_at')   // kullanıcıyı ENGELLENMİŞ bir şirkete taşımayın
    ->first();

Ve şirket seçimcisi aynı korumayı alır, böylece bir kullanıcı açılır menüden engellenmiş bir şirketi manuel olarak seçemez.

İnceleme Bu Defa Da Karşılığını Verdi

Bu seride her aşamanın, gönderilmek üzereyken kod incelemesinin bir şeyi yakaladığı bir anı vardır, bu aşamada da iki tane vardı ve her ikisi de tam bu alanda gerçekleşti.

Uygulamanın ilk versiyonu bir yeniden yönlendirme döngüsü içeriyordu: bloklanmış bir şirket isteği güvenli bir rotaya gönderildi, ancak o rota aynı middleware’den geçti, aynı hala bloklanmış aktif şirketi gördü ve yeniden yönlendirdi. Çözüm, yukarıda “kendini iyileştirme” kısmında, aktif şirketi önce değiştirip, bir sonraki geçişin farklı geçerli bir kiracıyı görmesini sağlamaktır.

İkincisi, terfi sorgusuydu. Benim ilk setNextAvailableCompany hemen ilk gelen şirketi terfi ettiriyordu, bu da bloklanmış olanı dahil ediyordu, yani bir operatör bir kiracıyı askıya alırsa, etkilenen kullanıcı otomatik olarak bu engellenmiş şirkete geri geçiyordu. whereNull('company_blocked_at') koşulu küçüktür ve tam anlamıyla önemli olan budur.

Ayrıca inceleme sırasında sıradan ama gerçek bir hatayı da yakaladı: şirket listesi filtreleri ?status[]=x gibi dizi sorgu parametreleri alıyor ve temel filtre, skalar değerler varsayıyordu; bu da 500 hatasına neden oluyordu. Bu örtük bir engellenme ile ilgili değildi, ama düzeltme (herhangi bir skalar olmayan filtre değerini atlamak yerine bağlamamak) aynı zamanda admin kullanıcıları filtrasyonunu da sağlamlaştırdı.

Amaçlı Olarak Okunabilir Hattı

Konsol, her bir şirketin abonelik durumunu gösterir, bu durum küçük ve sabit bir kelime dağarcığına ayrılır: deneme süresinde, aktif, sona ermek üzere, sona ermiş ya da hiç etkinleştirilmemiş. Bir operatör, göz atarak, hangi kiracıların sona ermekte olduğunu hemen görebilir.

Ancak konsolun kasten yapmadığı şey yönetmektir. “Bu aboneliği uzat”, “planı değiştir”, “manuel deneme süresi ver” gibi düğmeler yoktur. Durum, önceden belirlenmiş olan faturalama sütunlarından hesaplanan okunabilir bir bilgi olarak gösterilir ve UI, bunu açıkça metinle belirtir: abonelik yönetimi, faturalama eklentisi içerisinde yer alır.

Bu, iki aşama önce, faturalama biriminin teslim edilmesi sırasında çizdiğim ücretsiz-ücretli hattı takip ediyor. Ücretsiz çekirdek, tamamıyla çoklu kiracı bir operatör konsolu: kiracıları listele, incele, ihtiyaç duyulanları askıya al. İşle ilgili iş, parayı hareket ettirmek ve bir müşterinin neye hak kazanacağını değiştirmek olduğunda, bu ücretli larafoundry-billing eklentisi, ayrı bir pakettir. Durumu göstermek, çekirdeğin zaten sahip olduğu durumu okumaktır. Değiştirmek, ücret talep edeceğim bir üründür. Aynı ekran içerisinde bu hattı koymak, böylece ücretsiz kısım gerçekten kullanışlı ve ücretli kısım gerçekten ayrı olması, çoğu tasarım çalışmasıdır.

Dürüstlük Bölümü

Bu aşama birkaç şey değildir. Şirket ayrıntı görünümü okunabilir: bir kiracıyı inceleyebilirsiniz, ancak operatör panelinden henüz ayrıntılarını düzenleyemezsiniz. Engelleme, backend’de bir nedeni saklar ve denetler, ancak neden yakalama kullanıcı arayüzü minimaldir, rafinelenmiş bir iş akışından uzaktır. Ve platform çapındaki metriklerle admin dairesi kasıtlı olarak ertelendi, çünkü yarıdan fazlası çekirdekte henüz var olmayan modülleri istiyor ve gelir kısmı faturalama eklentisine bağlı. İki gerçek sayı ve “yakında geliyor” ile dolu bir panoya ihtiyaç duymaktansa, dürüst bir ikinci konsol ekranı en iyisidir.

Gönderilen, ekran: paket v0.10.0 etiketinde 398 Pest testi ve 81 Vue testi ile birlikte, güvenlik incelemesi temiz geri döndü ve altı inceleme bulgusu (bunlardan ikisi) regresyon testleri ile düzeltildi.

Tekrar Dizi

Bu serinin tekrar eden dersi, hatanın neredeyse asla özelliğin içinde olmadığını, varsayılan durumun içinde olduğu. Burada özellik kolaydı: bir kiracıyı askıya almak. Düzeltmeye ihtiyaç duyan varsayılan, bağışçınınkiydi, burada bir şirketin bloke edilmesi bir kişinin yasaklanması anlamına geliyordu ve kaçınılması gereken tuzak, yanındaki herkesi kapatacak olan açık uygulama kontrolüydü. Doğru kiracıyı düşürebilen ve arka plandaki katılımcıları sessizce uzaklaştırabilen bir engel, görünüşte yükseklik açısından daha küçük bir farktır ve bir operatör aracı görebileceğiniz güvenilirlik ile destek talepleri üreten bir araç arasındaki farktır.

Takip Et