DIY ACL। एक सरल अभिगम नियंत्रण प्रणाली के विकास और लेखन का इतिहास

हमारे पास समर्थन में एक आंतरिक परियोजना है जहां एक बहुत ही असुविधाजनक पहुंच नियंत्रण प्रणाली का उपयोग किया जाता है।

तथाकथित ए.सी.एल.

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

खैर, जब उपयोगकर्ता शिकायतें एक महत्वपूर्ण बिंदु पर पहुंचने लगीं, तो मुझे सिस्टम को सरल या फिर से तैयार करने का काम सौंपा गया।



मैंने मौजूदा कोड को देखा, मुझे पुनः काम करने की कोई इच्छा नहीं हुई, और एक तैयार समाधान खोजने का फैसला किया। मुझे तुरंत कहना चाहिए - मैं "साइकिल" का एक बड़ा प्रतिद्वंद्वी हूं, इससे पहले कि मैं कुछ लिखूं, मैं हमेशा तैयार-तैयार और उपयुक्त समाधान खोजने की कोशिश करता हूं। तो यह समय था, लेकिन कोई फायदा नहीं हुआ। उदाहरण के लिए, PEAR संग्रह में कई समाधान हैं, लेकिन मैंने उपयुक्त एक का चयन नहीं किया। बहुत सारे कोड को हटा दिया गया है (हम PHP संस्करण 5.3 का उपयोग कर रहे हैं), इसलिए यह स्वयं एसीएल लिखने का निर्णय लिया गया था।





मैं इस बारे में बात करना चाहता हूं। मैं कोड के उदाहरण न्यूनतम देने की कोशिश करूंगा - मैं आपको केवल काम के विचार और सिद्धांत बताता हूं।

लेकिन जो लोग चाहते हैं वे सभी पुस्तकालय कोड upd-2011 ( utf8 ) ले सकते हैं , देखें और, यदि वांछित है, तो इसका उपयोग करें।



शुरू करने के लिए, मैंने अपने काम के सामान्य सिद्धांत को अपने लिए समझने का फैसला किया, जिसके लिए मैंने वास्तविक दुनिया के साथ ऐसी समानता की कल्पना की:



पीपीसी। (चौकी)

बाबुस्का बैठी है, उसके सामने एक पत्रिका है। पत्रिका में उन कमरों की एक सूची है जहाँ आगंतुक चौकी से जाते हैं।

वास्तव में, सुविधा में बहुत सारे परिसर हैं, जबकि पत्रिका में दादी उनके पास कम हैं। केवल वही हैं जहां आपको पहुंच को नियंत्रित करने की आवश्यकता है।

प्रत्येक कमरा जो पत्रिका में है, उन आगंतुकों की एक सूची है जिन्हें प्रवेश करने की अनुमति है,

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

बाबुस्का, इस पत्रिका द्वारा निर्देशित, और आगंतुकों के हाथों में दस्तावेज़, सुविधा तक पहुंच को नियंत्रित करता है।

यह सिस्टम का क्लाइंट हिस्सा है।



अब प्रशासनिक हिस्सा:

समय-समय पर, सुरक्षा का प्रमुख चौकी पर आता है। वह पत्रिका में बदलाव करता है।

भविष्य की प्रणाली के लिए मेरे द्वारा निर्धारित आवश्यकताएँ:

