वेब संसाधन के लिए एक्सेस रोल डेटा मॉडल

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

तो, यह कार्यान्वयन विधि आपके लिए सही है यदि :

1) आप एक विशिष्ट सिस्टम ऑब्जेक्ट के लिए उपयोगकर्ता एक्सेस अधिकार प्राप्त करने में सक्षम होना चाहते हैं, जिसमें प्रत्येक विशिष्ट उपयोगकर्ता के लिए;
2) आप उपयोगकर्ताओं को इस तरह से व्यवस्थित करना चाहते हैं कि उनमें से प्रत्येक एक ऐसे विषय को संदर्भित करता है जिसके भीतर अधिकारों का एक निश्चित समूह होगा, और यह भी कि उपयोगकर्ता के पास एक बार में कई विषयों से संबंधित होने की क्षमता है;
3) यह बहुत अच्छा होगा यदि विषय के भीतर कुछ उपयोगकर्ता व्यवस्थापक की भागीदारी के बिना एक ही विषय के अंदर अन्य उपयोगकर्ताओं के एक्सेस अधिकारों का प्रबंधन कर सकते हैं, जबकि ऐसे उपयोगकर्ता स्वयं अपने विषय के अधिकारों से परे नहीं जाएंगे;
4) आप चाहेंगे कि संगठन प्रणाली वेब विकास के लिए किसी भी प्रोग्रामिंग भाषा में व्यवस्थित करने के लिए सहज और सरल हो, साथ ही साथ इसे किसी भी रिलेशनल डेटाबेस में संग्रहीत करें;
5) भविष्य में, सूचना प्रणाली का उपयोग उपयोगकर्ता कार्यों को लॉग करने के कार्य के साथ किया जाएगा, और आप एक्सेस अधिकार प्रणाली और लॉगिंग सिस्टम के बीच सीधा संबंध रखना चाहेंगे।

आइए एक व्यावहारिक उदाहरण पर चलते हैं:

कार्य एक परियोजना प्रबंधन प्रणाली को व्यवस्थित करना है, उदाहरण के लिए, इस तरह से:
प्रणाली:

• व्यवस्थापक;
• सामग्री प्रबंधक।

परियोजना:

• परियोजना प्रबंधक;
• प्रोजेक्ट क्यूरेटर;
• परियोजना ग्राहक;
• परियोजना विश्लेषक;
• परियोजना के निष्पादक;
• परियोजना परीक्षक।

एक डेटाबेस मॉडल पर विचार करें जो एक अधिकार प्रणाली के भंडारण को लागू करता है:

हमारे पास क्या है:
1) ऑब्जेक्ट - एक्सेस ऑब्जेक्ट;
2) क्रिया - किसी वस्तु पर किया जाने वाला कार्य;
3) अनुमति - किसी वस्तु पर कार्रवाई करने की अनुमति;
4) उपयोगकर्ता - उपयोगकर्ता;
5) परियोजना - एक परियोजना (अन्य आईपी में एक "भागीदार", "अनुबंध", आदि) हो सकता है;
6) project_type - परियोजना का प्रकार;
7) user_assigment - एक विशिष्ट परियोजना परियोजना के लिए उपयोगकर्ता उपयोगकर्ता को बांधना;
8) भूमिका - प्रोजेक्ट प्रकार के लिए भूमिका project_type ;
9) भूमिका_प्रवेश - भूमिका भूमिका के लिए अनुमति की अनुमति ;
10) role_user_assigment - एक विशिष्ट भूमिका के लिए उपयोगकर्ता-प्रोजेक्ट बाइंडिंग user_assigment का असाइनमेंट;
11) remove_permission_user_asgmt - एक विशिष्ट user_assigment बाइंडिंग की अनुमति अनुमति को हटा रहा है।

अगला, हमारे कार्यों के अनुक्रम पर विचार करें:

