Laravel'de Multi-Tenant + Multi-Campus: Yazma İşlemlerini Güvenli Hale Getirmek
Okuma işlemlerini test etmek kolay, hangi kullanıcı hangi kampüsün verisini görebilir? Ama yazma işlemleri? Bir veri hangi kampüse kaydediliyor, yanlış kampüse yazılabilir mi? Karobar (Pakistan'daki bir okul yönetim sistemi) bunu zor yoldan öğrendi.
Sistem başında her okul bir tenant'tı (ayrı veritabanı). Sonra okullar "ikinci kampüsümüz de olsun" dedi. Açık çözüm: her kampüs = yeni tenant. Ama bu mantıksız, bir okulun üç kampüsü olsa, ücret toplamı, müfredat, yönetici hepsi dağılır. Bunun yerine kampüs, okulun veritabanında `branches` tablosunun bir satırı oldu. Öğrenciler, öğretmenler, sınıflar, araçlar gibi 15 "kök" tablo `branch_id` taşıyor; geri kalanı üst tablolar aracılığıyla kampüse ulaşıyor.
Okuma işlemleri sıkı tutuldu: sorgu yazarken `where branch_id = X` otomatik eklendi, middleware'de kontrol edildi. Fakat yazma? Bir POST isteğinde, `branch_id` client'tan geliyor. Eğer doğru doğrulamıyorsan, kullanıcı başka kampüsa veri yazabilir. Örneğin bir öğretmen, kendi kampüsünde bir öğrenci oluşturması gerekiyorken, isteğe `branch_id: 5` koyabilir, ve sistem kabul edebilir.
Kritik kurallar: (1) Her yazma işleminde, kullanıcının o kampüse erişim hakkı var mı kontrol et. (2) `branch_id`'yi client'tan almayıp, oturumdan oku. (3) Toplu işlemlerde (update, delete) scope'u her zaman filtrele. (4) Yetkilendirme kurallarını model seviyesinde (Laravel Policy) ve query seviyesinde çift katla. (5) Testlerde sadece "bu veriyi görebilir mi" değil, "bu veriyi yanlış kampüsa yazabilir mi" sorusunu sor.
Laravel'de bu, `belongsTo` ilişkisini doğru kurmak ve `ScopedByBranch` gibi bir trait yazarak otomatikleştirilebilir. Ama en önemli kısım: yazma işlemleri okuma kadar titiz test etmek. Güvenlik boşluğu genellikle en görünür yerde değil, veri oluştururken oluşur.
0 yorum