Ne demek, “Kullanıcı Yönetici olup olmadığına karar vermemelidir. Ayrıcalıklar veya Güvenlik sistemi gerekir. ”

Soruda kullanılan örnek , kullanıcının yönetici olup olmadığını belirlemek için en iyi şekilde dokunan bir işleve çıplak veri iletmektedir. Yaygın cevaplardan biri şuydu:

user.isAdmin()

Bu, birkaç kez tekrarlanan ve birçok kez oylanan bir yorum yapılmasına yol açtı:

Bir kullanıcı bir Yönetici olup olmadığına karar vermemelidir. Ayrıcalıklar veya Güvenlik sistemi gerekir. Bir sınıfa sıkıca bağlı olan bir şey, onu sınıfın bir parçası yapmanın iyi bir fikir olduğu anlamına gelmez.

Yanıtladım,

Kullanıcı hiçbir şeye karar vermiyor. Kullanıcı nesnesi / tablosu her kullanıcı hakkında veri depolar. Gerçek kullanıcılar kendileriyle ilgili her şeyi değiştiremezler.

Ancak bu üretken değildi. Açıkça, iletişimi zorlaştıran temel bir perspektif farkı var. Birisi bana neden user.isAdmin () 'in kötü olduğunu anlatabilir ve "doğru" gibi göründüğünün kısa bir taslağını çizebilir mi?

Gerçekten, güvenliği koruduğu sistemden ayırmanın avantajını göremiyorum. Herhangi bir güvenlik metni, güvenliğin başlangıcından itibaren bir sistemde tasarlanması ve geliştirme, dağıtım, bakım ve hatta yaşamın her aşamasında göz önünde bulundurulması gerektiğini söyleyecektir. Yana takılabilen bir şey değildir. Ancak bu yorumda şu ana kadar 17 oy daha var önemli bir şeyi kaçırdığımı söylüyor.

Kullanıcı'yı bir anahtar olarak ve izinleri bir değer olarak düşünün.

Farklı bağlamlar, her kullanıcı için farklı izinlere sahip olabilir. İzinler içeriğe bağlı olduğundan, her bağlam için kullanıcıyı değiştirmeniz gerekir. Bu nedenle, bu mantığı başka bir yere (örneğin bağlam sınıfı) koymanız ve gereken izinlere bakmanız daha iyi.

Bunun bir yan etkisi sisteminizi daha güvenli hale getirmesidir, çünkü ilgili olmayan yerler için yönetici bayrağını temizlemeyi unutamazsınız.

Bu yorum kötü bir şekilde ifade edildi.

Mesele, kullanıcı nesnesinin bir yönetici mi, deneme kullanıcısı mı, süper kullanıcı mı olduğu veya sıradan veya dışında herhangi bir şey olup olmadığına "karar vermesi" değil . Açıkçası, bunlardan hiçbirine karar vermiyor, sizin tarafınızdan uygulandığı gibi, genel olarak yazılım sistemi karar veriyor. Nokta "kullanıcı" olup olmadığıdır sınıf gerektiğini temsil onun nesneleri temsil anapara rollerini veya bu olsun başka bir sınıfın bir sorumluluktur.

Özgün yorumu, anlatıldığı şekilde söylemeyi seçmezdim, ancak potansiyel olarak meşru bir sorunu tespit ediyor .

Spesifik olarak, ayırma emrinin onaylanma ve yetkilendirme olduğu endişeleridir .

Kimlik doğrulama , giriş yapma ve kimlik alma işlemini ifade eder. Sistemler sizin kim olduğunuzu bilir ve kişiselleştirme, nesne mülkiyeti, vb. Gibi şeylerde kullanılır.

Yetkilendirme atıfta yapmanız izin ne ve bu (genellikle) olan değil tarafından belirlenen Kim . Bunun yerine, adınız veya e-posta adresiniz gibi şeylerle ilgilenmeyen roller veya izinler gibi bazı güvenlik politikaları tarafından belirlenir.

