मैप ACL

यह पक्का करने के लिए कि खोज के नतीजों में किसी आइटम को सिर्फ़ वे उपयोगकर्ता देख सकें जिनके पास उसका ऐक्सेस है, आपको एंटरप्राइज़ रिपॉज़िटरी से आइटम को उनकी ऐक्सेस कंट्रोल सूचियों (एसीएल) के साथ इंडेक्स करना चाहिए. आपको अपनी रिपॉज़िटरी के एसीएल को मॉडल करना होगा और रिपॉज़िटरी में आइटम को इंडेक्स करते समय उन एसीएल को शामिल करना होगा. Content Connector SDK टूल, एसीएल के तरीकों का एक बेहतर सेट उपलब्ध कराता है. यह सेट, ज़्यादातर रिपॉज़िटरी के एसीएल को मॉडल करने के लिए काफ़ी असरदार है.

एसीएल (ACL) बनाना

एसीएल बनाने की प्रोसेस दो चरणों में होती है:

1. ACL क्लास में स्टैटिक तरीकों का इस्तेमाल करके, Principal बनाएं.
2. प्रिंसिपल का इस्तेमाल करके ACL बनाने के लिए, Acl.Builder क्लास का इस्तेमाल करें.

इस दस्तावेज़ के बाकी हिस्से में, ऐसे कुछ कॉन्सेप्ट के बारे में बताया गया है जिनके बारे में आपको एसीएल बनाने और उन्हें मॉडल करने के लिए जानना ज़रूरी है. जैसे, इनहेरिटेंस और कंटेनमेंट.

किसी बाहरी आईडी का इस्तेमाल करके प्रिंसिपल बनाना

Google Cloud Search में उपयोगकर्ताओं और ग्रुप के लिए, Google ईमेल पते का इस्तेमाल करना ज़रूरी है. रिपॉज़िटरी आइटम को इंडेक्स करते समय, हो सकता है कि कॉन्टेंट कनेक्टर में ये ईमेल पते न हों. हालांकि, Content Connector SDK टूल की मदद से किसी आइटम को इंडेक्स करने के लिए, ईमेल पते के बजाय किसी भी बाहरी आईडी (आईडी, जो किसी उपयोगकर्ता या ग्रुप को रिपॉज़िटरी आइटम का ऐक्सेस देता है) का इस्तेमाल किया जा सकता है. बाहरी आईडी वाले प्रिंसिपल बनाने के लिए, getUserPrincipal() या getGroupPrincpal() तरीकों का इस्तेमाल करें. ACL क्लास में कई अन्य स्टैटिक तरीके भी हैं, जिनका इस्तेमाल Principal ऑब्जेक्ट बनाने के लिए किया जाता है.

एसीएल इनहेरिटेंस

एसीएल इनहेरिटेंस का मतलब, किसी आइटम और किसी उपयोगकर्ता के लिए अनुमति से है. यह अनुमति, आइटम के एसीएल और उसकी इनहेरिटेंस चेन के एसीएल के कॉम्बिनेशन के नतीजे के आधार पर दी जाती है. अनुमति देने का फ़ैसला लेने के लिए इस्तेमाल किए जाने वाले नियम, रिपॉज़िटरी और आइटम की प्रॉपर्टी पर निर्भर करते हैं.

इनहेरिटेंस सेट करना

हर आइटम में सीधे तौर पर अनुमति वाले प्रिंसिपल और सीधे तौर पर अनुमति न पाने वाले प्रिंसिपल हो सकते हैं. इनके बारे में बताने के लिए, setReaders() और setDeniedReaders() तरीकों का इस्तेमाल किया जाता है. सीधे तौर पर अनुमति पा चुके प्रिंसिपल, एसीएल में पहचाने गए ऐसे उपयोगकर्ता होते हैं जिन्हें किसी खास आइटम का सीधा ऐक्सेस मिलता है. सीधे तौर पर ऐक्सेस न मिलने वाला प्रिंसिपल, एसीएल में ऐसा उपयोगकर्ता होता है जिसके पास किसी खास आइटम का ऐक्सेस नहीं होता.

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

पहले चित्र में दिखाया गया है कि setInheritFrom() तरीके का इस्तेमाल करके, अप्रत्यक्ष रूप से अनुमति वाले और अप्रत्यक्ष रूप से अनुमति न दिए गए प्रिंसिपल को कैसे इनहेरिट किया जाता है.

ऐक्सेस कंट्रोल की जानकारी, पहले चित्र में दी गई है:

• उपयोगकर्ता 1, आइटम A का सीधे तौर पर अनुमति पाया हुआ प्रिंसिपल है.
• उपयोगकर्ता 2, आइटम B का सीधे तौर पर अनुमति वाला प्रिंसिपल है.
• आइटम B को आइटम A का ACL इनहेरिट होता है.

ऐक्सेस कंट्रोल के आधार पर, ऐक्सेस के नियम ये हैं:

