मैप ACL

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

एसीएल बनाना

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

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

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

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

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

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

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

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

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

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

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

ऐक्सेस कंट्रोल को पहले डायग्राम में दिखाया गया है:

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

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

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

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

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

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

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

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

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

उदाहरण के लिए, अगर बच्चे के पास 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 की एसीएल इनहेरिट की गई है.
• आइटम C को आइटम B में शामिल करने से, आइटम A को आइटम C का इनडायरेक्ट ऐक्सेस नहीं मिलता. इसलिए, उपयोगकर्ता 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 को खोज नहीं सकता.