Haberler ve analiz
Birden fazla şirket için portal: giriş yapmak veri erişimini belirlemez
Auth0, Neon ve GitLab üç yalıtım katmanını gösteriyor: kuruluş bağlamı, depolama sınırları ve uygulama içindeki izin kontrolleri.
Çalışan giriş yaptı ama hangi şirket adına hareket ediyor? Doğrudan bağlantıyla başka şirketin siparişini açabilir mi? B2B ürün büyürken bu sorular ayrıntılı SSO yapılandırmasından önce gelir. Yeni Auth0 ve GitLab yayınları, eylül tarihli Neon mimari yazısıyla birlikte kararın üç katmanını ayırmaya yardım eder.
Kuruluş bağlamını belirleyin
9 Ekim'de Auth0 Organizations'ı anlattı: üyelik, kimlik sağlayıcı bağlantıları, metaveri ve kuruluş kapsamlı roller. FlowGrid ve Acme örnekleri açıkça kurgusaldır. Müşteri uygulaması veya sonuç göstermeden senaryoyu açıklar.
Kendi portalınızda her kaydın sahibi kuruluşu belirleyin. Bir kişi farklı haklarla birçok şirkette çalışabilir. Seçilen kuruluş bu nedenle başlıktaki ad olarak kalmak yerine eyleme eşlik etmelidir. Bir şirkette sipariş okuma izni, her şirketin siparişini düzenleme iznine dönüşmemelidir.
Depolamayı ayırmak başka katmanı ele alır
14 Eylül LuBot mimarisi anlatımında Neon, ortak hesaplar ve Supabase faturalamasıyla her kiracıya ayrı veritabanı açıklar. Bu karşılaştırmanın önceki arka planıdır; ekim duyurusu değildir.
Ayrı veritabanları açık depolama sınırı kurabilir, fakat kullanılacak veritabanını hâlâ uygulama seçer. Yönlendirme hatası veya aşırı yönetici erişimi, depolama ayrıldı diye kaybolmaz. Kararı bakım, kurtarma ve müşteri hesabı yönetimi gereksinimleriyle birlikte verin.
Müşteri portalında şirket ayrımının kavramsal AI görseli.
Kimlik doğrulamadan sonra yetkiyi kontrol edin
5 Ekim'de GitLab iki kitleye hizmet vermeye başlayan iç Django uygulamasını tartıştı. Yalnızca login_required, ayrı modüllere erişimi sınırlamak için yeterli değildi. Menü öğesini gizlemek de sunucu tarafı yetkilendirmenin yerini almaz.
Birlikte bu yazılar pratik kabul koşulu önerir: sistem kullanıcıyı, aktif kuruluşu ve somut eylemin iznini bilir. Bu olgular seçilen veriyi tutarlı belirlemelidir. Kimlik sağlayıcı, veritabanı tasarımı ve uygulama kodu farklı katmanlarda çalışır; hiçbiri diğerinin yerine geçmez.
Kabul testi için iki örnek şirket ve her birinde farklı rolü olan kullanıcı oluşturun. Başka şirketin kaydına doğrudan URL'yi deneyin, API isteğinde kimliği değiştirin, şirket bağlamını değiştirin ve önceden kuyruğa alınmış işi yürütün. Sonra kullanıcının erişimini kaldırıp eylemleri yineleyin. Açık ret dâhil beklenen sonucu önceden kararlaştırın.
İş kuralları ve izinler rehberimiz kontrolleri çerçevelemeye yardım eder. Arşiv API tasarımı bu yeni ürünlerin benimsenmesini değil erişim modellerini tartışır. Müşteri portalı geliştirirken başka entegrasyon eklemeden kuruluşları, rolleri ve veri sınırlarını konuşun.