• उपयोगकर्ता 1 को आइटम B के प्रिंसिपल के तौर पर साफ़ तौर पर बताने की ज़रूरत नहीं है, ताकि वह आइटम B के लिए, सीधे तौर पर अनुमति वाले प्रिंसिपल के तौर पर काम कर सके. ऐक्सेस इनहेरिट किया जाता है, क्योंकि उपयोगकर्ता 1 को आइटम A के लिए, सीधे तौर पर अनुमति वाले प्रिंसिपल के तौर पर लिस्ट किया गया है और आइटम B को आइटम A से अपना ACL इनहेरिट होता है.
• उपयोगकर्ता 2, आइटम A के लिए, किसी दूसरे प्रिंसिपल के तौर पर अनुमति नहीं पाता.

इनहेरिटेंस का टाइप सेट करना

अगर आपने setInheritFrom() तरीके का इस्तेमाल करके इनहेरिटेंस सेट किया है, तो आपको setInheritanceType() तरीके का इस्तेमाल करके इनहेरिटेंस टाइप सेट करना होगा. इनहेरिटेंस टाइप से यह तय होता है कि बच्चे का एसीएल, उसके माता-पिता के एसीएल के साथ कैसे जुड़ता है. Acl.InheritanceType, इनहेरिटेंस के तीन टाइप लागू करता है:

• BOTH_PERMIT - किसी उपयोगकर्ता को आइटम का ऐक्सेस सिर्फ़ तब देने के लिए, इनहेरिटेंस टाइप को BOTH_PERMIT पर सेट करें, जब चाइल्ड आइटम के ACL और पैरंट के इनहेरिट किए गए आइटम के ACL, दोनों ही उस उपयोगकर्ता को आइटम ऐक्सेस करने की अनुमति देते हों.

• CHILD_OVERRIDE - इनहेरिटेंस टाइप को CHILD_OVERRIDE पर सेट करें, ताकि जब दोनों के बीच विरोध हो, तो चाइल्ड आइटम के ACL को इनहेरिट किए गए पैरंट आइटम के ACL से ज़्यादा प्राथमिकता दी जाए. इसलिए, अगर पैरंट आइटम का एसीएल, उपयोगकर्ता को रीडर के तौर पर ऐक्सेस देने से मना करता है, तो भी उपयोगकर्ता के पास ऐक्सेस रहेगा. हालांकि, इसके लिए ज़रूरी है कि उसके पास चाइल्ड आइटम का ऐक्सेस रीडर के तौर पर हो. इसके उलट, अगर पैरंट आइटम का एसीएल उपयोगकर्ता को ऐक्सेस देता है, तब भी उपयोगकर्ता के पास ऐक्सेस नहीं होता. ऐसा तब होता है, जब उसे चाइल्ड आइटम को पढ़ने की अनुमति न दी गई हो.

• PARENT_OVERRIDE - जब माता-पिता और बच्चे के आइटम के एसीएल में अंतर हो, तो माता-पिता के आइटम के एसीएल को बच्चे के आइटम के एसीएल से ज़्यादा प्राथमिकता देने के लिए, इनहेरिटेंस टाइप को PARENT_OVERRIDE पर सेट करें. इसलिए, अगर चाइल्ड आइटम का एसीएल, उपयोगकर्ता को पाठक के तौर पर ऐक्सेस देने से मना करता है, तो भी उपयोगकर्ता के पास ऐक्सेस रहेगा. बशर्ते, उसके पास पैरंट आइटम का पाठक के तौर पर ऐक्सेस हो. इसके उलट, अगर चाइल्ड आइटम के ACL ने उपयोगकर्ता को ऐक्सेस दिया है, तो भी उपयोगकर्ता के पास ऐक्सेस नहीं होगा. ऐसा तब होता है, जब उसे पैरंट आइटम को पढ़ने की अनुमति न मिली हो.

एसीएल इनहेरिटेंस चेन का आकलन करते समय, अनुमति के फ़ैसले का नतीजा बदल सकता है. Cloud Search, एसीएल इनहेरिटेंस चेन के लिए, लीफ से रूट तक के क्रम में आकलन करता है. खास तौर पर, किसी चेन के लिए एसीएल का फ़ैसला, बच्चे और उसके माता-पिता के साथ किए गए आकलन से शुरू होता है. यह फ़ैसला, रूट पैरंट तक जा सकता है.

उदाहरण के लिए, अगर बच्चे के पास CHILD_OVERRIDE इनहेरिटेंस टाइप है और उपयोगकर्ता के पास बच्चे का ऐक्सेस है, तो Drive को माता-पिता का आकलन करने की ज़रूरत नहीं है. हालांकि, अगर बच्चे के पास PARENT_OVERRIDE या BOTH_PERMIT है, तो Drive, इनहेरिटेंस की जांच करना जारी रखता है.

आइटम को कंटेनमेंट में डालना और मिटाना

किसी आइटम को इंडेक्स करते समय, IndexingItemBuilder क्लास के setContainer() तरीके का इस्तेमाल करके, आइटम को कंटेनर के तौर पर लेबल किया जा सकता है. कंटेनर/कंटेन में मौजूद आइटम के बीच के संबंध से, आइटम की फ़िज़िकल हैरारकी तय होती है. साथ ही, यह पक्का होता है कि आइटम सही तरीके से मिटाए गए हैं. किसी कंटेनर को मिटाने पर, उसमें मौजूद आइटम भी मिट जाते हैं.