Bu ikisi birbirine dik olarak değişebilir. Örneğin, kimlik doğrulama modelini OpenID / OpenAuth sağlayıcılarını ekleyerek değiştirebilirsiniz. Güvenlik politikasını yeni bir rol ekleyerek veya RBAC'den ABAC'ye değiştirerek değiştirebilirsiniz.

Bunların hepsi bir sınıfa veya soyutlamaya girerse, risk azaltma için en önemli araçlarınızdan biri olan güvenlik kodunuz ironik bir şekilde yüksek riskli olur.

Kimlik doğrulama ve yetkilendirmenin çok sıkı bağlandığı sistemler ile çalıştım. Bir sistemde, her biri bir tür "rol" için iki paralel kullanıcı veritabanı vardı. Görünüşe göre, onu tasarlayan kişi veya ekip, tek bir fiziksel kullanıcının her iki rolde olabileceğini veya birden fazla rolde ortak olan bazı eylemler olabileceğini veya Kullanıcı Kimliği çarpışmalarında sorun olabileceğini düşünmemiştir. Bu kuşkusuz aşırı bir örnek, ancak çalışmak için inanılmaz derecede acı vericiydi.

Microsoft ve Sun / Oracle (Java) , Güvenlik Sorumlusu olarak kimlik doğrulama ve yetkilendirme bilgilerinin toplamını ifade eder . Mükemmel değil, ama oldukça iyi çalışıyor. .NET, örneğin, sahip , hangi kapsüller - Eski bir varlık politikası (yetki) nesne ikincisi bir iken kimlik (doğrulama). Birini diğerinin içine koyma kararını makul bir şekilde sorgulayabilirsiniz , ancak önemli olan, yazdığınız çoğu kodun soyutlamalardan yalnızca biri için olacağıdır ; bu, test edilmesi ve yeniden yapılandırmanın kolay olduğu anlamına gelir.IPrincipalIIdentity

Bir User.IsAdminalanla ilgili yanlış olan bir şey yok ... aynı zamanda bir alan olmadığı süreceUser.Name . Bu, "Kullanıcı" kavramının doğru tanımlanmadığını ve ne yazık ki, güvenlik söz konusu olduğunda kulakların arkasında biraz ıslanan geliştiriciler arasında çok yaygın bir hata olduğunu gösterecektir. Tipik olarak, kimlik ve politika ile paylaşılması gereken tek şey, tesadüfen değil, hem Windows hem de * nix güvenlik modellerinde tam olarak nasıl uygulandığı olan Kullanıcı Kimliğidir.

Hem kimliği hem de politikayı içine alan sarıcı nesneler oluşturmak tamamen kabul edilebilir. Örneğin, mevcut kullanıcının erişmesine izin verilen çeşitli widget'lara veya bağlantılara ek olarak "merhaba" mesajı görüntülemeniz gereken bir gösterge paneli ekranı oluşturulmasını kolaylaştıracaktır. Bu sarmalayıcı yalnızca kimlik ve politika bilgilerini tamamladığı ve kendisine ait olduğunu iddia etmediği sürece. Başka bir deyişle, toplu bir kök olarak sunulmadığı sürece .

Basit bir güvenlik modeli , yeni bir uygulama tasarlarken, YAGNI ve diğer şeylerden ötürü her zaman iyi bir fikir gibi gözükse de, neredeyse her zaman sizi daha sonra ısırmaya başlıyor, çünkü sürpriz sürpriz, yeni özellikler eklendi!

Bu nedenle, sizin için neyin en iyisini biliyorsanız, kimlik doğrulama ve yetkilendirme bilgilerini ayrı tutabilirsiniz. Şu anda "yetkilendirme", "IsAdmin" bayrağı kadar basit olsa bile, kimlik doğrulama bilgileriyle aynı sınıf veya tablonun bir parçası değilse, güvenlik politikanızın ne zaman ve ne zaman yapması gerekiyorsa, yine de daha iyi olursunuz. değiştir, zaten iyi çalışan kimlik doğrulama sistemlerinizde rekonstrüktif cerrahi yapmanız gerekmez.