1. संसाधनों के अधिकार दिए जा सकते हैं: उपयोगकर्ता, उपयोगकर्ता, समूह, समूहों को।
2. बिंदु संख्या 1 से, यह इस प्रकार है कि उपयोगकर्ता समूहों में हो सकते हैं।
3. सिस्टम (कम से कम पहले संस्करण में) सबसे सरल होगा, जिसका अर्थ है कि यह या तो एक निश्चित उपयोगकर्ता को संसाधन का अधिकार देता है या नहीं।
4. संसाधन के अधिकार विरासत में मिले।
   
   यही है, यदि संसाधन, उदाहरण के लिए कहो। Someitem का स्वामित्व केवल उपयोगकर्ता Pupkin के पास है, तो स्वचालित रूप से वह और केवल वह (लेकिन धारा 5 देखें) संसाधनों तक पहुंच है:
   
   
   • example.com/someitem/item2
   • example.com/someitem/item3 आदि।
   
   
   लेकिन केवल अगर कुछ अधीनस्थ संसाधनों के लिए अधिकारों को फिर से परिभाषित नहीं किया जाता है। यदि अधिकारों को ओवरराइड किया जाता है, तो उन्हें पेड़ में एक नए तरीके से विरासत में मिला है।
   
   
5. सिस्टम में अनिवार्य (सिस्टम) समूह होने चाहिए:
   
   
   • अनधिकृत उपयोगकर्ता
   • अधिकृत उपयोगकर्ता
   • सुपर उपयोगकर्ता।
   
   
   इसके अलावा, सुपरसुअर के पास इन आवश्यकताओं के पिछले पैराग्राफ से पुपकिन के संसाधनों सहित किसी भी संसाधन का अधिकार है।
   
   
6. ठीक है, पैराग्राफ 4 के अनुसार, संसाधन अधीनस्थ और पैतृक हो सकते हैं।
   
   यहाँ संसाधन के अनुसार, सामान्य तौर पर, मेरा मतलब है कि साइट पर कोई भी पथ।
   
   यदि यह एक पथ में अंतिम तत्व को स्लैश (/) तक मिटा देता है, तो एक मूल संसाधन प्राप्त किया जा सकता है।
   
   उदाहरण के लिए, एक ही उदाहरण. com/someitem/item2 - erase / item2 - हमें अभिभावक मिलते हैं:
   
   - example.com/someitem
   
   
7. पिछले पैराग्राफ से यह इस प्रकार है कि सभी साइट संसाधनों के लिए एक सामान्य पूर्वज होना चाहिए - यह मूल संसाधन है।
   
   इस मामले में, यह example.com है , लेकिन हम इसे '/' के रूप में संगृहीत करेंगे, और यह सिस्टम, अर्थात सिस्टम के लिए भी अनिवार्य होगा।
   
   
8. सिस्टम तत्वों (उपयोगकर्ता समूहों और रूट संसाधन) को सिस्टम से हटाया नहीं जा सकता है।
9. क्लाइंट कोड में उपयोग के लिए सिस्टम यथासंभव सरल होना चाहिए।
10. शुरुआत के लिए, मेरी राय में पर्याप्त।

आवश्यकताओं को परिभाषित किया जाता है, डेटाबेस की संरचना स्पष्ट हो जाती है:

टेबल्स: (न्यूनतम आवश्यक फ़ील्ड निर्दिष्ट)

उपयोगकर्ताओं

+ --------------------------

+ आईडी | पहला नाम

+ --------------------------



समूहों

+ --------------------------

+ आईडी | पहला नाम

+ --------------------------



साधन

+ --------------------------

+ आईडी | पहला नाम

+ --------------------------



समूहों में उपयोगकर्ता

+ -------------------------------------------------

+ आईडी | समूह आईडी | उपयोगकर्ता आईडी

+ -------------------------------------------------



संसाधनों के लिए उपयोगकर्ता अधिकार

+ -------------------------------------------------

+ आईडी | संसाधन आईडी | उपयोगकर्ता आईडी

+ -------------------------------------------------



संसाधन समूह के अधिकार

+ -------------------------------------------------

+ आईडी | संसाधन आईडी | समूह आईडी

+ -------------------------------------------------



MySQL के लिए डेटाबेस स्कीमा डॉक्स डायरेक्टरी में लाइब्रेरी आर्काइव में है।



