Bir görüşte güvenlik koşullarının kullanılması MVC'nin ihlali midir?


10

Genellikle bir kullanıcıya (örneğin bir web sayfasında) gösterilenler kısmen güvenlik kontrollerine dayanır. Genellikle kullanıcı düzeyi / ACL güvenliğinin bir sistemin iş mantığının bir parçası olduğunu düşünüyorum. Bir görünüm, UI öğelerini koşullu olarak görüntülemek için güvenliği açıkça kontrol ederse, iş mantığını içererek MVC'yi ihlal ediyor mu?


Alternatif ne olurdu?

1
Bazıları tarafından bir anti-desen olarak kabul edilse bile, size en iyi güvenliği sağlayan şeyi kullanırsınız .
zxcdw

Yanıtlar:


6

Biri modelde diğeri görünümde olmak üzere iki tür güvenlik koşulu olabilir. Görünüm, geçerli kullanıcının izinlerine bağlı olarak ilgili öğelerin görüntülenmesini kontrol eder, ancak model temel verilere erişimi kontrol eder. Model doğru doğrulamalara / doğrulamalara sahip olduğu sürece, görünüm eksik olsa bile, hala güvenlik vardır.

Görünümün farklı seviyeler / roller için değişmesi gerektiğinden, genellikle her ikisine de sahip olmanız gerekir. Denetleyici, görünümü değiştirecek ilgili verileri gönderir, ancak görünümün içeriği doğru kullanıcıya gizlemek / görüntülemek için bu verilerle bir şeyler yapması gerekir.

Bu nedenle, şablonların çoğunun koşullu öğeleri vardır ( Gidon örneği):