En azından tek sorumluluk ilkesini ihlal ediyor . Değişiklikler olmalı mı (birden fazla yönetici seviyesi, hatta daha farklı roller?) Bu tür bir tasarım oldukça dağınık ve sürdürülmesi berbat olurdu.

Her ikisinin de tek ve iyi tanımlanmış bir rolü olabilmesi için güvenlik sistemini kullanıcı sınıfından ayırmanın avantajını düşünün. Genel olarak tasarımı korumak için daha temiz, daha kolay bir iş çıkar.

Bence, belki de yetersiz ifade edilen meselenin Usersınıfa çok fazla ağırlık vermesi olduğunu düşünüyorum . Hayır, User.isAdmin()bu yorumlarda önerildiği gibi bir yönteme sahip bir güvenlik sorunu yoktur . Sonuçta, birisi temel sınıflarınızdan birine kötü niyetli kodlar sokmak için kodunuzda yeterince derinse, ciddi sorunlarınız var. Öte yandan, Userher bağlam için yönetici olup olmadığına karar vermek mantıklı değildir . Farklı roller eklediğinizi düşünün: forumunuz için moderatörler, ön sayfada yayınlar yayınlayan editörler, editörlerin yayınlaması için içerik yazabilen yazarlar vb. UserNesneye koyma yaklaşımıyla User, sınıfla doğrudan ilgili olmayan çok fazla yöntem ve üzerinde yaşayan bir çok mantıkla karşılaşacaksınız .

Bunun yerine, farklı türde izinleri ve bir PermissionsManagersınıfı kullanabilirsiniz. Belki de PermissionsManager.userHasPermission(User, Permission)bir boole değeri döndürmek gibi bir yönteme sahip olabilirsin . Uygulamada, (java'da) gibi görünebilir:

if (!PermissionsManager.userHasPermission(user, Permissions.EDITOR)) {
  Site.renderSecurityRejectionPage();
}

Esasen before_filter, gerçek dünyada bu tür izin denetimlerinin bir örneğini sunan Rails yöntemi yöntemine eşdeğerdir .

Object.isX (), nesne ile X arasında, bir boole sonucu olarak ifade edilebilecek açık bir ilişkiyi göstermek için kullanılır, örneğin:

Water.isBoiling ()

Circuit.isOpen ()

User.isAdmin () , sistemin her bağlamında, bir kullanıcının sistemin her bölümünde bir yönetici olduğunu tek bir 'Yönetici' anlamı olduğunu varsayar .

Yeterince basit gibi görünse de, gerçek bir dünya programı bu modele neredeyse hiç uymayacak, kesinlikle bir kullanıcının [X] kaynağını yönetmesi ancak [Y] değil, daha farklı yönetici türleri için bir gereksinim olacaktır. ] yönetici vs [sistem] yönetici).

Bu durum genellikle ihtiyaçların araştırılmasını gerektirir. Nadiren, eğer bir müşteri, User.isAdmin () in gerçekten temsil ettiği ilişkiyi ister, bu yüzden herhangi bir çözümü açıklığa kavuşturmaktan çekinmeyeceğim.

Poster sadece farklı ve daha karmaşık bir tasarıma sahipti. Bence User.isAdmin()iyi . Daha sonra bazı karmaşık izinler modelini tanıtsanız bile, taşınması için çok az sebep görüyorum User.isAdmin(). Daha sonra, Kullanıcı sınıfını giriş yapmış bir kullanıcıyı temsil eden bir nesneye ve kullanıcı hakkındaki verileri temsil eden statik bir nesneye bölmek isteyebilirsiniz. Ya da olmayabilir. Yarın için yarını kurtar.

Gerçekten bir sorun değil ...

Ben bir problem görmüyorum User.isAdmin(). Kesinlikle PermissionManager.userHasPermission(user, permissions.ADMIN), SRP'nin kutsal adına kodu daha az net hale getiren ve değerli bir şey eklemeyen bir şeye tercih ediyorum .

