यह पक्का करने के लिए कि खोज के नतीजों में सिर्फ़ वे उपयोगकर्ता किसी आइटम को देख पाएं जिनके पास उसका ऐक्सेस है, एंटरप्राइज़ रिपॉज़िटरी से आइटम को उनकी ऐक्सेस कंट्रोल लिस्ट (एसीएल) के साथ इंडेक्स करें. आपको रिपॉज़िटरी के लिए एसीएल मॉडल बनाने होंगे. साथ ही, आइटम इंडेक्स करते समय उन्हें शामिल करना होगा. Content Connector SDK टूल, ज़्यादातर रिपॉज़िटरी के एएसएल को मॉडल करने के तरीके उपलब्ध कराता है.
एसीएल बनाना
एसीएल बनाने की प्रोसेस में दो चरण होते हैं:
- ACL क्लास में स्टैटिक तरीकों का इस्तेमाल करके,
Principalबनाएं. - प्रिंसिपल का इस्तेमाल करके एसीएल बनाने के लिए,
Acl.Builderक्लास का इस्तेमाल करें.
इस दस्तावेज़ में, ACL को मॉडल बनाने और उन्हें बनाने से जुड़ी अवधारणाओं के बारे में बताया गया है. जैसे, इनहेरिटेंस और कंटेनमेंट.
बाहरी आईडी का इस्तेमाल करके प्रिंसिपल बनाना
Google Cloud Search के लिए, उपयोगकर्ताओं और ग्रुप को Google के ईमेल पतों पर रीडायरेक्ट करना ज़रूरी है. रिपॉज़िटरी आइटम को इंडेक्स करते समय, कॉन्टेंट कनेक्टर के पास ये ईमेल पते नहीं हो सकते. हालांकि, Content Connector SDK की मदद से किसी आइटम को इंडेक्स करने के लिए, ईमेल पते के बजाय बाहरी आईडी (ऐसा आईडी जो किसी उपयोगकर्ता या ग्रुप को रिपॉज़िटरी आइटम ऐक्सेस करने की अनुमति देता है) का इस्तेमाल किया जा सकता है. बाहरी आईडी वाले प्रिंसिपल बनाने के लिए, getUserPrincipal या getGroupPrincipal तरीके का इस्तेमाल करें. ACL क्लास में, Principal ऑब्जेक्ट बनाने के लिए कई अन्य स्टैटिक मेथड शामिल हैं.
किसी आइटम की पहचान को फिर से मैप करने के बाद, आपको आइटम को फिर से इंडेक्स करना होगा, ताकि नई पहचान लागू हो सके. ज़्यादा जानकारी के लिए, रीमैपिंग आइडेंटिटी देखें.
एसीएल इनहेरिटेंस
एसीएल इनहेरिटेंस का मतलब है किसी आइटम और उपयोगकर्ता के लिए अनुमति. यह अनुमति, आइटम और उसकी इनहेरिटेंस चेन के एसीएल को मिलाकर तय की जाती है. अनुमति देने या न देने से जुड़े फ़ैसलों के नियम, रिपॉज़िटरी और आइटम की प्रॉपर्टी पर निर्भर करते हैं.
इनहेरिटेंस सेट करना
हर आइटम के लिए, सीधे तौर पर अनुमति दिए गए प्रिंसिपल और सीधे तौर पर अनुमति नहीं दिए गए प्रिंसिपल हो सकते हैं. इन्हें setReaders और setDeniedReaders तरीकों का इस्तेमाल करके तय किया जाता है. सीधे तौर पर अनुमति दिया गया प्रिंसिपल, एसीएल में पहचाना गया ऐसा उपयोगकर्ता होता है जिसके पास किसी आइटम को सीधे तौर पर ऐक्सेस करने की अनुमति होती है. एसीएल में जिस उपयोगकर्ता को किसी आइटम का ऐक्सेस नहीं दिया गया है उसे सीधे तौर पर ऐक्सेस से रोका गया प्रिंसिपल कहा जाता है.
setInheritFrom तरीके का इस्तेमाल करके, किसी आइटम के लिए अन्य ऐप्लिकेशन से मिली अनुमतियां और अन्य ऐप्लिकेशन से मिली अनुमतियां अस्वीकार की गई हैं को भी इनहेरिट किया जा सकता है. जिस प्रिंसिपल को अनुमति मिली है वह एसीएल इनहेरिटेंस के ज़रिए किसी आइटम को ऐक्सेस कर सकता है. जिस प्रिंसिपल को सीधे तौर पर अनुमति नहीं दी गई है उसे इनहेरिटेंस के ज़रिए ऐक्सेस करने की अनुमति नहीं दी जाती.
पहली इमेज में, प्रिंसिपल को इनहेरिट करने के लिए setInheritFrom तरीके का इस्तेमाल करने का तरीका दिखाया गया है.
setInheritFrom
तरीका.पहली इमेज में, ऐक्सेस कंट्रोल की इन सुविधाओं को दिखाया गया है:
- उपयोगकर्ता 1, आइटम A का सीधे तौर पर अनुमति दिया गया प्रिंसिपल है.
- उपयोगकर्ता 2 को आइटम B को सीधे तौर पर ऐक्सेस करने की अनुमति है.
- आइटम B को आइटम A की ACL मिलती है.
इन कंट्रोल के आधार पर, ऐक्सेस के नियम ये हैं:
- उपयोगकर्ता 1 को आइटम B के लिए, सीधे तौर पर अनुमति नहीं दी गई है. हालांकि, उसे आइटम A से अनुमति मिली है.
- उपयोगकर्ता 2, आइटम A का इनडायरेक्ट प्रिंसिपल नहीं है.
इनहेरिटेंस का टाइप सेट करना
अगर आपने setInheritFrom तरीके का इस्तेमाल करके इनहेरिटेंस सेट किया है, तो आपको setInheritanceType तरीके का इस्तेमाल करके इनहेरिटेंस का टाइप सेट करना होगा. इनहेरिटेंस टाइप से यह तय होता है कि चाइल्ड ACL, पैरंट ACL के साथ कैसे जुड़ता है. Acl.InheritanceType तीन तरह के होते हैं:
BOTH_PERMIT- सिर्फ़ तब ऐक्सेस दें, जब बच्चे और माता-पिता/अभिभावक, दोनों की एसीएल (ऐक्सेस कंट्रोल लिस्ट) में इसकी अनुमति हो.CHILD_OVERRIDE- अगर कोई टकराव होता है, तो बच्चे के एसीएल को माता-पिता के एसीएल पर प्राथमिकता दी जाती है. अगर माता-पिता किसी उपयोगकर्ता को बच्चे का ऐक्सेस नहीं देते हैं, तो भी वह उपयोगकर्ता बच्चे का ऐक्सेस पा सकता है. इसके अलावा, अगर माता-पिता किसी उपयोगकर्ता को बच्चे का ऐक्सेस देते हैं, तो भी उसे बच्चे का ऐक्सेस नहीं मिल सकता.PARENT_OVERRIDE- अगर पैरंट और चाइल्ड एसीएल में कोई टकराव होता है, तो पैरंट एसीएल को प्राथमिकता दी जाती है.
Cloud Search, ACL इनहेरिटेंस चेन का आकलन लीफ़ से रूट तक करता है. जांच की शुरुआत बच्चे और उसके माता-पिता से होती है. इसके बाद, यह जांच मुख्य माता-पिता तक पहुंच सकती है.
उदाहरण के लिए, अगर बच्चा CHILD_OVERRIDE का इस्तेमाल करता है और उपयोगकर्ता के पास ऐक्सेस है, तो Cloud Search को माता-पिता का आकलन करने की ज़रूरत नहीं है. हालांकि, अगर बच्चा PARENT_OVERRIDE या BOTH_PERMIT का इस्तेमाल करता है, तो Cloud Search, चेन में ऊपर की ओर आकलन करना जारी रखता है.
आइटम को अलग करना और मिटाना
किसी आइटम को इंडेक्स करते समय, उसे कंटेनर के तौर पर लेबल किया जा सकता है. इसके लिए, IndexingItemBuilder क्लास के setContainer तरीके का इस्तेमाल करें. इस संबंध से, फ़िज़िकल हैरारकी तय होती है और यह पक्का किया जाता है कि डेटा सही तरीके से मिटाया गया हो. किसी कंटेनर को मिटाने पर, उसमें मौजूद आइटम भी मिट जाते हैं.
कंटेनमेंट के संबंध, ACL इनहेरिटेंस के नियमों से अलग होते हैं. उदाहरण के लिए, किसी फ़ोल्डर में मिटाने के लिए कोई फ़ाइल हो सकती है, लेकिन फ़ाइल किसी दूसरे फ़ोल्डर से एसीएल इनहेरिट कर सकती है. किसी फ़ोल्डर को मिटाने से, उन आइटम को नहीं मिटाया जाता है जो उसके एएलसी को इनहेरिट करते हैं. हालांकि, ऐसा तब होता है, जब वे आइटम भी उसकी कंटेनमेंट हैरारकी में शामिल न हों.
दूसरी इमेज में, ऐक्सेस कंट्रोल की इन सुविधाओं को दिखाया गया है:
- उपयोगकर्ता 1, आइटम A का सीधे तौर पर अनुमति दिया गया प्रिंसिपल है.
- उपयोगकर्ता 2 को आइटम B को सीधे तौर पर ऐक्सेस करने की अनुमति है.
- उपयोगकर्ता 3 को आइटम C को सीधे तौर पर ऐक्सेस करने की अनुमति है.
- आइटम C को आइटम A की ACL मिलती है.
- आइटम B, आइटम A को अपने कंटेनर के तौर पर दिखाता है.
- आइटम C, आइटम B को अपने कंटेनर के तौर पर दिखाता है.
इन कंट्रोल के आधार पर, ऐक्सेस के नियम ये हैं:
- अप्रत्यक्ष ऐक्सेस,
setInheritFromतरीके से मिलता है. उपयोगकर्ता 1, आइटम C को ऐक्सेस कर सकता है, क्योंकि यह आइटम A से इनहेरिट किया गया है. - अप्रत्यक्ष ऐक्सेस, कंटेनमेंट से नहीं मिलता. उपयोगकर्ता 2, आइटम C को ऐक्सेस नहीं कर सकता.
setInheritFrom तरीका.एसीएल इनहेरिटेंस को कंटेनमेंट से अलग करने पर, कई स्ट्रक्चर मॉडल किए जा सकते हैं.
किसी आइटम को मिटाने पर:
- मिटाए गए आइटम वाला कोई भी आइटम खोजा नहीं जा सकता. साथ ही, उसे मिटाने के लिए शेड्यूल कर दिया जाता है.
setInheritFromमें मिटाए गए आइटम की जानकारी देने वाला कोई भी आइटम खोजा नहीं जा सकेगा.
अगर कोई संसाधन, मिटाए गए किसी आइटम के लिए setInheritFrom का इस्तेमाल करता है, लेकिन उसमें कोई कंटेनर सेट नहीं है या उसकी हैरारकी में मिटाए गए आइटम शामिल नहीं हैं, तो आइटम डेटा सोर्स में बना रहता है.
इसे मिटाने की ज़िम्मेदारी आपकी है.
तीसरी इमेज में, आइटम के क्रम को मिटाने का उदाहरण दिखाया गया है.
इमेज 3 में, इन ऐक्सेस कंट्रोल को दिखाया गया है:
- उपयोगकर्ता 1, आइटम A का सीधे तौर पर अनुमति दिया गया प्रिंसिपल है.
- उपयोगकर्ता 2, आइटम D का सीधे तौर पर अनुमति दिया गया प्रिंसिपल है.
- आइटम D और E, दोनों को आइटम A से इनहेरिट किया गया है.
- आइटम D, आइटम A को अपने कंटेनर के तौर पर दिखाता है.
- आइटम A और E, रूट-लेवल के आइटम हैं.
कंटेनर के रेफ़रंस के ज़रिए, मिटाए गए आइटम को भी मिटा दिया जाता है. आइटम A को मिटाने पर:
setInheritFromरेफ़रंस के सभी डिसेंडेंट का ऐक्सेस खत्म हो जाता है.- उपयोगकर्ता अब आइटम A को ऐक्सेस नहीं कर सकते.
- आइटम D को मिटा दिया जाता है और इसे ऐक्सेस नहीं किया जा सकता.
- आइटम E को मिटाया नहीं जाता, लेकिन यह ऐक्सेस नहीं किया जा सकता और न ही इसे खोजा जा सकता है.