क्या सुरक्षा स्थितियों का उपयोग MVC का उल्लंघन है?


10

अक्सर उपयोगकर्ता को जो दिखाया जाता है (जैसे वेब पेज पर) आंशिक रूप से सुरक्षा जांच पर आधारित होगा। मैं आमतौर पर उपयोगकर्ता-स्तर / एसीएल सुरक्षा को एक प्रणाली के व्यावसायिक तर्क का हिस्सा मानता हूं। अगर कोई दृश्य यूआई तत्वों को सशर्त रूप से प्रदर्शित करने के लिए सुरक्षा की स्पष्ट रूप से जांच करता है, तो क्या यह व्यावसायिक तर्क युक्त एमवीसी का उल्लंघन कर रहा है?


क्या विकल्प होगा?

1
आप इसका उपयोग करते हैं जो आपको सबसे अच्छी सुरक्षा देता है, भले ही इसे कुछ द्वारा एक विरोधी पैटर्न माना जाता है ।
zxcdw

जवाबों:


6

सुरक्षा के दो प्रकार हो सकते हैं, एक मॉडल पर और दूसरा दृश्य पर। दृश्य वर्तमान उपयोगकर्ता की अनुमति के आधार पर प्रासंगिक तत्वों के प्रदर्शन को नियंत्रित करता है, लेकिन मॉडल अंतर्निहित डेटा तक पहुंच को नियंत्रित करता है। जब तक मॉडल में सभी सही सत्यापन / मान्यताएं हैं, तब भी यदि दृश्य की कमी है, तब भी सुरक्षा है।

आमतौर पर आपके पास दोनों होते हैं, क्योंकि विभिन्न स्तरों / भूमिकाओं के लिए दृश्य को बदलना पड़ता है। नियंत्रक प्रासंगिक डेटा भेजता है जो दृश्य को बदल देगा, लेकिन दृश्य को सही उपयोगकर्ता के लिए सामग्री को छिपाने / प्रदर्शित करने के लिए उस डेटा के साथ अभी भी कुछ करने की आवश्यकता है।

यही कारण है कि ज्यादातर अस्थायी ढांचे में सशर्त तत्व होते हैं ( हैंडलबार उदाहरण):

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

तो इसका मतलब है कि यह उल्लंघन नहीं है, जब तक कि उपयुक्त टुकड़े सही जगह पर न हों।


4

हां और ना।

यदि वास्तविक सुरक्षा निर्णय दृश्य द्वारा किया जाता है, तो हाँ, आप एमवीसी का उल्लंघन कर रहे हैं। यदि, हालांकि, दृश्य वास्तविक निर्णय को मॉडल में दर्शाता है, तो आप ठीक हैं। मॉडल से मिली जानकारी के आधार पर कौन से तत्व दिखाने हैं, इस पर निर्णय लेने में कुछ भी गलत नहीं है।

उदाहरण के लिए, यदि आपके पास "एडिट" बटन है जो केवल "एडिटर" अनुमतियों वाले उपयोगकर्ताओं के लिए दिखाई देता है, तो यह देखने के लिए ठीक है कि मौजूदा उपयोगकर्ता कौन है और क्या उनके पास "एडिटर" की अनुमति है, तो बटन दिखाने के लिए या नहीं यह तय करने के लिए इस जानकारी का उपयोग करना। यदि, हालांकि, दृश्य प्रमाणीकरण और प्राधिकरण तर्क को स्वयं करने के लिए थे, तो आप एमवीसी का उल्लंघन करेंगे।


2

मैं कहूंगा कि नहीं

लेकिन @rvcoutinho ने एक अलग कारण के लिए कहा (हालाँकि वह विकिपीडिया का हवाला देता है जो मुझे मेरी सोच में गलत लगता है)

मैं कहूंगा कि किसी भी प्रासंगिक सुरक्षा चिंताओं को मॉडल को देखने के लिए दिया जाना चाहिए (इस कारण से आप एक ViewModel का उपयोग करने की इच्छा कर सकते हैं संयोजनों की संख्या पर निर्भर करता है), जिसमें आप सुरक्षा बिट्स के लिए स्विच कर सकते हैं।

यह दो परत सुरक्षा सत्यापन की अनुमति देता है: यूआई परत पर इसलिए सामान्य स्थिति के लिए एक पोस्टबैक वापस किया जाता है, साथ ही खराब अभिनेताओं के लिए सर्वर परत पर जहां मॉडल खुद के अंदर सुरक्षा ज्ञान को बनाए रखता है, इसलिए नियंत्रक जानकारी को बंद कर देता है मॉडल जो तुरंत इसे बाहर निकालता है।