Bence SRP, bazıları için kelimenin tam anlamıyla biraz yorumlanıyor. Bence bir sınıfın zengin bir arayüze sahip olması tercih edilir. SRP, bir nesnenin ortak sorumluluğuna girmeyen her şeyi ortak çalışanlara devretmesi gerektiği anlamına gelir. Bir kullanıcının yönetici rolü bir boolean alandan daha fazla ilgiliyse, kullanıcı nesnesinin PermissionsManager'a devredilmesi çok mantıklı olabilir. Ancak bu, bir kullanıcının isAdminyöntemini korumasının da iyi bir fikir olmadığı anlamına gelmez . Aslında, uygulamanız basitten karmaşığa geçiş yaptığında, Kullanıcı nesnesini kullanan kodu değiştirmek istediğiniz anlamına gelir. Şimdi, müşterinizin bir kullanıcının yönetici olup olmadığı sorusunu cevaplamanın gerçekte ne olduğunu bilmesine gerek yok.

... ama neden gerçekten bilmek istiyorsun?

Bununla birlikte, Bana bir kullanıcının belirli bir işlemi gerçekleştirmesine izin verilip verilmeyeceği gibi bir kullanıcının belirli bir işlemi gerçekleştirmesine izin verilip verilmeyeceği gibi bir kullanıcının bir yönetici olup olmadığını nadiren bilmeniz gerektiği gibi görünüyor. Bu durumda, Widget'taki gibi bir yöntem kullanmayı tercih ederim isUpdatableBy(User user):

boolean isUpdatableBy(User user) {
    return user.isAdmin();
}

Bu şekilde, bir Widget bir kullanıcı tarafından güncellenmesi için hangi kriterlerin yerine getirilmesi gerektiğini bilmekle sorumludur ve kullanıcı bir yönetici olup olmadığını bilmekle sorumludur. Bu tasarım niyetleri hakkında net bir şekilde iletişim kurar ve zamanı geldiğinde daha karmaşık iş mantığına geçmeyi kolaylaştırır.

[Düzenle]

Sorunu değil sahip olan User.isAdmin()ve kullanılmasıPermissionManager.userHasPermission(...)

Bir kullanıcının yönetici olup olmadığını (veya yönetici rolü olup olmadığını) bilmek istediğimde, neden Kullanıcı nesnesine bir yöntemi PermissionManager nesnesinde bir yöntemi çağırmaya tercih etmeyi tercih ettiğimi açıklamak için cevabımı ekleyeceğimi düşündüm.

Bence , bu kullanıcının bir yönetici olduğu sorusunu sormak istediğiniz yerde her zaman Kullanıcı sınıfına bağlı kalacağınızı varsaymak adil olur. Kurtulmayacağın bir bağımlılık. Ancak, kullanıcı hakkında soru sormak için kullanıcıyı farklı bir nesneye aktarmanız gerekirse, bu, Kullanıcıya zaten sahip olduğunuz nesnenin üstüne o nesneye yeni bir bağımlılık yaratır. Eğer soru çok sorulursa, fazladan bir bağımlılık yarattığınız çok fazla yer var, ve eğer bağımlılıktan herhangi biri talep ederse değiştirmek zorunda kalabileceğiniz çok fazla yer var.

Bunu bağımlılığı User sınıfına taşıyarak karşılaştırın. Şimdi, aniden, müşteri kodunun (soruyu sorması gereken kodun bu yönetici olduğu şeklinde ), bu sorunun nasıl yanıtlandığının uygulanmasına bağlanmadığı bir sisteme sahipsiniz . İzin sistemini tamamen değiştirmekte özgürsünüz ve bunu yapmak için yalnızca bir sınıftaki bir yöntemi güncellemeniz gerekiyor. Tüm müşteri kodu aynı kalır.

isAdminKullanıcı sınıfında izinler alt sistemine bağımlılık yaratma korkusuyla ilgili bir yönteme sahip olmamak konusunda ısrar etmek, bir kuruş kazanmak için bir dolar harcamak gibi bir şeydir. Elbette, Kullanıcı sınıfında bir bağımlılıktan kaçınırsınız, ancak soruyu sormanız gereken her yerde bir tane yaratmanın maliyeti vardır. İyi bir pazarlık değil.

