PHP ओओपी - प्राधिकरण कैसे संभालें?

Question

मैं अपने विचार के लिए एक प्रबंधन प्रणाली का निर्माण कर रहा हूं। मैं PHP में अच्छी तरह से परिचित हूं (कम से कम मुझे वह सब कुछ करने के लिए पर्याप्त है जो मुझे करने की ज़रूरत है) लेकिन मैं ओओपी का उपयोग करने के साथ अनुभव नहीं कर रहा हूं। मैं इसे जितना कर सकता हूं उतना उपयोग करता हूं लेकिन बहुत से सर्वोत्तम प्रथाओं से मैं परिचित नहीं हूं इसलिए जब मैं चीजें करता हूं तो मुझे चिंता है कि मैं उन्हें गलत क्रम में कर रहा हूं।

इस प्रोजेक्ट के लिए मेरे पास उपयोगकर्ता द्वारा प्रबंधित की जाने वाली चीज़ के लिए एक कक्षा है, मुझे यह जांचने की आवश्यकता है कि उपयोगकर्ता को इसे प्रबंधित करने की अनुमति है या नहीं। मुझे अनुमति है कि अनुमतियों की जांच के लिए, मेरा प्रश्न है: मुझे यह कहां करना चाहिए?

मैं कक्षा के बाहर कर देना चाहिए, इसलिए जैसे:

if user permissions are valid 
initialize class 
else return error 

या मैं

initialize class 
class checks permissions 
class returns error if permissions are invalid 

करना चाहिए मैं अनिश्चित हूँ जो सही दृष्टिकोण है। एक तरफ वर्ग के भीतर जांच करना ओओपी पद्धति के बारे में मुझे सबसे अच्छा लगता है, लेकिन फिर मुझे यह भी महसूस होता है कि अनुमति को अज्ञात होने पर वर्ग को प्रारंभ करने तक इसे प्राप्त करने की अनुमति दी जा सकती है।

मुझे यह कैसे करना चाहिए? अगर इस तरह की कोई चीज है जो इस तरह की चीज को कवर करती है तो एक लिंक की बहुत सराहना की जाएगी (मुझे खोजों के माध्यम से कुछ भी नहीं मिल रहा है, लेकिन अगर मैं सही चीज़ की तलाश में हूं तो मुझे 100% यकीन नहीं है क्योंकि मुझे ओओपी के बारे में पता है)

Answer 1

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

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

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

मैं वर्तमान में एक एमवीसी पैटर्न का उपयोग कर रहा हूं, और मेरे पास एक नियंत्रक है, जो अपने बच्चों को कार्यों को भेजता है। इसकी एकमात्र सार्वजनिक विधि है और यह actionAction($params) पर स्वयं कॉल करेगी, लेकिन पहले यह अनुमतियों की जांच करेगी।

एक महत्वपूर्ण बात याद करने के लिए किया जाता है: यूआई कि उपयोगकर्ता करने की अनुमति नहीं है पर कभी नहीं वर्तमान कार्यों (जब तक आप उसे अपने "प्रो संस्करण" खरीदने के लिए मजबूर करने के लिए कोशिश कर रहे हैं, वह यह है कि) ;-)

Answer 2

मुझे लगता है कि अनुमति का वर्ग होना सबसे अच्छा तरीका है। और फिर आप वस्तु बनाने या ऑब्जेक्ट में बनाने से पहले जांच सकते हैं।

create permission class 
if access then create class and set permission object 
else error 
// do action 
if have permissions show something 
else do not show something 

देखो कैसे zend acl component

Answer 3

में किया मैं एक बहुत ही ठोस और मजबूत सीएमएस प्रणाली लिखा है। यहां बताया गया है कि मैं इसे कैसे करता हूं और मुझे आशा है कि आप अपना स्वयं का समाधान करने के बारे में कुछ जानकारी निकाल सकते हैं।

