मैप ACL

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

ACL बनाएं

ACL बनाने की प्रक्रिया दो चरणों में होती है:

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

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

बाहरी आईडी का इस्तेमाल करके मुख्य खाता बनाएं

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

ACL इनहेरिटेंस

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ये ऐक्सेस कंट्रोल, दूसरी इमेज में दिखाए गए हैं:

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

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

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

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

किसी आइटम को मिटाने के बाद:

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

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

तीसरी इमेज में दिखाया गया है कि आइटम के क्रम के लिए, डेटा मिटाने का तरीका कैसे काम करता है.

ये ऐक्सेस कंट्रोल, तीसरी इमेज में दिखाए गए हैं:

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

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

• setInheritFrom() पहचान फ़ाइल के सभी डिसेंडेंट, सभी उपयोगकर्ताओं के लिए ऐक्सेस खो देते हैं.
• कोई भी उपयोगकर्ता आइटम A को ऐक्सेस नहीं कर सकता.
• आइटम D को साफ़ तौर पर मिटा दिया गया है. कोई भी उपयोगकर्ता आइटम D को ऐक्सेस नहीं कर सकता.
• आइटम E को मिटाया नहीं जाता, क्योंकि डेटा को मिटाने की प्रक्रिया सिर्फ़ कंटेनर के रेफ़रंस के ज़रिए आगे बढ़ती है.
• आइटम E पहुंच के बाहर हो जाएगा और कोई भी उपयोगकर्ता आइटम E को नहीं खोज पाएगा.