मेरे अनुभव में, असली सवाल ज्यादातर टूट जाता है कि उपयोगकर्ता-विशिष्ट पहुंच-प्रतिबंध की कोई राशि होने जा रही है या नहीं।
उदाहरण के लिए, मान लीजिए कि आप किसी समुदाय का स्कीमा तैयार कर रहे हैं और आप उपयोगकर्ताओं को उनकी प्रोफ़ाइल की दृश्यता को टॉगल करने की अनुमति देते हैं।
एक विकल्प सार्वजनिक/निजी प्रोफ़ाइल फ़्लैग से चिपके रहना और व्यापक, पूर्व-खाली अनुमति जांच से चिपके रहना है:'users.view' (सार्वजनिक उपयोगकर्ताओं को देखता है) बनाम, 'users.view_all' (मॉडरेटर के लिए सभी उपयोगकर्ताओं को देखता है) ।
एक अन्य में अधिक परिष्कृत अनुमतियां शामिल हैं, आप चाहते हैं कि वे चीजों को कॉन्फ़िगर करने में सक्षम हों ताकि वे खुद को (ए) सभी के द्वारा देखने योग्य बना सकें, (बी) अपने चुने हुए दोस्तों द्वारा देखे जा सकें, (सी) पूरी तरह से निजी रखा जा सके, और शायद (डी ) अपने हाथ से उठाए गए bozos को छोड़कर सभी के द्वारा देखा जा सकता है। इस मामले में आपको अलग-अलग पंक्तियों के लिए स्वामी/पहुंच-संबंधित डेटा संग्रहीत करने की आवश्यकता है, और घने, उन्मुख ग्राफ़ के संक्रमणीय बंद होने से बचने के लिए आपको इनमें से कुछ चीजों को बहुत अधिक सारगर्भित करने की आवश्यकता होगी।
किसी भी दृष्टिकोण के साथ, मैंने पाया है कि भूमिका संपादन/असाइनमेंट में अतिरिक्त जटिलता असाइनिंग में परिणामी आसानी/लचीलेपन से ऑफसेट है डेटा के अलग-अलग हिस्सों के लिए अनुमतियां, और यह कि निम्नलिखित ने सबसे अच्छा काम किया:
- उपयोगकर्ताओं की कई भूमिकाएं हो सकती हैं
- भूमिकाओं और अनुमतियों को एक ही तालिका में एक ध्वज के साथ मिला दिया गया है ताकि दोनों में अंतर किया जा सके (भूमिकाओं/अनुमतों को संपादित करते समय उपयोगी)
- भूमिकाएं अन्य भूमिकाएं निर्दिष्ट कर सकती हैं, और भूमिकाएं और अनुमतियां एक ही तालिका के भीतर से अनुमतियां प्रदान कर सकती हैं (लेकिन अनुमतियां भूमिकाएं निर्दिष्ट नहीं कर सकती हैं)।
परिणामी उन्मुख ग्राफ़ को फिर दो प्रश्नों में खींचा जा सकता है, जो एक बार और सभी के लिए उचित समय में आपके द्वारा उपयोग की जा रही किसी भी भाषा का उपयोग करके बनाया जा सकता है, और बाद में उपयोग के लिए मेम्कैश या इसी तरह के कैश में कैश किया जा सकता है।
वहां से, उपयोगकर्ता की अनुमतियों को खींचना यह जाँचने का विषय है कि उसकी कौन सी भूमिकाएँ हैं, और अंतिम अनुमति प्राप्त करने के लिए अनुमति ग्राफ़ का उपयोग करके उन्हें संसाधित करना है। यह सत्यापित करके अनुमतियां जांचें कि उपयोगकर्ता के पास निर्दिष्ट भूमिका/अनुमति है या नहीं। और फिर अपनी क्वेरी चलाएं/उस अनुमति जांच के आधार पर एक त्रुटि जारी करें।
आप अलग-अलग नोड्स के लिए चेक बढ़ा सकते हैं (यानी check_perms($user, 'users.edit', $node) "इस नोड को संपादित कर सकते हैं" बनाम check_perms($user, 'users.edit') के लिए के लिए "एक नोड संपादित कर सकते हैं") यदि आपको आवश्यकता हो, और आपके पास अंतिम उपयोगकर्ताओं के लिए बहुत लचीला/उपयोग में आसान कुछ होगा।
जैसा कि शुरुआती उदाहरण को स्पष्ट करना चाहिए, पंक्ति-स्तरीय अनुमतियों की ओर बहुत अधिक स्टीयरिंग से सावधान रहें। किसी व्यक्तिगत नोड की अनुमतियों की जाँच करने में प्रदर्शन अड़चन कम है, क्योंकि यह वैध नोड्स की सूची खींचने में है (अर्थात केवल वे जिन्हें उपयोगकर्ता देख या संपादित कर सकता है)। यदि आप क्वेरी ऑप्टिमाइज़ेशन में (बहुत) अच्छी तरह से वाकिफ नहीं हैं, तो मैं स्वयं पंक्तियों के भीतर झंडे और user_id फ़ील्ड से परे किसी भी चीज़ के खिलाफ सलाह दूंगा।
