मैप ACL

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

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

ACL बनाएं

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

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

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

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

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

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

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

ACL इनहेरिटेंस

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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