{{#if isCurrentUserAdmin}}
    ....
{{/if}

Bu, uygun parçalar doğru yerde olduğu sürece bunun bir ihlal olmadığı anlamına gelir.


4

Evet ve hayır.

Gerçek güvenlik kararı görünüm tarafından alınırsa, evet, MVC'yi ihlal ediyorsunuz. Ancak, görünüm gerçek kararı modele devrediyorsa, sorun değil demektir. Modeldeki bilgilere dayanarak, hangi öğelerin gösterileceğine karar vermek konusunda yanlış bir şey yoktur.

Örneğin, yalnızca "düzenleyici" izinleri olan kullanıcılar tarafından görülebilen bir "düzenle" düğmeniz varsa, görünümün modele geçerli kullanıcının kim olduğunu ve "düzenleyici" iznine sahip olup olmadığını sorması iyidir, düğmenin gösterilip gösterilmeyeceğine karar vermek için bu bilgileri kullanın. Ancak, görünüm kimlik doğrulama ve yetkilendirme mantığının kendisini yapmak olsaydı, MVC'yi ihlal edersiniz.


2

Hayır derdim .

Ama @ rvcoutinho'nun söylediğinden farklı bir nedenden dolayı (wikipedia'dan bahsediyor olsa da, bu da benim düşüncemde yanlış hissettiriyor)

Güvenlikle ilgili herhangi bir endişenin, görünüm için verilen Model tarafından paylaşılması gerektiğini söyleyebilirim (bu nedenle bir ViewModel kullanmak isteyebileceğiniz kombinasyon sayısına bağlı olarak), böylece güvenlik bitleri için anahtarlarınız olabilir.

Bu, iki katmanlı güvenlik doğrulamasına izin verir: UI katmanında, normal durum için bir geri gönderme ve ayrıca modelin kendi içindeki güvenlik bilgisini koruduğu kötü aktörler için sunucu katmanında altüst edilmek üzere denetleyicinin hemen fırlatan model.

Bunun gibi iki katmanlı güvenlik endüstride standarttır ve bu şekilde güvenlik mantığınızın sadece iki yerde bulunması gerekir, bu yüzden bir mantık, kontrol cihazınıza güvenlik mantığını koyar koymaz, oraya koyarsınız ve Kullanıcı arayüzü ve modelde (model, son savunma hattı olduğundan ve özellikle masaüstü istemcisi veya herhangi bir sunucu yönetim aracı gibi MVC web uygulamasının dışındaki tüm kullanımlar için önemlidir)


Wikipedia'nın "Bir denetleyicinin, görünümün modelin sunumunu değiştirmek için ilişkili görünümüne komutlar gönderebileceği" iddiası Model-View-Presenter için daha uygun görünüyor , çünkü ifadenin açıkladığı etkileşimli model orada mümkünken, MVC'de bir kez Görünüm oluşturulur, Görünüm ile Denetleyici arasında başka bir işlem yapılmaz.
Robert Harvey

1
@RobertHarvey İfadenin MVC tanımımla uyuşmadığına katılıyorum, ancak şanslıyız, doğruluğun herhangi bir olasılıktan ziyade birçok anlaşmayla kararlaştırıldığı bir endüstride çalışıyoruz, çünkü bu tanımlar sadece herkesin kendi paketlerini yapmalarını sağlayan sürekli gelişen bir temel. Ya da daha açık bir ifadeyle, muhtemelen buradaki herkes kadar yanılıyorum.
Jimmy Hoffa

3
Bu yüzden insanların bu tür şeyler hakkında çok bilgiç olduklarını düşünüyorum.
Robert Harvey

1
@rvcoutinho Hiç değişmez olduğunu söylemezdim; yanınızda referanslar var, sahip olduğum tek şey benim düşüncem, bu yüzden aklımda bu muhtemelen yanlış olduğum anlamına geliyor, bu yüzden bahsetmiştim. Benim fikrim, referansım olmasa bile paylaşmaya değer olacak kadar makul olduğunu düşünüyorum, bu yüzden söylediğim gibi, muhtemelen yanlış olduğumdan bağımsız olarak, yine de yaptım.
Jimmy Hoffa

1
@rvcoutinho: Aslında OP'nin sorusundan bahsediyordum. :) Kurallar bir şeylerin yapılmasını engellemediği sürece kurallarda yanlış bir şey yoktur.
Robert Harvey

2

Hayır derdim .

Genellikle, bu tür güvenlik kontrolleri kontrolör tarafından yapılacaktır.

Wikipedia'dan gelince :

Bir denetleyici, görünümün model sunumunu değiştirmek için ilişkili görünümüne komutlar gönderebilir

Ve doğrudan görüşte yapılması gerektiğini düşünmüyorum. Örneğin, javascript yoluyla yapılırsa, bu bir güvenlik sorunu olabilir (javascript devre dışı bırakılabilir ve ayrıcalıklı verilere erişilebilir).

Yine Wikipedia'dan :

Bir görünüm modelden bir çıktı gösterimi oluşturmak için ihtiyaç duyduğu bilgileri ister .


1
Birçok yazılım sisteminde, bir öğenin görüntülenmesi kullanıcının güvenlik düzeyine bağlıdır. Görünüm Modeli'nde bir veri öğesinin sıfır veya null değerine ayarlanarak görüntülenmesini engelleyebilirsiniz, ancak veri öğesinin adı veya açıklaması görüntülenmeye devam eder. Veri öğesi açıklamasının (pratik bir şekilde) görüntülenmesini engelleyebileceğiniz tek yer Görünüm'dedir.
Robert Harvey

Katılıyorum. Görünümün verileri talep edeceğini, kontrolörün modeli manipüle edeceğini ve görünümün yine onu temsil edeceğini söyleyebilirim. Görünüm, yalnızca çıktının temsilinden sorumlu olmalıdır.
rvcoutinho

Bu nedenle, Görünüm'ün kullanıcının görmesi gerekmeyen görsel öğeleri gizlemesi gerekir. Denetleyici verilerin görsel sunumunu oluşturmaktan sorumlu değildir; Görünüm. Elbette, görüntülediğiniz şey Görünüm / Kaynakta bile olamayacak kadar hassassa, denetleyicinin yapması gereken farklı bir görünüm döndürmektir .
Robert Harvey

1
Demek istediğim bu. Görünüm farklı olmalıdır. Anladığım kadarıyla, görünüm sadece verilerin temsiline dikkat etmelidir. Temsil ile, bir şeyi nasıl göstereceğimi kastediyorum, ne zaman gösterileceğini değil. Yine de yorumlarınız tamamen alakalı.
rvcoutinho

Sanırım aynı ifadeyi iki farklı şey için kullanıyor olabiliriz. Zaten farklı bir görüş nedir? Ancak bence en önemli konu üzerinde hemfikiriz: eğer güvenliğe duyarlıysa, görüş tarafından ele alınmamalıdır.
rvcoutinho

1

Bu soruya dahil olan birkaç sorun var.

  1. Doğrulama gerektiğini (söylediği bu kullanıcı) değil View bir endişe.
  2. Yetkilendirme (yapmasına izin Geçerli kullanıcı mı bu ) olduğunu kullanıcıya sunulan Nelerin etkileyebilir çünkü View bir endişe. Böylece, bir düzenleme düğmesi görüntüleme kodu koşullu bir şekilde çevrilebilir if model.userCanEdit() ... endif.
  3. Bir kullanıcının hangi yetkilendirme özelliklerine, yani iş mantığına ve Modele yerleştirilmesi gerektiğinin belirlenmesi. (Örneğin, 'düzenle' ayrıcalığının 2000 itibarına sahip olması veya yazar ya da moderatör olmanız gerekir)

0

Sadece UI öğesini görüntülemekle ilgili ise bence sorun yok (yine de başka nasıl yapardınız?). Bu elemanlarda herhangi bir veri varsa, model kapların boş olduğundan emin olmalıdır. Ve elbette izin verisini almak için kodun görünümden önce ele alınmış olması gerekir, bu nedenle burada modele aktif erişim yoktur.


0

Bir görünüm, UI öğelerini koşullu olarak görüntülemek için güvenliği açıkça kontrol ederse, iş mantığını içererek MVC'yi ihlal ediyor mu?

Evet, MVC'nin ihlalidir.

Görünüm yalnızca öğeleri görüntülemek için oradadır ve mantık modelde olmalıdır. Görünümün bir şey yapmasını sağlayarak (sizin durumunuzda güvenliği kontrol edin), mantığı oraya yerleştirirsiniz.


O halde görünüm, düzenleme düğmesi gibi bir şeyin görüntülenip görüntülenmeyeceğini nasıl bilebilir?
Matt S

@MattS Sunucu, görünümü görüntülemek veya gizlemek için bir işlev çağırır (modeldeki bir duruma bağlı olarak).
BЈовић
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.