YB और LDAP में RBAC प्राधिकरण

RBAC एक वेब अनुप्रयोग के लिए केंद्रीय नियंत्रण के लिए एक सरल और शक्तिशाली तरीका है। इसका मुख्य लाभ यह है कि प्राधिकरण पदानुक्रम की सही समझ और आवेदन के साथ, आप नियंत्रकों के कोड को बदलने के बिना बहुत लचीले ढंग से पहुंच को नियंत्रित कर सकते हैं।

दुर्भाग्य से, YII में मानक RBAC मैनुअल उत्तर की तुलना में अधिक प्रश्न छोड़ता है। मैं इस स्थिति को ठीक करने का इरादा रखता हूं।
मैं "सही" पदानुक्रम बनाने के बारे में बात करूंगा: यह कैसे करना है इसके लायक नहीं है। और अंत में, मैंने Yii और RBAC के साथ LDAP प्राधिकरण (ActiveDirectory से) मित्र बनाने के निर्देश पर बचत की।

हर कोई जो दिलचस्पी रखता है, बिल्ली का स्वागत है!


आरबीएसी (भूमिका आधारित अभिगम नियंत्रण) भूमिका आधारित अभिगम नियंत्रण । Yii में इस प्रणाली का आधार तीन मुख्य लिंक हैं:

• भूमिका (भूमिका)
• कार्य (टास्क)
• ऑपरेशन (ऑपरेशनटन)

मुझे लगता है कि पाठक ने पहले ही आधिकारिक YII पाठ्यपुस्तक के पृष्ठ की संक्षिप्त समीक्षा की है और Yii में प्राधिकरण तंत्र के मूल सिद्धांतों को जानता है।

इसलिए, हम प्राधिकरण तत्वों के सही पदानुक्रम के निर्माण के लिए तुरंत आगे बढ़ते हैं।

भूमिकाओं की पदानुक्रम।

सबसे महत्वपूर्ण, और समझने में सबसे अधिक भ्रमित करने वाला, आरबीएसी में तत्वों का पदानुक्रम है। कितनी अच्छी तरह से सोचा गया यह इस बात पर निर्भर करता है कि आप लचीले ढंग से सिस्टम में भूमिकाएं कैसे प्रबंधित कर सकते हैं, और कितनी बार आपको नियंत्रक कोड को बदलना होगा।

आइए प्रत्येक प्राधिकरण तत्व पर अधिक विस्तार से विचार करें:

• एक ऑपरेशन प्राधिकरण का सबसे निचला तत्व है। यह वही है जिसे हमें अपने नियंत्रकों के कोड में जांचना चाहिए। दूसरे शब्दों में: एक ऑपरेशन वह है जो कोड से जुड़ा होता है।
• एक भूमिका , इसके विपरीत, प्राधिकरण का सर्वोच्च तत्व, संचालन और कार्यों को एक साथ समूहित करना है। और यह वह भूमिका है जो हमें उपयोगकर्ताओं को संलग्न करनी चाहिए।
• कार्य - यह ऑपरेशन और भूमिका के बीच एक वैकल्पिक तत्व है, और bizRule का उपयोग करके ऑपरेशन के अधिकारों को प्रतिबंधित करता है। समझने की सुविधा के लिए, हम इसे फ़िल्टर कहते हैं ।

ऊपर दिए गए आरेख में एक विशिष्ट पदानुक्रम दिखाया गया है जहां नियंत्रक ऑपरेशन की जाँच करते हैं और भूमिकाएँ उपयोगकर्ताओं को सौंपी जाती हैं। हालाँकि, YII आपको नियंत्रक में कुछ और जाँचने से नहीं रोकता है, उदाहरण के लिए, उपयोगकर्ता की भूमिका।
लेकिन आपको याद रखना चाहिए कि यह गलत है और इस तथ्य की ओर जाता है कि आप केंद्रीकृत प्रबंधन के लाभों को खो देते हैं।