इस तरह दो परत सुरक्षा उद्योग में मानक है, और इस तरह से आपके सुरक्षा तर्क को केवल दो स्थानों पर मौजूद रहने की अनुमति मिलती है, इसलिए यह एक बोनस है, जैसे ही आप अपने नियंत्रक में सुरक्षा तर्क डालते हैं, आप इसे वहां डाल रहे हैं, और इस तरह से यूआई और मॉडल में (मॉडल को इसकी आवश्यकता है क्योंकि यह रक्षा की अंतिम पंक्ति है और विशेष रूप से उस एमवीसी वेब-ऐप के बाहर डेस्कटॉप क्लाइंट या किसी भी सर्वर प्रबंधन उपकरण के उपयोग के लिए महत्वपूर्ण है)


विकिपीडिया का दावा है कि "एक नियंत्रक अपने संबंधित दृश्य को मॉडल के दृश्य की प्रस्तुति को बदलने के लिए कमांड भेज सकता है" मॉडल-व्यू-प्रस्तुतकर्ता के लिए अधिक उपयुक्त लगता है , जैसा कि इंटरैक्टिव मॉडल वाक्यांश का वर्णन करना संभव लगता है, जबकि एमवीसी में, एक बार दृश्य का प्रतिपादन किया गया है, दृश्य और नियंत्रक के बीच कोई और कार्रवाई नहीं हुई है।
रॉबर्ट हार्वे

1
@RobertHarvey मैं इस बात से सहमत हूँ कि यह कथन MVC की मेरी परिभाषा में फिट नहीं है, लेकिन भाग्यशाली है कि हम एक ऐसे उद्योग में काम करते हैं जहाँ शुद्धता को किसी भी उकसावे के बजाय समझौते की बहुलता से तय किया जाता है क्योंकि ये परिभाषाएँ केवल उसी तरह से तैरती हैं जैसे कि ईथर से एक निरंतर विकसित होने वाली नींव जो हर किसी को अपनी टेकअवे बनाने की अनुमति देती है। या अधिक स्पष्ट शब्दों में, मैं शायद उतना ही गलत हूं जितना कि बाकी सभी लोग यहां हैं।
जिम्मी होफा

3
यही कारण है कि मुझे लगता है कि लोग वैसे भी इस तरह के बारे में बहुत अधिक पांडित्यपूर्ण हैं।
रॉबर्ट हार्वे

1
@rvcoutinho मैं यह नहीं कहूंगा कि मैं वास्तव में शाब्दिक था; आपको अपनी ओर से संदर्भ मिल गए हैं, मुझे जो कुछ मिला है वह मेरी राय है, इसलिए मेरे दिमाग में इसका मतलब है कि मैं गलत हूं, इसलिए मैंने इसका उल्लेख किया है। मुझे लगता है कि मेरी राय काफी हद तक साझा करने योग्य है, हालांकि मेरे पास कोई संदर्भ नहीं है इसलिए मैंने इसे वैसे भी किया, इस तथ्य की परवाह किए बिना कि जैसा मैंने कहा, मैं गलत हूं।
जिमी हॉफ

1
@rvcoutinho: वास्तव में, मैं ओपी के प्रश्न का उल्लेख कर रहा था। :) नियमों में कुछ भी गलत नहीं है, जब तक कि नियम कुछ पाने के रास्ते में नहीं आते।
रॉबर्ट हार्वे

2

मैं कहूंगा कि नहीं

आमतौर पर, नियंत्रक द्वारा इस तरह की सुरक्षा जांच की जाने वाली है।

से के रूप में विकिपीडिया :

एक नियंत्रक मॉडल के दृश्य की प्रस्तुति को बदलने के लिए अपने संबंधित दृश्य को कमांड भेज सकता है

और मुझे नहीं लगता कि इसे सीधे तौर पर देखा जाना चाहिए। यदि यह जावास्क्रिप्ट के माध्यम से किया जाता है, उदाहरण के लिए, यह एक सुरक्षा मुद्दा हो सकता है (कोई जावास्क्रिप्ट को अक्षम कर सकता है और निजीकृत डेटा तक पहुंच सकता है)।

फिर से, विकिपीडिया से :

एक दृश्य मॉडल से सूचना का अनुरोध करता है कि उसे आउटपुट प्रतिनिधित्व उत्पन्न करने की आवश्यकता है ।


1
कई सॉफ्टवेयर सिस्टम में, एक तत्व का प्रदर्शन उपयोगकर्ता के सुरक्षा स्तर पर निर्भर करता है। जब आप दृश्य मॉडल में शून्य या शून्य पर सेट करके किसी डेटा आइटम के प्रदर्शन को रोक सकते हैं, तब भी डेटा आइटम का नाम या विवरण प्रदर्शित किया जाएगा। एकमात्र स्थान जहां आप डेटा आइटम विवरण के प्रदर्शन को रोक सकते हैं (व्यावहारिक तरीके से) व्यू में है।
रॉबर्ट हार्वे