• मेरे पास एक इंडेक्स फ़ाइल है, जो Admin कक्षा लोड करती है। मेरे सीएमएस में कार्यक्षमता मॉड्यूलर है (इसलिए अपनी फाइल और कक्षा में शामिल है)।
• एक मॉड्यूल $_GET पैरामीटर के आधार पर लोड किया गया है।
• समारोह $_GET पैरामीटर जाँच क्योंकि करने के लिए और लोड इसी समारोह मेरी Admin कक्षा में है ($admin->pick_method()) और मैं भी मेरी Admin कक्षा में एक User वस्तु है, मैं पहले जाँच कर सकते हैं अनुरोध किया मॉड्यूल में वर्तमान में उपयोगकर्ता के लॉग-इन है अनुमति सरणी
• यदि अनुमतियां true लौटाती हैं, तो मैं मॉड्यूल लोड करता हूं। यदि false, तो मैं एक दोस्ताना "अनधिकृत पहुंच" पृष्ठ प्रदर्शित करता हूं।

उम्मीद है कि इससे मदद मिलती है।

Answer 4

कक्षा के भीतर मान्य वर्ग और अनुमति प्राधिकरण के बीच एक निर्भरता उत्पन्न करता है जो अच्छा नहीं है क्योंकि आप दो संभावित विषम वस्तुओं को एक साथ जोड़ रहे हैं। आप Inversion of Control (उदाहरण के लिए dependency injection) या authorisation notifications using Emesary द्वारा इसे हल कर सकते हैं।

कक्षा के बाहर मान्य करना संभवतः बदतर है क्योंकि वास्तविक खतरा है कि प्राधिकरण जांच गलत होगी या पूरी तरह से चूक जाएगी। यह वस्तुओं के बीच जोड़ने का गलत प्रकार भी बनाता है क्योंकि वस्तु स्वयं के नियंत्रण में नहीं है।

यदि आप इसे बनाए जाने पर ऑब्जेक्ट के बाहर ऐसा करने जा रहे हैं तो ऑब्जेक्ट की आवश्यकता होती है ताकि interface जैसे IAuthorisable प्रदान किया जा सके जिसे एक अलग ऑब्जेक्ट द्वारा सत्यापित किया जा सके।

उदा।

interface IAuthorisable 
{ 
    public function getRequirements(); 
} 

class Authorisation 
{ 
    public static createObject($newObj) 
    { 
      if (canDo($newObj->getRequirements())) 
       return $newObj; 
      return null; 
    } 
} 

class Something implements IAuthorisable 
{ 
    public function getRequirements() 
    { 
      return SomeSortOfIdentifierOrSomething; 
    } 
} 

$mySomething = Authorisation::createObject(new Something($p1, $p2), " 

यदि $ my कुछ कुछ शून्य है तो इसकी अनुमति नहीं है। जाहिर है, इसे पाठक के लिए अभ्यास के रूप में छोड़ दिया गया है जो ठीक से विस्तार और डिजाइन की जरूरत है।

Answer 5

OO मूल बातें
अगर यह समझ में आता है वर्ग में शामिल करने की। आप कर सकते हैं।
क्या एक पुस्तक वर्ग में एक प्रमाणित कार्य है? नहीं, डाउनलोड() और कन्वर्ट टीओपीडीएफ() जैसे फ़ंक्शंस अधिक समझ में आता है।

मेरे दृष्टिकोण
मैं हमेशा कम से कम प्रतिरोध का रास्ता ढूंढने के लिए प्रयास करें।

यदि 10 स्क्रिप्ट/पेज हैं जो 1 वर्ग और 1 या 2 स्क्रिप्ट से बात करते हैं तो कुछ कार्यों के लिए प्रमाणीकरण की आवश्यकता होती है, मैं उन 1 या 2 स्क्रिप्ट में प्रमाणीकरण का निर्माण करूंगा। (या उन्हें एक .htpasswd के साथ एक उपफोल्डर में रखें)

लेकिन जब आप एक एमवीसी संरचना का उपयोग कर रहे हैं, तो सब कुछ एक वर्ग है, इसलिए यह कौन सा वर्ग तय करने का सवाल बन गया है।
मैं नियंत्रक कक्षाओं में प्रमाणीकरण नियम और उपयोगकर्ता वर्ग में डेटाबेस-तर्क के प्रमाणीकरण को प्रस्तुत करता हूं।