यहां यह तुरंत निर्धारित करना आवश्यक है कि मैंने अलग से प्राधिकरण प्रणाली लिखी थी, पहले मैंने PEAR :: Auth का उपयोग किया था, और मैंने इसके लिए ACL किया, लेकिन PEAR के मौजूदा संस्करण में :: प्रामाणिक बहुत सारे आउटडेटेड हैं (PHP 5.3 के लिए) कोड, इसलिए लाइब्रेरी के लिए प्राधिकरण ने अपना लिखने का फैसला किया। यह सामान्य रूप से सरल निकला। मैं इस लेख के ढांचे में इसका वर्णन नहीं करूंगा। मैं केवल यह कह सकता हूं कि मैंने प्राधिकरण प्रणाली से खुद को अलग करने की कोशिश की, किसी भी प्रणाली का उपयोग किया जा सकता है, केवल शर्त यह है कि इसे IAuth इंटरफ़ेस को लागू करना होगा (यह वर्णित पुस्तकालय के संग्रह में है)



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



यह निम्नानुसार है कि सिस्टम को तुरंत डेटा स्टोरेज से अलग किया जाना चाहिए, और एडेप्टर के माध्यम से डेटा के साथ काम करना चाहिए।



इसलिए, - एडॉप्टर इंटरफ़ेस का वर्णन करना आवश्यक है, और अभी के लिए एक एडेप्टर लागू करें, MySQL के लिए कहें।

एडॉप्टर के लिए इंटरफ़ेस कुछ इस तरह है:

// --       // --        /** *   . *     ,     *     * * @param string $orderBy     . * default:    * @param bool $getUsers      . * @param bool $getGroups      . * * @param bool $where      * * @return array  . * [    ] * [   ] * */ public function getResources($orderBy=null, $getUsers=true, $getGroups=true, $where=false); /** *    * * @param string $orderBy    . *   -   * @param bool $getUsers     * @param bool $getResources This     * @return array      * (      *  ) * */ public function getGroups($orderBy=null, $getUsers=false, $getResources=false); /** *    * * @param int $groupId Id  * @return array     *   * */ public function getUsersForGroup($groupId); /** *    * * @param int $groupId Id  * @return array     *   * */ public function getResourcesForGroup($groupId);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

और इतने पर और आगे।

यह स्पष्ट होना चाहिए कि एडेप्टर से किन कार्यों की आवश्यकता होगी।

