ASP.NET Core

ASP.NET Core'da rapor ve klasörlere rol tabanlı erişim: kullanıcılar, roller ve admin claim'leri

Dotnet Report'ta çalışan Razi Syed, self-service bir rapor builder'ında yetkilendirmeyi üç katmana ayırıyor: auth cookie'sinden okunan sunucu tarafı kimlik, her rapor ve klasörde veri olarak saklanan erişim alanları ve yalnızca normal kuralları atlayan işlemler için verilen claim'ler. Yaklaşım, kullanıcıların kaynak oluşturup paylaştığı her ASP.NET Core uygulamasına taşınabilir.

Yayın tarihi
Okuma süresi
9 dk okuma
agent çalıştırması #23
agent çalıştırması #23
Orijinale git dev.to

Bu haberi bildir

Özette bir hata mı var, ya da bu içeriğin sahibi misin? Mesajın doğrudan bana e-posta olarak gelir.

Mesaj türü

Kilit noktalar

  • Üç ayrı katman: auth cookie'den gelen kimlik, her rapor ve klasörde veri olarak saklanan izinler ve normal kuralları atlayan işlemler için claim'ler.
  • CurrentUserRole erişim kontrollerinin okuduğu liste; UserRoles ve Users yalnızca paylaşım listelerini doldurur, yetki vermez.
  • Her rapor, klasör ve dashboard virgülle ayrılmış UserId, UserRoles, ViewOnlyUserRoles, DeleteOnlyUserRoles ve ClientId alanları taşır; boş alan o eksende kısıt yok demektir.
  • CallReportApi, user id'si sunucu tarafı kimlikle uyuşmayan istekleri reddeder ve her rapor, klasör ve dashboard id'si için ValidateAccess çağırır.
  • Admin mode ve /dotnetsetup ekranı AllowAdminMode ile AllowSetupPageAccess claim'lerini ister; front-end toggle'ı yok sayılır, admin'e özel metotlar 403 döner.
  • ASP.NET Core Identity'nin security stamp doğrulaması principal'ı yeniden kurup özel claim'leri silebilir; OnValidatePrincipal içinde geri ekleyin.

Raporlarını kaydeden kullanıcılar gelince tek bir IsAdmin bayrağı ya insanları dışarıda bırakır ya herkese anahtar verir. Syed bunu üç katmana ayırıyor. Kimlik, DotNetReportApiController içindeki GetSettings() metodunda sunucu tarafında üretiliyor: tenant ve user id ile ClaimTypes.Role claim'lerinden gelen CurrentUserRole listesi; UserRoles ve Users ise yalnızca paylaşım listelerini dolduruyor. İzinler her rapor, klasör ve dashboard üzerinde veri olarak duruyor: virgülle ayrılmış UserId, UserRoles, ViewOnlyUserRoles ve ClientId alanları; boş alan o eksende kısıt olmadığı anlamına geliyor.

Zorlama sunucuda: CallReportApi, user id'si sunucu tarafı kimlikle uyuşmayan istekleri reddediyor ve rapor, klasör veya dashboard id'leri için ValidateAccess çağırıyor. Admin mode ve kurulum ekranı claim'lere bağlı (AllowAdminMode, AllowSetupPageAccess); front-end'deki toggle dikkate alınmıyor, admin'e özel API metotları 403 dönüyor. Kimliğin boş kalması kontrolü kısa devre yaptırıyor, ayrıca Identity'nin security stamp doğrulaması özel claim'leri düşürebiliyor.

Gerçek dünyada kullanımı

  • Her kiracının finance ekibinin bordro raporunu read-only paylaştığı, şirketin geri kalanının hiç görmediği çok kiracılı bir SaaS.
  • Destek ekibinde birkaç kişinin AllowAdminMode ile başkalarının bozuk raporlarını düzeltip klasörleri düzenlediği bir kurulum.
  • Müşterilerin rapor ürettiği ama hangi tablo ve kolonların açılacağını yalnızca iç ekibin değiştirebildiği bir platform.
  • Yeni raporların varsayılan olarak sadece oluşturan ve Manager rolüyle düzenlenebildiği, paylaşılmadan sızıntı olmayan bir yapı.

Neden önemli

Tüm çağrıları tek bir sunucu tarafı kontrolden geçirmek, tarayıcıdan tahmin edilen bir rapor id'sinin veri yerine hata dönmesi demek; arayüzde gizlemek ise hiçbir koruma sağlamıyor.

Bu özet, DEV Community: #aspnetcore üzerindeki orijinal yazıdan agent tarafından üretildi. Yazının tamamı ve tüm hakları ilgili yazara/yayıncıya aittir. Orijinal yazıya git

Benzer haberler

Geri bildirim

Bir hata mı buldun, bir fikrin mi var? Yazdığın mesaj doğrudan bana e-posta olarak gelir.

Mesaj türü