2011-08-31 19 views
22

मैं कुछ एसीएल आवश्यकताओं के साथ एक वेब अनुप्रयोग लिख रहा हूं: कोई उपयोगकर्ता कुछ वस्तुओं में बदलाव कर सकता है, कुछ आइटम कई उपयोगकर्ताओं द्वारा संपादन योग्य हो सकते हैं, व्यवस्थापक कुछ भी संपादित कर सकता है और प्रबंधक अपने संगठन आदि के भीतर सब कुछ संपादित कर सकता है।प्राधिकरण मॉडल या नियंत्रक का हिस्सा होना चाहिए?

मैं Play का उपयोग कर रहा हूँ! ढांचे, और Secure मॉड्यूल के रूप में, ऐसा लगता है कि प्राधिकरण चिंताओं को रखने की जगह नियंत्रकों में है। हालांकि, मुझे ऐसा लगता है कि प्राधिकरण मुद्दे व्यापार तर्क का हिस्सा हैं, और इसलिए मॉडल में होना चाहिए। इसके अलावा, मैं उन नियंत्रकों में डुप्लिकेट तर्क देखना शुरू कर रहा हूं जिन्हें मुझे पुनः प्रतिक्रिया करने की आवश्यकता है।

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

तो आम अभ्यास क्या है? क्या मैं मॉडल में प्राधिकरण कोड डाल सकता हूं, या इसे नियंत्रक में रख सकता हूं?

उत्तर

14

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

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

+7

तो यह कौन सा है, ग्रे क्षेत्र, या बिल्कुल सही? :) – itsadok

+3

मेरी राय में, मुझे लगता है कि यह बिल्कुल सही है, हालांकि, यह एक भूरा क्षेत्र है और इसलिए व्याख्या के लिए खुला है।इसलिए, यह इस बात पर निर्भर करता है कि आप मेरी व्याख्या से सहमत हैं या नहीं: o) – Codemwnci

4

ज्यादातर मामलों में, सुरक्षा मॉडल के ऊपर एक (या अधिक) परत होनी चाहिए। सुरक्षा अपने आप पर एक डोमेन है, निचले स्तर की परत तक पहुंच प्रतिबंधित है।

मुझे नहीं लगता कि सुरक्षा नियंत्रक स्तर पर की जानी चाहिए।

मेरी राय में, यह है कि तरह दिखना चाहिए:

देखें -> नियंत्रक -> सुरक्षा -> मॉडल

सुरक्षा परत एक बहाना या मॉडल पर एक प्रॉक्सी, पहुँच की रक्षा हो सकती है, लेकिन नियंत्रक के लिए पारदर्शी हो।

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

+0

आप सुरक्षा और प्रमाणीकरण को जोड़ रहे हैं। आवेदन की हर परत पर सुरक्षा चिंताओं का सामना करना पड़ता है - देखें: गहराई में रक्षा। सवाल यह है कि "प्राधिकरण कहां से संबंधित है?", सुरक्षा नहीं। –

1

मैं व्यक्तिगत रूप से वास्तव में Play के तरीके को पसंद करता हूं! सुरक्षित मॉड्यूल इसे संभालता है (the tutorial is ever-helpful here)। यदि आपको @Before एनोटेशन का उपयोग करने में कोई फर्क नहीं पड़ता है, तो यह बहुत दर्द रहित है।

1

प्रमाणीकरण न तो नियंत्रक या डोमेन मॉडल का हिस्सा होना चाहिए।

इसके बजाय यह सेवा परत में होना चाहिए।

नियंत्रक को केवल प्रेषक के रूप में कार्य करना चाहिए और HTTP और एप्लिकेशन सेवा के बीच प्रतिनिधि होना चाहिए। यह एप्लिकेशन सेवा है जहां ऑर्केस्टेशन होता है। प्राधिकरण रखने के लिए यह सबसे अच्छी जगह है।

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

चूंकि डोमेन मॉडल सेवा परत पर एक-दूसरे के साथ संवाद करते हैं, इसलिए यह उसी स्तर पर प्राधिकरण को स्थानांतरित करना सर्वोत्तम होता है।

0

मैं इस स्तर पर कर रहा हूँ और निम्नलिखित तरीके से इस संभाल करने के लिए इच्छुक:

  • जे एस द्वारा कोई प्रपत्र सत्यापन, बजाय के माध्यम से HTTPS ajax

  • एक अजाक्स php वर्ग


  • सामान्य प्रकार जैसे ईमेल और पासवर्ड (संभवतः assoc सरणी सत्यापन अन्य कक्षाओं द्वारा पुन: उपयोग किया जाएगा, तो यह निश्चित है कि एक मॉडल के लिए ठोस डेटा के लिए एक डेटा को भेजा गया डेटा डेटा एक मॉडल क्षेत्र)।

  • यदि कोई त्रुटि क्रेडेंशियल के लिए एक उपयोगकर्ता तालिका में एक देखने को ईमेल/
    पासवर्ड साख को प्रवेश/साइनअप/पासवर्ड के रूप में प्रमाणीकरण
    प्रकार के साथ एक नियंत्रक के लिए पारित रीसेट

  • नियंत्रक तो पैदा करता है आवश्यक उत्पादन दृश्य या उपयोगकर्ता सत्र आदि में लॉग इन

यह Laravel में आधारित है सेट लेकिन मैं अपने पुस्तकालय है यह laravel के स्वतंत्र और सिर्फ शिथिल इस वीटा के लिए आधारित चाहते हैं के रूप में एल आवश्यकता

यह मुद्दा यह है कि मॉडल आवश्यक प्रमाण-पत्र डेटा के रूप में देखता है, फिर नियंत्रक को भेजता है क्योंकि यह परवाह नहीं करता कि इसे कैसे संसाधित किया जाना चाहिए। मुझे लगता है कि इस क्षेत्र को प्रत्येक घटक के बीच एक निश्चित जिम्मेदारी बनाने का यही एकमात्र तरीका है।

0

MVC चौखटे के साथ मेरे व्यक्तिगत अनुभव से मैं कहूंगा:

  1. मॉडल एक वस्तु है कि डेटाबेस तालिका का प्रतिनिधित्व कर रहा है यह शुद्ध होना चाहिए और किसी भी अतिरिक्त तर्क नहीं होने चाहिए।
  2. नियंत्रक वह स्थान है जहां निर्णय किए जाते हैं और अन्य कस्टम तर्क, इसलिए प्रमाणीकरण नियंत्रक में होना चाहिए। यह को कुछ हुक डिज़ाइन किया जा सकता है जो यह जांच सकता है कि उपयोगकर्ता अधिकृत है या नहीं, सभी आवश्यक स्थानों में नहीं, इसलिए आपके पास कोड पुनरावृत्ति DRY नहीं है।

  3. यदि आप एक विशिष्ट बाकी वास्तुकला का उपयोग कर रहे उपयोगकर्ता के लिए अनुमति देने के लिए सबसे अच्छा तरीका है एक टोकन बनाने, databse में और क्लाइंट पक्ष पर सहेजें और हर अनुरोध पर इस टोकन को सत्यापित करने के लिए है। यदि आप वेब ब्राउज़र ऐप का उपयोग कर रहे हैं तो आप प्राधिकरण के लिए सर्वर-साइड सत्र का उपयोग कर सकते हैं ( यह अधिक आसान है)।

तो मेरा प्रस्ताव नियंत्रक में प्राधिकरण तर्क रखना है।

संबंधित मुद्दे

 संबंधित मुद्दे