मैं असहमत हूं। मैं कहूंगा कि दृश्य डेटा का अनुरोध करेगा, नियंत्रक मॉडल में हेरफेर करेगा, और दृश्य फिर से, इसका प्रतिनिधित्व करेगा। दृश्य केवल आउटपुट के प्रतिनिधित्व के लिए जिम्मेदार होना चाहिए।
rvcoutinho

यही कारण है कि दृश्य को उन दृश्य तत्वों को छिपाने की आवश्यकता होती है जो उपयोगकर्ता को देखने की आवश्यकता नहीं है। डेटा के दृश्य प्रतिनिधित्व बनाने के लिए नियंत्रक जिम्मेदार नहीं है; दृश्य है बेशक, यदि आप जो प्रदर्शित कर रहे हैं वह इतना संवेदनशील है कि यह दृश्य / स्रोत में भी नहीं हो सकता है, तो नियंत्रक को जो करना है वह एक अलग दृश्य है।
रॉबर्ट हार्वे

1
वह मेरी बात है। नजरिया अलग होना चाहिए। जहां तक ​​मैं समझता हूं, ऐसा लगता है कि दृश्य को केवल डेटा के प्रतिनिधित्व का ध्यान रखना चाहिए। प्रतिनिधित्व से, मेरा मतलब होगा कि किसी चीज़ को कैसे दिखाना है, कब नहीं दिखाना है। फिर भी आपकी टिप्पणियाँ पूरी तरह से प्रासंगिक हैं।
rvcoutinho

खैर, मुझे लगता है कि हम दो अलग-अलग चीजों के लिए एक ही अभिव्यक्ति का उपयोग कर सकते हैं। वैसे भी एक अलग दृष्टिकोण क्या है? लेकिन मुझे लगता है कि हम सबसे महत्वपूर्ण मामले पर सहमत हैं: यदि यह सुरक्षा के प्रति संवेदनशील है, तो इसे दृष्टिकोण से नियंत्रित नहीं किया जाना चाहिए।
rvcoutinho

1

इस सवाल में कई मुद्दे शामिल हैं।

  1. प्रमाणीकरण (यह उपयोगकर्ता है जो वह कहता है कि वह है) दृश्य की चिंता नहीं होनी चाहिए ।
  2. प्राधिकरण (वर्तमान उपयोगकर्ता करने की अनुमति दी है इस ) है क्योंकि यह प्रभावित कर सकते हैं क्या उपयोगकर्ता के लिए प्रस्तुत हो जाता है, दृश्य की एक चिंता का विषय। इस प्रकार, एक संपादन-बटन प्रदर्शित करने के लिए कोड को सशर्त जैसे घिरा जा सकता है if model.userCanEdit() ... endif
  3. एक उपयोगकर्ता के पास कौन सा प्राधिकरण विशेषता है, इसका निर्धारण व्यवसाय तर्क है और इसे मॉडल में रखा जाना चाहिए। (उदाहरण के लिए कि 'संपादित करें' विशेषाधिकार के लिए आपको 2000 प्रतिष्ठा की आवश्यकता होती है, या यह कि आपको लेखक या मॉडरेटर होना चाहिए)

0

यदि यह केवल UI तत्व प्रदर्शित करने के बारे में है, तो मुझे लगता है कि यह ठीक है (आप इसे और कैसे भी करेंगे?)। यदि उन तत्वों में कोई डेटा होगा, तो मॉडल को यह सुनिश्चित करना चाहिए कि कंटेनर खाली हैं। और निश्चित रूप से अनुमति डेटा प्राप्त करने के लिए कोड को दृश्य से पहले संभाला जाना चाहिए था, इसलिए यहां मॉडल के लिए कोई सक्रिय पहुंच नहीं है।


0

अगर कोई दृश्य यूआई तत्वों को सशर्त रूप से प्रदर्शित करने के लिए सुरक्षा की स्पष्ट रूप से जांच करता है, तो क्या यह व्यावसायिक तर्क युक्त एमवीसी का उल्लंघन कर रहा है?

हां, यह एमवीसी का उल्लंघन है।

दृश्य केवल तत्वों को प्रदर्शित करने के लिए है, और तर्क मॉडल में होना चाहिए। दृश्य कुछ करने से (आपके मामले में, सुरक्षा की जाँच करें), आप तर्क को वहां रख रहे हैं।


फिर दृश्य को कैसे पता चलेगा कि संपादन बटन की तरह कुछ प्रदर्शित करना है या नहीं?
मैट एस

@MattS प्रस्तुतकर्ता उस बटन को दिखाने या छिपाने के लिए एक फ़ंक्शन को कॉल करता है (मॉडल में एक राज्य के आधार पर)।
B38овиЈ
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.