Sahipliği sunucuda türetin
Kayıt kimliği bir şeyi tanımlar; onu kimin okuyabileceğini kanıtlamaz. supastack, kullanıcıya ait kayıtları workspaceId ile sınırlar. Sunucu, kimliği doğrulanmış kullanıcının çalışma alanını çözer ve bir kaydı okurken ya da değiştirirken bu kapsamı dahil eder.
Tarayıcı tarafından gönderilen bir çalışma alanı kimliğini sahiplik kanıtı olarak değerlendirmeyin. Tarayıcı bir eylem isteyebilir ama güvenilir sunucu bağlamı, bunun kimin eylemi olduğunu belirlemelidir. Bu kural; görev durumu, kayıtlı sağlayıcı yapılandırması, kullanım kayıtları ve ürüne ait her kaynak için geçerli olmalıdır. Yerleşimler ve bileşenler neyin çizileceğini filtreleyebilir ama çizim yetkilendirme değildir — kontrol, kaydın gerçekten okunduğu ya da yazıldığı yerde olmalıdır.
Bu yazıdaki diğer her şey o kuraldan çıkar: sahiplik istenmez, türetilir. İstemciden gelen bir workspaceId herhangi bir yerde güvenilir sayıldığı anda diğer her kontrol süslemeye dönüşür. Kimlik doğrulama yazısı oturumun bu sınırın yukarısında nasıl kurulduğunu anlatır.
Üyelik sınırın parçasıdır
Kapsam, bir kaydın hangi çalışma alanına ait olduğunu yanıtlar; üyelik, bu kullanıcının o çalışma alanına ait olup olmadığını yanıtlar. İkisini de sunucuda çözün. supastack kişisel ve organizasyon çalışma alanlarını sahip, yönetici ve üye rolleriyle modeller — çalışma alanları kılavuzu modeli belgeler.
Roller ikinci bir eksen ekler: üye, yalnızca yöneticinin değiştirebildiğini okuyabilir. İki kontrolü ayrı tutun — “bu çalışma alanına ait” ve “bu eylemi yapabilir” — böylece bir rütbe düşürme ya da çıkarma diğer her şeyle aynı sınırda etki eder. Davetler ve çıkarmalar bir yönetici sonradan düşüncesi değil, aynı yaşam döngüsünün parçasıdır.
Üyelik değişikliklerinin de anında etki etmesi gerekir. Çıkarılmış bir üyenin sonraki isteği, önbelleğe alınmış bir jeton ne zaman süresi dolarsa değil, sınırda başarısız olmalıdır — kontrolün daha önce verilmiş bir kimlik bilgisinin içinde değil, kayıtların okunduğu yerde yaşamasının bir nedeni daha budur.
Kurtarmayı erişim vermeden faydalı kılın
Bir görev URL'si, kullanıcının yenileme sonrası dönmesini sağlar. İşe bir referansı koruduğu için faydalıdır. Kimliği doğrulanmış API, durum ya da sonuç döndürmeden önce istenen görevin mevcut çalışma alanına ait olduğunu yine de doğrulamalıdır.
Aynı ilke gönderim kurtarma için de geçerlidir. Bir idempotency anahtarı, tekrarlanan isteği tanımlamaya ve yinelenen işi önlemeye yardımcı olur. Ne oturumdur ne de erişim anahtarı. Kaydedilmiş bir gönderimi yeniden denemek yine kimlik doğrulama, çalışma alanı sahipliği ve uygun yetkilendirme gerektirir.
Yalıtımın sessizce aşındığı yer kolaylık yollarıdır. Meşru bir kullanıcının işe dönmesine yardım eden bir bağlantı — yenileme sonrası, bir tamamlanma e-postasından — diğer her istekle aynı kimliği doğrulanmış kontrolden geçmelidir. İstekten sonuca hattı tam da bu ilkeyle görev kapsamlı idempotency anahtarları kullanır.
Başarısız olması gereken istekleri test edin
Sahibin bir kaydı almasına izin veren test mutlu yolu kanıtlar. Yalıtımı kanıtlamaz. Aynı kaydı isteyen ikinci bir çalışma alanı, anonim bir istek ve başka bir sahibi yerine koymaya çalışan bir yazmayla eşleştirin.
Kalıcı sonucun yanında dış davranışı da doğrulayın. Reddedilen bir istek başka bir çalışma alanının verisini değiştirmemeli ve hata yanıtı gizli anahtarları ya da ham veritabanı ayrıntılarını sızdırmamalıdır. Bu kontroller, uygulama değiştiğinde sınırı gözden geçirilebilir kılar.
- İkinci bir çalışma alanı aynı kayıt kimliğini ister — reddedilir.
- Anonim bir istek aynı uç noktaya gelir — reddedilir.
- Çalışma alanından çıkarılmış bir üye yeniden dener — reddedilir.
- Bir yazma farklı bir sahip ya da çalışma alanı adlandırır — reddedilir ve hiçbir şey değişmez.
- Hata yanıtları genel kalır — sır yok, şema ayrıntısı yok.
Kuralı ürününüze taşıyın
Yeni bir ürün tablosu eklerken ekranı oluşturmadan önce sahipliğine karar verin. Kalıcılık modeline workspaceId dahil edin, çalışma alanını mevcut sunucu sınırı üzerinden çözün ve bu bağlamı hem liste hem detay işlemlerinde kullanın.
Arka plan işçileri de aynı özeni gerektirir. Kuyruğa alınmış bir görev, doğru kaydı yüklemek için yeterli güvenilir bağlam taşımalı, sağlayıcı kimlik bilgileri ise sunucuda kalmalıdır. Tutarlı bir sahiplik kuralı, rota bazlı istisnalar koleksiyonundan daha kolay bakım yapılabilirdir.
API yüzeyi de aynı sınıra aittir. Çalışma alanı API anahtarları ve imzalı giden webhook'lar çalışma alanının kapsamını beraberinde taşır — bir anahtar asla kiracılar arası okuma yolu olmamalı ve bir webhook yükü asla komşunun kayıtlarını taşımamalıdır. API modülü kılavuzu bu yüzeyin şeklini anlatır.
Çalışma alanı yalıtımı hakkında sık sorulan sorular
Çok kiracılı yalıtım her projede aynı avuç soruyu gündeme getirir. Erken netleştirmeye değer olanlar bunlardır.
- Uygulama düzeyi kapsam yeterli mi, satır düzeyi güvenlik mi gerekir? — Her okuma ve yazmada sunucu tarafından uygulanan kapsam, çoğu SaaS için tehdit modelini karşılar. Veritabanı RLS'i derin savunma ekler ama sınır kontrollerinin yerini almaz — işçiler ve API anahtarları hâlâ aynı kurala ihtiyaç duyar.
- Çalışma alanları arası paylaşım nasıl çalışmalı? — Kapsamı zayıflatmak yerine açıkça modelleyin — bir davet, bir üyelik satırı. “Bağlantıya sahip olan herkes” bir kaza değil, kendi kontrolleri olan tasarlanmış bir özellik olmalıdır.
- Çok kiracılı uygulamalarda önce ne bozulur? — Kolaylık yolları: kurtarma bağlantıları, yönetici araçları, kayıtları çıplak kimlikle yükleyen arka plan işçileri. Normal kapsamdan geçmeden bir kayda dokunan her kod yolunu denetleyin.
- Var olan bir tabloya kapsam nasıl eklerim? —
workspaceIdekleyin, geriye dönük doldurun, okuma ve yazmalarda uygulayın, sonra UI'a dokunun. Sınır varsayılmış değil kanıtlanmış olsun diye olumsuz testleri önce çıkarın. - Sayfa korunuyorsa sunucu eylemlerinin kontrole ihtiyacı var mı? — Evet. Sayfa korumaları ekranları gizler; işlemleri yetkilendirmez. Her eylem oturumu ve çalışma alanını bağımsız çözer.