मैप 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 से अपनी एसीएल इनहेरिट करता है.
• उपयोगकर्ता 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 में शामिल करने से नहीं मिलता. इसलिए, उपयोगकर्ता 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 को खोज नहीं सकता.