Bu tartışma bana sınıf tasarımı, güvenlik ve doğruluk hakkında benzer bir tartışmada dikkatimi çeken Eric Lippert'in Blog Post'u hatırlattı.

Neden bu kadar çok Sınıf Sınıfı Mühürlendi?

Özellikle, Eric nokta yükseltir:

4) Güvenli. Polimorfizmin tüm amacı, hayvanlara benzeyen fakat aslında zürafalar olan nesnelerin etrafından geçebileceğinizdir. Burada potansiyel güvenlik sorunları var.

Mühürsüz bir türün örneğini alan bir yöntemi her uyguladığınızda, bu türün potansiyel olarak düşmanca örnekleri karşısında sağlam olacak şekilde yazmalısınız. SİZİN uygulamalarınız için doğru olduğunu bildiğiniz herhangi bir değişmeze güvenemezsiniz, çünkü bazı düşmanca web sayfaları uygulamanızı alt sınıflandırabilir, mantığınızı bozan şeyler yapmak için sanal yöntemleri geçersiz kılabilir ve onu geçebilir. , O sınıfı kullanan yöntemleri, o sınıfın ne yaptığını bildiğimden emin olarak yazabilirim.

Bu teğet gözükebilir, ancak sanırım diğer posterlerin SOLID tek sorumluluk ilkesiyle ilgili ortaya koydukları nokta ile uyuşmuyor . Bir User.IsAdminyöntemi veya özelliği uygulamamak için bir neden olarak aşağıdaki kötü amaçlı sınıfı düşünün .

public class MyUser : User
{

    public new boolean IsAdmin()
    {
        // You know it!
        return true;
    }

    // Anything else we can break today?

}

Tabii ki, bu bir gerginlik: kimse henüz IsAmdminsanal bir yöntem yapmayı önermedi, ancak kullanıcı / rol mimariniz tuhaf bir şekilde karmaşık hale geldiyse olabilir. (Ya da belki değil. Bir düşünün public class Admin : User { ... }: böyle bir sınıfın içinde yukarıdaki kodun aynısı olabilir.) Kötü niyetli bir ikili kodun yerine yerleştirilmesi yaygın bir saldırı vektörü değildir ve kaos için belirsiz bir kullanıcı kitaplığından çok daha fazla potansiyele sahiptir - o zaman yine, Gerçek shenaniganların kapısını açan Ayrıcalıklı Eskalasyon hatası olabilir . Son olarak, kötü niyetli bir ikili dosya veya nesne örneği çalışma zamanına girdiğinde, "Ayrıcalık veya Güvenlik Sisteminin" benzer bir şekilde değiştirildiğini hayal etmek çok da zor olmaz.

Fakat Eric'in dikkatini çektiğinizde, kullanıcı kodunuzu belirli bir hassas sisteme koyarsanız, belki de oyunu kaybedersiniz.

Oh, ve sadece kayıt için kesin olmak gerekirse, şu soruyu kabul ediyorum: “Bir kullanıcı bir Yönetici olup olmadığına karar vermemelidir. Ayrıcalıklar veya Güvenlik sistemi gerekir. ” User.IsAdminKod, sistem üzerinde çalışıyorsa, kodun% 100 kontrolünde kalmamanız için bir yöntem kötü bir fikirdir - bunun yerine yapmalısınız Permissions.IsAdmin(User user).

Buradaki sorun şudur:

if (user.isAdmin()) {
   doPriviledgedOp();
} else {
   // maybe we can anyway!
   doPriviledgedOp();
}

Güvenliğinizi uygun şekilde kurdunuz ya da bu durumda ayrıcalıklı yöntem arayan kişinin yetkisine sahip olup olmadığını kontrol etmelidir - bu durumda kontrol gereksizdir. Ya da güvenlik konusunda kendi kararlarını vermesi için ayrıcalıklı olmayan bir sınıfa güvenmiyorsunuz ve güveniyorsunuz.