मैप ACL

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

ध्यान दें: कॉन्टेंट कनेक्टर SDK टूल, सिंगल-डोमेन ACL के साथ काम करता है, लेकिन क्रॉस-डोमेन ACL के साथ नहीं. आप अपने संगठन से बाहर के किसी भी उपयोगकर्ता और ग्रुप को ऐक्सेस नहीं दे सकते. आपके संगठन से बाहर के उपयोगकर्ताओं या ग्रुप को रेफ़र करने वाले किसी भी ACL का कोई असर नहीं होता.

एसीएल बनाएं

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

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

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

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

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

ध्यान दें: उपयोगकर्ताओं को खोज के नतीजों में तब तक आइटम नहीं दिखते, जब तक उनका बाहरी आईडी उनके Google खाते से सिंक नहीं हो जाता. इन बाहरी उपयोगकर्ता या ग्रुप आईडी को किसी Google ईमेल पते के साथ सिंक करने के लिए, आइडेंटिटी कनेक्टर का इस्तेमाल किया जा सकता है. आइडेंटिटी कनेक्टर के बारे में ज़्यादा जानकारी के लिए, पहचान कनेक्टर बनाना देखें.

चेतावनी: किसी आइटम की पहचान को किसी दूसरी आइडेंटिटी के साथ फिर से मैप करने के बाद, आपको आइटम को फिर से इंडेक्स करना होगा, ताकि नई आइडेंटिटी को होल्ड किया जा सके. ज़्यादा जानकारी के लिए, पहचान की रीमैपिंग करना देखें.

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

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

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

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

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

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

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

पहली इमेज. setInheritFrom() तरीका.

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

• उपयोगकर्ता 1, आइटम A का मुख्य मालिक है.
• उपयोगकर्ता 2, आइटम B का मुख्य मालिक है.
• आइटम B, आइटम A का ACL इनहेरिट करता है.

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

• उपयोगकर्ता 1 को आइटम 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 पर सेट करें, ताकि पैरंट आइटम के एसीएल को, चाइल्ड आइटम के एसीएल पर प्राथमिकता हासिल करने के लिए, जब उनका विरोध करना पड़े. इसलिए, अगर चाइल्ड आइटम का ACL, उपयोगकर्ता को नामंजूर रीडर के रूप में ऐक्सेस देने से इनकार करता है, तो भी उपयोगकर्ता के पास उसे ऐक्सेस करने की अनुमति होती है. वहीं, चाइल्ड आइटम का ACL, उपयोगकर्ता को ऐक्सेस देता है. हालांकि, अगर उपयोगकर्ता को पैरंट आइटम का ऐक्सेस नहीं मिलता है, तो उसे ऐक्सेस नहीं मिलेगा.

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

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

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

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

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

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

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

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

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

दूसरी इमेज. इस्तेमाल किया जा रहा setInheritFrom() तरीका.

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

जब कोई आइटम मिटाया जाता है, तो:

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

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

तीसरी इमेज में, उदाहरण के तौर पर दिखाया गया है कि किसी आइटम के क्रम को कैसे मिटाया जाता है.

तीसरी इमेज. किसी आइटम और एसीएल इनहेरिटेंस को मिटाना.

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

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

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

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