कंटेनमेंट रिलेशनशिप, ACL इनहेरिटेंस नियमों से पूरी तरह अलग होते हैं. उदाहरण के लिए, किसी फ़ाइल सिस्टम में मौजूद फ़ाइल को मिटाने के मकसद से, किसी फ़ोल्डर में रखा जा सकता है. हालांकि, उस फ़ाइल को किसी दूसरे फ़ोल्डर से एसीएल इनहेरिट किया जा सकता है. किसी फ़ोल्डर को मिटाने पर, उसमें मौजूद ऐसे आइटम नहीं मिटते जिन्हें उसके एसीएल से इनहेरिट किया गया है. हालांकि, ऐसा तब होता है, जब वे आइटम फ़ोल्डर की कंटेनमेंट हैरारकी में भी शामिल हों.

ऐक्सेस कंट्रोल की जानकारी, दूसरे चित्र में दी गई है:

• उपयोगकर्ता 1, आइटम A का सीधे तौर पर अनुमति वाला प्रिंसिपल है.
• उपयोगकर्ता 2, आइटम B का सीधे तौर पर अनुमति वाला प्रिंसिपल है.
• उपयोगकर्ता 3, आइटम C का सीधे तौर पर अनुमति पाया हुआ प्रिंसिपल है.
• आइटम C को आइटम A का ACL इनहेरिट किया जाता है.
• आइटम B, आइटम A को अपना कंटेनर बताता है.
• आइटम C, आइटम B को अपना कंटेनर बताता है.

ऐक्सेस कंट्रोल के आधार पर, ऐक्सेस के नियम ये हैं:

• इनडायरेक्ट ऐक्सेस, setInheritFrom() तरीके से मिलता है. इसलिए, उपयोगकर्ता 1 आइटम C को ऐक्सेस कर सकता है, क्योंकि आइटम C को आइटम A का एसीएल इनहेरिट किया जाता है.
• आइटम B में मौजूद आइटम C से, आइटम A का ऐक्सेस नहीं मिलता. इसलिए, उपयोगकर्ता 2, आइटम C को ऐक्सेस नहीं कर सकता.

एसीएल इनहेरिटेंस को कंटेनमेंट हैरारकी से अलग करने पर, कई अलग-अलग मौजूदा स्ट्रक्चर बनाए जा सकते हैं.

किसी आइटम को मिटाने पर:

• जिस आइटम में मिटाया गया आइटम शामिल है उसे खोजा नहीं जा सकता. साथ ही, उसे Google के डेटा सोर्स से मिटाने के लिए शेड्यूल कर दिया जाता है.
• setInheritFrom() तरीके का इस्तेमाल करके, मिटाए गए आइटम की जानकारी देने वाले किसी भी आइटम को खोजा नहीं जा सकता.

अगर किसी संसाधन में, setInheritFrom() के तरीके का इस्तेमाल करके मिटाया गया आइटम मौजूद है, लेकिन उसमें setContainer() का इस्तेमाल करके कोई कंटेनर सेट नहीं किया गया है या उसके कंटेनमेंट के लेआउट में कोई मिटाया गया आइटम मौजूद नहीं है, तो वह आइटम और उसका डेटा Google के डेटा सोर्स में बना रहता है. आइटम मिटाने की ज़िम्मेदारी आपकी है.

तीसरे चित्र में, आइटम के लेआउट के हिसाब से मिटाने की सुविधा के काम करने का उदाहरण दिया गया है.

ऐक्सेस कंट्रोल की जानकारी, तीसरे चित्र में दी गई है:

• उपयोगकर्ता 1, आइटम A का सीधे तौर पर अनुमति वाला प्रिंसिपल है.
• उपयोगकर्ता 2, आइटम D का सीधे तौर पर अनुमति वाला प्रिंसिपल है.
• आइटम D और आइटम E, दोनों को आइटम A का एसीएल इनहेरिट होता है.
• आइटम D, आइटम A को अपना कंटेनर बताता है.
• आइटम A और E, रूट-लेवल आइटम हैं, क्योंकि इनमें कोई कंटेनर आइटम नहीं है.

कंटेनर के रेफ़रंस के ज़रिए, कैस्केड मिटाता है. आइटम A मिटाने पर:

• setInheritFrom() रेफ़रंस के सभी वंशजों का ऐक्सेस, सभी उपयोगकर्ताओं के लिए हट जाता है.
• कोई भी उपयोगकर्ता आइटम A को ऐक्सेस नहीं कर सकता.
• आइटम D, अपने-आप मिट जाता है. कोई भी उपयोगकर्ता आइटम D को ऐक्सेस नहीं कर सकता.
• आइटम E को नहीं मिटाया जाता, क्योंकि मिटाने की प्रोसेस सिर्फ़ कंटेनर के रेफ़रंस के ज़रिए होती है.
• आइटम E को ऐक्सेस नहीं किया जा सकता और कोई भी उपयोगकर्ता आइटम E को खोज नहीं सकता.