एक उदाहरण पर विचार करें:
हमारे पास समाचार है, जिसके प्रबंधन के लिए हम पहुंच को अलग करना चाहते हैं।
RBAC को डिज़ाइन करते समय पहली बात हमें यह करना चाहिए कि संभावित OPERATIONS (और उपयोगकर्ता भूमिकाओं पर नहीं, क्योंकि यह पहली नज़र में लगता है) पर विचार करना चाहिए।

आमतौर पर, समाचार को हटाया , बनाया , पढ़ा और संपादित किया जा सकता है । हम इन क्रियाओं को संचालन में बदलते हैं : हटाएं , बनाएं , नया करें , पढ़ेंन्यूज , अपडेटन्यूज ।

कोड में, आप इनमें से कोई भी ऑपरेशन देख सकते हैं:

if(Yii::app()->user->checkAccess('createNews')) { //   } // if(Yii::app()->user->checkAccess('updateNews')) { //   } 

ऑपरेशन के विचार के बाद, आप भूमिकाओं पर आगे बढ़ सकते हैं (मैं जानबूझकर कार्यों को छोड़ देता हूं, हम उनके बारे में थोड़ी देर बाद बात करेंगे):

उपलब्ध संचालन से, हम निम्नलिखित भूमिकाओं को अलग कर सकते हैं:
newsReader , newsManager , newsAuthor ।

तत्वों की पदानुक्रम निम्नानुसार होगी:

• न्यूज़रीडर
  • readNews
• newsAuthor
  • readNews
  • createNews
• newsManager
  • readNews
  • createNews
  • deleteNews
  • updateNews

ये भूमिकाएँ विशिष्ट उपयोगकर्ताओं से जुड़ी हो सकती हैं। लेकिन अधिक सामान्यीकृत भूमिकाओं का एक और अमूर्त बनाना बेहतर है, और उपयोगकर्ताओं के लिए इसे संलग्न करें, उदाहरण के लिए:

• अतिथि
  • न्यूज़रीडर
• अधिकृत
  • newsAuthor
• मध्यस्थ
  • newsManager

इस तरह का अमूर्त सुविधाजनक है अगर हमें न केवल समाचार का प्रबंधन करना है, बल्कि यह भी कहना है, फोटो गैलरी में चित्र या स्टोर में सामान। फिर आपके सिस्टम के ऐसे प्रत्येक भाग के लिए आपको अपनी "इंटरमीडिएट" भूमिकाएँ बनाने की आवश्यकता होती है, उदाहरण के लिए photoReader (showPhoto) , फ़ोटोग्राफ़र (showPhoto, addPhoto) , photoManager (showPhoto, addPhoto, deletePhoto) और उन्हें सामान्यीकृत भूमिकाओं में संलग्न करें:

• अतिथि
  • न्यूज़रीडर
  • photoReader
• अधिकृत
  • newsAuthor
  • फोटोग्राफर
• मध्यस्थ
  • newsManager
  • photoManager

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

आपने शायद देखा कि अपडेट ऑपरेशन न्यूज़ऑथोर और फ़ोटोग्राफ़र भूमिकाओं के लिए उपलब्ध नहीं है। यह सही है, क्योंकि यदि इस स्तर पर हम उन्हें ऑपरेशन अपडेट देते हैं या अपडेट करते हैं, तो वे अंधाधुंध सभी तस्वीरों का प्रबंधन करने में सक्षम होंगे। और हमें लेखकों को केवल उनके तत्वों को संपादित करने में सक्षम होना चाहिए।

यह इसके लिए है कि कार्य बनाए जाते हैं। कार्य फ़िल्टर हैं जो अधिकार निर्दिष्ट कर सकते हैं। चलिए updateOwnNews टास्क बनाते है, जिसके वंशज हम updateNews को असाइन करेंगे । कार्य के नाम से यह स्पष्ट है कि यह आपको अपनी खुद की खबर को संपादित करने की अनुमति देगा, और bizRule इससे हमें मदद मिलेगी।

bizRule कुछ प्रकार का PHP कोड है, जिसके परिणाम का उत्तर होना चाहिए: इस नियम को इस उपयोगकर्ता पर लागू करना है या नहीं।

हमारे अपडेट के लिए bizRuleNwnews कार्य इस तरह दिखेगा:

 $bizRule='return Yii::app()->user->id==$params["news"]->authID;'; 

यदि हम जाँचते हैं कि लेखक की आईडी वर्तमान अधिकृत उपयोगकर्ता के साथ समाचार से मेल खाती है या नहीं।

एक व्यापार नियम में वर्तमान समाचार आइटम प्राप्त करने के लिए, आपको पहले इसे वहां पारित करना होगा:

 $params=array('news'=>$post); if(Yii::app()->user->checkAccess('updateNews',$params)) { //   } 

कृपया ध्यान दें कि हम एक विशिष्ट कार्य ( updateOwnNews ) की जाँच नहीं कर रहे हैं, लेकिन अपडेटन्यूज़ ऑपरेशन (पदानुक्रम का सबसे निचला तत्व)।

पदानुक्रम के लिए धन्यवाद, जो कि कार्य अद्यतन बनाने के बाद। इस तरह से बन गया:

• newsAuthor
  • readNews
  • createNews
  • updateOwnNews
    • updateNews

Yii नीचे से अभिगम नियंत्रण शुरू करेगा और पदानुक्रम ऊपर जाएगा, अर्थात्। updateNews की जाँच करेंगे, फिर updateOwnNews पर जाएँ। चेक के प्रत्येक चरण में, Yii जाँच करेगा: यदि बिज़रुले नियम निर्धारित है, और यदि यह है, तो यह चेकऑफ़ फ़ंक्शन में निर्दिष्ट मापदंडों को पारित करेगा।

एक चेक को योजनाबद्ध रूप से निम्नानुसार दर्शाया जा सकता है:



आरेख 3 परीक्षण परिदृश्य दिखाता है:
पहला परिदृश्य तब होता है जब एक अधिकृत उपयोगकर्ता अपनी खबर संपादित करने की कोशिश करता है। इस मामले में, नीचे से ऊपर की ओर जा रहा चेक अप अपडेट के माध्यम से जाता है। और चूंकि उपयोगकर्ता आईडी समान हैं, इसलिए यह सफल होता है।

दूसरे मामले में, उपयोगकर्ता के पास एक मध्यस्थ की भूमिका होती है। इसकी पदानुक्रम में कोई अपडेटऑनएन्यूज कार्य नहीं है, इसलिए, केवल अपडेटन्यूज ऑपरेशन की उपस्थिति की जांच की जाती है।
सत्यापन सफल है।

तीसरे मामले में, एक अधिकृत उपयोगकर्ता किसी और के लेख को संपादित करने की कोशिश करता है, और updateOwnNews चरण में चेक विफल रहता है, क्योंकि संतुष्ट नहीं bizRule कार्य।

ऊपर दिए गए उदाहरण केंद्रीकृत अधिकार प्रबंधन को प्रदर्शित करते हैं।
ऑपरेशन को पूरा करने के लिए नियंत्रक पर एक बार एक चेक लिखकर और वहां पैरामीटर पारित करके, एक्सेस कंट्रोल पर आगे का सारा काम RBAC पर छोड़ दिया जाता है।
इसलिए, जब भी संभव हो, आपको हमेशा चेकऑउट फ़ंक्शन को पैरामीटर पास करना चाहिए (भले ही चेक की गई वस्तु में एक बिज़र्यूल न हो), और ऑपरेशन की जांच करें, भूमिका नहीं।

यदि एक स्थिति में नियंत्रक में आप एक से अधिक चेक लिखना चाहते हैं - तो आप जानते हैं, आप गलत दिशा में जा रहे हैं - आपको पदानुक्रम के संगठन के साथ समस्याएं हैं।

उदाहरण के लिए:

 if(Yii:app()->user->checkAccess('moderator') && Yii:app()->user->checkAccess('administrator')) { //delete smth } 

यह गलत है। इस दृष्टिकोण के साथ, आप केंद्रीय रूप से अधिकारों का प्रबंधन नहीं कर सकते। आपको हर बार कोड को संपादित करना होगा और यहां एक नई शर्त जोड़नी होगी।

नियंत्रकों में अधिकारों की जाँच के तरीके

अधिकारों को सत्यापित करने के 2 तरीके हैं।
पहली विधि हम पहले से ही विचार कर चुके हैं। यह सीडब्यूसर घटक का चेकआइट () तरीका है।

लेकिन उन लोगों के लिए जो इस बात की परवाह करते हैं कि उनके नियंत्रक "मोटे नहीं हो रहे हैं", अधिकारों की जाँच करने का एक और पहलू-उन्मुख तरीका है।

विधि नियंत्रक के लिए 'accessControl' फिल्टर कनेक्ट करने के लिए है।

यह फ़िल्टर आपके लिए सभी गंदे काम करेगा: यह एक्सेस अधिकारों की जांच करेगा और यदि आवश्यक हो, तो उपयोगकर्ता को पृष्ठ 403 पर भेजें। इस प्रकार, आपको प्रत्येक कार्रवाई में सत्यापन कोड की नकल करने की आवश्यकता नहीं है।

समाचार नियंत्रक के उदाहरण से फ़िल्टर पर विचार करें:

 class NewsController extends CController { … public function filters() { return array( 'accessControl', ); } public function accessRules() { return array( array('allow', 'actions'=>array('create'), 'roles'=>array('createNews'), ), array('allow', 'actions'=>array('delete'), 'roles'=>array('deleteNews'), ), array('allow', 'actions'=>array('view'), 'roles'=>array('readNews'), ), array('allow', 'actions'=>array('update'), 'roles'=>array('updateNews'), ), ); } ... } 

AccessRules फ़ंक्शन में , हम 4 नियम निर्दिष्ट करते हैं, जिनमें से प्रत्येक एक सरणी है। जहां क्रियाएँ कुंजी इंगित करती है कि हम किन क्रियाओं के लिए नियम लागू करते हैं, और भूमिकाएँ किन भूमिकाओं के लिए महत्वपूर्ण हैं।

यह ध्यान दिया जाना चाहिए कि इस तथ्य के बावजूद कि कुंजी को 'भूमिका' कहा जाता है, आप वहां किसी भी प्राधिकरण तत्व में प्रवेश कर सकते हैं, चाहे वह एक ऑपरेशन हो या एक कार्य हो। लेकिन जैसा कि हम सभी जानते हैं, नियंत्रकों में हमें केवल संचालन की जांच करनी चाहिए, यही कारण है कि वे ऊपर के उदाहरण में अंकित हैं।

यह फ़िल्टर हमें कार्रवाई में "पास-थ्रू" कोड की कई लाइनों से छुटकारा पाने में मदद करता है। हालाँकि, एक समस्या है: हमें वर्तमान समाचार को 'updateNews' में प्रसारित करने की आवश्यकता है ताकि अपडेट में परिभाषित bizRnNews सही तरीके से काम करे।

यह समझने के लिए कि आप फ़िल्टर में पैरामीटर कैसे पास कर सकते हैं, मुझे फ्रेमवर्क कोड में जाना पड़ा और वहां झांकना पड़ा। सौभाग्य से, संस्करण 1.1.11 से ऐसा अवसर दिखाई दिया।

मापदंडों को पारित करने के लिए, आपको इस तरह एक नियम लिखना होगा:

 'roles'=>array('newsUpdate'=>array('news'=>$news)) 

हालांकि, समस्याएं खत्म नहीं होती हैं। फ़िल्टर किसी भी कार्रवाई से पहले चलता है, जिसका अर्थ है कि हमने अभी तक एक समाचार वस्तु नहीं बनाई है जिसे हम प्रसारित कर सकते हैं।

समाधान निम्नलिखित दृष्टिकोण हो सकता है:

 protected $model; public function accessRules() { return array( ... array('allow', 'actions' => array('update'), 'roles' => array( 'updateNews' => array( 'news' => $this->news )), ), ... ); } public function getNews() { if ($this->actionParams['id']) { return $this->loadModel($this->actionParams['id']); } } public function loadModel($id) { if ($this->model === null) $this->model = News::model()->findByPk($id); if ($this->model === null) throw new CHttpException(404, 'The requested page does not exist.'); return $this->model; } 

यहां मैं समाचार क्षेत्र के लिए एक गेट्टर बनाता हूं, जिसमें मुझे लोडमॉडल फ़ंक्शन के माध्यम से समाचार मॉडल मिलता है। लेकिन कई बार डेटाबेस को खींचने के लिए नहीं (शुरुआत में जब अधिकारों की जांच करते हुए, और फिर कार्रवाई में ही), मैंने एक निजी क्षेत्र $ मॉडल बनाया, जिसमें मॉडल को कैश किया गया था। और अगली बार जब मैं लोडमॉडल फ़ंक्शन का उपयोग करता हूं, तो मॉडल संपत्ति से प्राप्त किया जाएगा, और आधार से नहीं।

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

RBAC Yii और LDAP

LDAP लाइटवेट डायरेक्ट्री एक्सेस प्रोटोकॉल है, "एक लाइटवेट डायरेक्ट्री एक्सेस प्रोटोकॉल," विकिपीडिया हमें बताता है। हमारे उपयोगकर्ता नाम और पासवर्ड का उपयोग करके कॉर्पोरेट नेटवर्क से उपयोगकर्ताओं को अधिकृत करने के लिए, हमारे मामले में, हम ActiveDirectory निर्देशिका तक पहुँच प्राप्त करेंगे।

PHP में अंतर्निहित LDAP समर्थन है, और इसलिए आपको कुछ भी आविष्कार नहीं करना है, और कई तैयार घटक हैं जो निर्देशिकाओं तक पहुंचने के लिए एक सुविधाजनक इंटरफ़ेस प्रदान करते हैं।

मैंने adLdap घटक का उपयोग किया, जैसा कि इसे विशेष रूप से ActiveDirectory के लिए डिज़ाइन किया गया है, यह एक सरल और सुविधाजनक OOP API प्रदान करता है, और इसके साथ काम करना अच्छा है।

आरंभ करने के लिए, मैंने एक एप्लिकेशन घटक के रूप में Yii को adLdap से जोड़ा, अर्थात:

 //protected/config/main.php 'components' => array( ... 'ldap' => array( 'class' => 'LdapComponent', 'baseDn' => 'DC=example,DC=org', //example.org 'accountSuffix' => '@example.org', 'domainControllers' => array('dc.example.org'), 'adminUsername' => 'username', 'adminPassword' => 'password' ), .. ) 

LdapComponent वर्ग ही:

 //protected/components/LdapComponent.php Yii::import('application.vendors.adLDAP.adLDAP'); class LdapComponent extends adLDAP { public $baseDn; public $accountSuffix; public $domainControllers; public $adminUsername; public $adminPassword; public function __construct() { } public function init() { parent::__construct(); } } 

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

इसके अलावा, हम इस घटक का उपयोग Yii में अन्य सभी की तरह कर सकते हैं:

 Yii::app()->ldap 

LDAP का उपयोग करते हुए प्राधिकरण के लिए, आपको Yii में प्राधिकरण के लिए आवश्यक मानक घटक बनाने होंगे: UserIdentity और WebUser :

 //protected/components/LdapIdentity.php class LdapIdentity extends CUserIdentity { protected $_id; /** * Authenticates a user via LDAP. * @return boolean whether authentication succeeds. */ public function authenticate() { $ldap = Yii::app()->ldap; $result = $ldap->authenticate($this->username, $this->password); $ldapUserInfo = $ldap->user()->infoCollection($this->username, array("mail", "displayname")); $this->setState('fullname', $ldapUserInfo->displayname); $this->setState('email', $ldapUserInfo->mail); if (!$result) { $this->errorCode = self::ERROR_USERNAME_INVALID; } else { $dbUser = User::model()->findByAttributes(array('ldap' => $this->username)); if (!$dbUser) { $dbUser = new User(); $dbUser->ldap = $this->username; $dbUser->save(); } $this->_id = $dbUser->primaryKey; $this->errorCode = self::ERROR_NONE; } return !$this->errorCode; } public function getId() { return $this->_id; } } 

उपरोक्त कोड में, हम अपने प्राधिकरण तर्क को लागू करने के लिए CUserIdentity वर्ग की प्रामाणिक विधि को फिर से परिभाषित करते हैं। हम ADL के माध्यम से AD में इस उपयोगकर्ता को अधिकृत करने का प्रयास कर रहे हैं, और यदि सफल हो, तो हम उसका नाम और ईमेल स्थायी भंडारण में डाल देंगे।

LDAP के अलावा, मैंने डेटाबेस में उपयोगकर्ताओं के बारे में अतिरिक्त जानकारी रखने का फैसला किया, इसलिए सफल प्राधिकरण के बाद, यह जाँच की जाती है: क्या इस उपयोगकर्ता के लिए डेटाबेस में पहले से ही एक पंक्ति है, और यदि नहीं, तो यह बनाया गया है।

 //protected/components/LdapUser.php class LdapUser extends CWebUser { protected $_groups = null; protected $_model; /** * * @return type */ public function getGroups() { if ($this->_groups === null) { if ($user = $this->getModel()) { $this->_groups = Yii::app()->ldap->user()->groups($user->ldap); } } return $this->_groups; } /** * * @return User */ public function getModel() { if (!$this->isGuest && $this->_model === null) { $this->_model = User::model()->findByPk($this->id); } return $this->_model; } } 

LdapUser वर्ग मानक से लगभग अलग नहीं है, हमारे लिए महत्वपूर्ण है सिवाय LdapUser :: getGroups () के। यह फ़ंक्शन, जैसा कि आप अनुमान लगा सकते हैं, इस उपयोगकर्ता के सभी समूहों के AD से वापस आता है।

मैंने Yii अनुप्रयोग में ActiveDirectory भूमिकाओं में उपयोगकर्ता समूह बनाने का निर्णय लिया।
यानी हम विशिष्ट उपयोगकर्ताओं को भूमिकाएँ नहीं सौंपेंगे, लेकिन समूहों को। और AD के माध्यम से किस समूह को किसके केंद्र में रखा जाएगा।
यह कॉर्पोरेट पोर्टलों और अन्य आंतरिक संसाधनों में बहुत सुविधाजनक है, जैसा कि प्रिंटर, फ़ोल्डर्स और अन्य कार्यालय के बुनियादी ढांचे के अधिकारों के साथ, उपयोगकर्ता को तुरंत कॉर्पोरेट वेबसाइट में अनुभागों के अधिकार दिए जाएंगे। इसी समय, आईटी विभाग के विशेषज्ञों को कुछ भी समझाने की आवश्यकता नहीं है, वे बस अपना काम "हमेशा की तरह" करते हैं।

उपयोगकर्ताओं को भूमिकाएँ सौंपने के लिए, मैंने CPhpAuthManager वर्ग को फिर से परिभाषित किया:

 class PhpAuthManager extends CPhpAuthManager { public function init() { //      auth.php   config  if ($this->authFile === null) { $this->authFile = Yii::getPathOfAlias('application.config.auth') . '.php'; } parent::init(); //          guest. if (!Yii::app()->user->isGuest) { //    AD     $existingRoles = $this->getRoles(); if (Yii::app()->user->groups) { foreach (Yii::app()->user->groups as $group) { if ($existingRoles[$group]) { $this->assign($group, Yii::app()->user->id); } } } } } } 

ऊपर दिए गए कोड में, हम उन समूहों की सूची लेते हैं, जिनमें उपयोगकर्ता है, जाँच करें: क्या उसी नाम की भूमिका मौजूद है, और यदि ऐसा है, तो उपयोगकर्ता को भूमिका सौंपें।

LDAP के साथ एक उदाहरण प्राधिकरण कॉन्फ़िगरेशन फ़ाइल इस तरह दिखाई देती है:

  ... /************************************ ***************ROLES**************** ************************************/ 'newsReader' => array( 'type' => CAuthItem::TYPE_ROLE, 'description' => '', 'bizRule' => NULL, 'data' => NULL, 'children' => array( 0 => 'readNews', ), ), 'newsAuthor' => array( 'type' => CAuthItem::TYPE_ROLE, 'description' => '', 'bizRule' => NULL, 'data' => NULL, 'children' => array( 'newsReader', 'createNews', 'updateOwnNews', 'deleteOwnNews' ), ), 'newsManager' => array( 'type' => CAuthItem::TYPE_ROLE, 'description' => '', 'bizRule' => NULL, 'data' => NULL, 'children' => array( 'newsReader', 'createNews', 'updateNews', 'deleteNews', ), ), // 'requestCreator' => array( 'type' => CAuthItem::TYPE_ROLE, 'description' => '', 'bizRule' => NULL, 'data' => NULL, 'children' => array( 0 => 'createRequest', ), ), 'requestManager' => array( 'type' => CAuthItem::TYPE_ROLE, 'description' => '', 'bizRule' => NULL, 'data' => NULL, 'children' => array( 'createRequest', 'viewRequests', 'manageRequests', ), ), /************************************ **********ROLES ASSIGMENTS********** ************************************/ 'developers' => array( 'type' => CAuthItem::TYPE_ROLE, 'description' => '', 'bizRule' => NULL, 'data' => NULL, 'children' => array( 'newsManager', 'requestManager', ), ), 'departamentBoss'=> array( 'type' => CAuthItem::TYPE_ROLE, 'description' => '', 'bizRule' => NULL, 'data' => NULL, 'children' => array( 'requestCreator' , ), ), 

रोल अनुभाग में, हम "मध्यवर्ती" भूमिकाओं का वर्णन करते हैं। उसके बाद, रोल असेंबल्स अनुभाग में, हम AD से समूहों का वर्णन करते हैं, और उन्हें मध्यवर्ती भूमिकाएँ सौंपते हैं।

उपरोक्त विन्यास को इस तरह पढ़ा जा सकता है:
डेवलपर्स समूह के लिए, समाचार (newsManager) और एप्लिकेशन (requestManager) के साथ सभी क्रियाएं उपलब्ध होंगी, और डिपार्चरबॉस समूह के लिए, केवल एप्लिकेशन का निर्माण उपलब्ध होगा।

निष्कर्ष

यदि सही तरीके से उपयोग किया जाए तो Yii में भूमिका तंत्र वास्तव में लचीला है।
भविष्य की योजनाओं में GUI भूमिका प्रबंधन समाधान का निर्माण या अनुकूलन शामिल है यहां तक ​​कि कई कार्यों के साथ, सिस्टम भ्रमित हो जाता है, और लेखन की मात्रा अनुचित है।
मैं सभी उपयोगकर्ताओं से चर्चा करने का आग्रह करता हूं: उन्होंने Yii परियोजनाओं में अधिकार प्रबंधन प्रणाली को कैसे लागू किया, और व्यक्तिगत अनुभव से क्या सुझाव दूसरों के लिए उपयोगी हो सकते हैं?

और क्या पढ़ें:

• Yii आधिकारिक गाइड
• किसी अन्य व्यक्ति से अधिकारों + अनुभव का पदानुक्रम कैसे काम करता है, इस पर एक अच्छा लेख
• मंच पर चर्चा, जिसमें से एक समय में मैंने बहुत सी उपयोगी चीजें सीख लीं (पढ़ें क्रेकोडर पोस्ट)
• विकिपीडिया पर LDAP
• AdLdap गाइड