1) कार्य के अनुसार, हमारे पास 2 प्रकार की परियोजना है: एक उपयोगकर्ता परियोजना और एक प्रणाली, हम उन्हें project_type में ठीक करते हैं।
2) हमारे पास टाइप "सिस्टम" के लिए 2 भूमिकाएं भी हैं और टाइप "यूजर प्रोजेक्ट" के लिए 6 भूमिकाएं हैं, हम उन्हें संबंधित प्रोजेक्ट_टाइप के तहत भूमिका में ठीक करते हैं।
3) अगला, हम उन ऑब्जेक्ट ऑब्जेक्ट्स को परिभाषित करते हैं जो उपयोगकर्ता के साथ काम करेंगे। (उदाहरण के लिए, "उपयोगकर्ता प्रोफ़ाइल", "कार्य", "परीक्षण", "नोट", आदि)
4) हम सभी ऑब्जेक्ट के लिए उत्पादित एक्शन क्रियाओं को परिभाषित करते हैं। ये दोनों क्लासिक CRUD और सिस्टम-विशिष्ट हैं: "असाइन", "ब्लॉक", "डाउनलोड", आदि।
5) कुछ कार्यों और वस्तुओं से हम अनुमति अनुमति का एक संग्रह बनाते हैं, उदाहरण के लिए: "कार्य जोड़ें", "नोट संपादित करें", आदि।
6) विशिष्ट भूमिकाओं के लिए अनुमति अनुमति बनाएँ।
7) तब यह केवल विशिष्ट उपयोगकर्ता और परियोजनाएँ बनाने के लिए बना रहता है, पूर्व को user_assigment में बाद में संबद्ध करता है और उन्हें role_user_assigment तालिका में किसी विशिष्ट प्रोजेक्ट के ढांचे के भीतर भूमिकाएँ प्रदान करता है।

इस प्रणाली में प्रतिबंध जैसी कोई चीज नहीं है, इसलिए यदि किसी उपयोगकर्ता के पास 2 भूमिकाएं हैं, तो इन भूमिकाओं के लिए सभी अनुमतियों के संघ को उसका उपयोग अधिकार माना जाएगा।
उसी समय, यदि यह आवश्यक है कि उपयोगकर्ता के पास उसके अधिकारों से कोई विशिष्ट अनुमति नहीं है, तो इसे केवल हटाए गए__प्रवेश_सुपर_सैग्मट तालिका में जोड़ने के लिए पर्याप्त है (जिसका अर्थ है कि इस तरह के अभिगम अधिकारों का अभाव)। उदाहरण के लिए, एक परीक्षक के लिए, यह अनुमति जारी करना आवश्यक है कि केवल "प्रोजेक्ट मैनेजर" की भूमिका हो। इस मामले में, परीक्षक के लिए "प्रोजेक्ट मैनेजर" की भूमिका निर्दिष्ट करना और सभी आवश्यक अनुमतियों को छोड़कर सभी अनुमतियों को हटाने के लिए हटा दिया गया है__प्रवेश_सुपर_सग्मट में ।
इस संगठन के भीतर, उपयोगकर्ता परियोजना के किसी भी भूमिका को स्वतंत्र रूप से परियोजना के भीतर उपयोगकर्ताओं को भूमिकाएँ सौंपने का अधिकार देने में कोई कठिनाई नहीं है, जबकि वह "सिस्टम प्रशासक" की भूमिका के लिए खुद को या किसी और को अनुमति देने में सक्षम नहीं होगा, क्योंकि उसे चुनना होगा। केवल उन भूमिकाओं और अनुमतियों को जो इसके प्रोजेक्ट_टाइप के साथ संबद्ध हैं, दी जाएगी।

मैं ध्यान देता हूं कि ऐसा संगठन लॉगिंग सिस्टम के साथ अच्छी तरह से इंटरैक्ट करता है (यह इस लेख में नहीं दिया गया है, इसकी सादगी के कारण), क्योंकि हम यह पता लगा सकते हैं कि किसी विशेष उपयोगकर्ता ने किसी विशेष क्षण में क्या कार्रवाई की।
इसके अलावा, अधिकारों को व्यवस्थित करने की ऐसी प्रणाली अधिसूचना प्रणालियों और कार्य प्रवाह प्रणालियों के साथ अच्छी तरह से चलती है।
व्यापार के लिए सूचना प्रणाली (php, ओरेकल डेटाबेस में एप्लिकेशन के कार्यान्वयन) में से एक में सिस्टम का उपयोग 2 साल के लिए किया गया है, जो पूरी तरह से फिट बैठता है।