MySQL के लिए एडॉप्टर में एक विधि का एक उदाहरण कार्यान्वयन

  public function getGroups($orderBy=null, $getUsers=false, $getResources=false) { if ( empty($orderBy) ) { $orderBy = $this->tables['group']['namecol']; } $query = "SELECT * FROM {$this->tables['group']['name']} ORDER BY {$orderBy}"; $res = $this->_connection->query($query); if ( !$res ) { return false; } $groups = $res->fetchAll(PDO::FETCH_ASSOC); if ( !$getUsers && !$getResources ) { return $groups; } foreach ($groups as & $_g) { if ( $getUsers ) { $_g['users'] = $this->getUsersForGroup($_g[ $this->tables['group']['idcol'] ]); } if ( $getResources ) { $_g['resources'] = $this->getResourcesForGroup($_g[ $this->tables['group']['idcol'] ]); } } return $groups; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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



1. ग्राहक

2. प्रशासक

ग्राहक का कार्य:

वर्तमान उपयोगकर्ता के लिए अनुरोध किए गए संसाधन के अधिकारों की जांच करें, और या तो उसे एक्सेस दें या "एक्सेस से वंचित" पृष्ठ पर भेजें।

वैसे, एक्सेस की अनुपस्थिति में सिस्टम से बाहर निकलने को अलग-अलग कार्यों में निर्धारित किया जाता है, और कॉन्फ़िगरेशन के दौरान केवल इन कार्यों के नाम सिस्टम में स्थानांतरित किए जाते हैं।

केवल दो कार्यों की आवश्यकता है: लॉगिन पृष्ठ पर भेजें () और पहुंच से वंचित है () ।

वैसे, एक नियम के रूप में, अपनी खुद की परियोजनाओं में मैं आमतौर पर त्रुटियों के लिए एक पृष्ठ 403 और 404 बनाता हूं, "पृष्ठ नहीं मिला"।

मुझे ऐसा लगता है कि यह एक अधिक विश्वसनीय विकल्प है, क्योंकि जब "एक्सेस से वंचित किया जाता है" (403 त्रुटियां) प्रदर्शित करते हैं, तो हम पहले से ही संभावित हमलावर को अतिरिक्त जानकारी प्रदान करते हैं कि "... ऐसा पृष्ठ मौजूद है, केवल आप, वासा, को जाना नहीं है।" "

प्रशासनिक भाग का कार्य:

सिस्टम प्रबंधन।

समूहों, उपयोगकर्ताओं को समूहों, संसाधनों, अधिकारों से जोड़ना, उपरोक्त सभी को हटाना और इसी तरह।

क्लाइंट कोड में सिस्टम का उपयोग करना।

क्लाइंट कोड में सिस्टम का उपयोग बहुत सरलता से किया जाता है, उदाहरण के लिए:



index.php (आवेदन प्रविष्टि बिंदु)

 <?php $acl = new AuthAcl_Client($options); $acl->start(); //    ?>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

यही है, कोड या तो क्लाइंट एप्लिकेशन तक नहीं पहुंचेगा, यदि संसाधन का अनुरोध करने वाले उपयोगकर्ता के पास अधिकार नहीं हैं (उदाहरण के लिए, पृष्ठ 404 प्रदर्शित होता है), या एप्लिकेशन काम करना जारी रखता है।



$ Acl ऑब्जेक्ट के कंस्ट्रक्टर में, हम आवश्यक पैरामीटर पास करते हैं, यह आमतौर पर एक सरणी है, जो सरलतम मामले में पूरी तरह अनुपस्थित हो सकता है, क्योंकि सिस्टम में अपने अधिकांश तत्वों के लिए डिफ़ॉल्ट मान हैं।



लेकिन आमतौर पर पैरामीटर के इस सरणी में ऐसे तत्व होते हैं जैसे:

1. प्राधिकरण फ़ॉर्म में लॉगिन और पासवर्ड दर्ज करने के लिए फ़ील्ड्स के नाम (सिस्टम उन्हें प्राधिकरण प्रणाली को आगे भेजता है)।
2. डेटा एक्सेस करने के लिए एडेप्टर का नाम (उदाहरण के लिए, 'MySQL')
3. डेटाबेस से जुड़ने की जानकारी।
4. उपयोगकर्ताओं, समूहों, संसाधनों, अधिकारों को संग्रहीत करने वाले तालिकाओं के नाम।
5. क्या पासवर्ड एन्क्रिप्ट किया गया है, यदि हां, तो किस तरह से (उदाहरण के लिए, सच, md5)
6. और बाकी सब कुछ जिसे आप कॉन्फ़िगर और कॉन्फ़िगर कर सकते हैं।

प्रारंभ () विधि में, ऐसा कुछ होता है:

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

मैं हमेशा अपने कोड को अधिकतम परीक्षणों में शामिल करने की कोशिश करता हूं, इस बार भी ऐसा ही था। लिखे थे

इकाई परीक्षण (पुरालेख में स्थित), जिसके बाद सभी इच्छित कार्यक्षमता को लागू किया गया था।



यह, सिद्धांत रूप में, मैं सभी के बारे में बात करना चाहता था।

पूरे पुस्तकालय के लिए कोड लेख से जुड़ा हुआ है।

मुझे बहुत खुशी होगी अगर ऐसा अनुभव किसी के लिए उपयोगी हो। प्रस्तावित समाधान की कमजोरियों की आलोचना सुनकर मुझे भी खुशी होगी।



AuthAcl पुस्तकालय कोड (ज़िप संग्रह में)





UPD: 07/31/2011

Utf-8 में संस्करण:

AuthAcl-utf8 लाइब्रेरी कोड