หากต้องการให้เฉพาะผู้ใช้ที่มีสิทธิ์เข้าถึงรายการหนึ่งๆ จะเห็นรายการดังกล่าวในผลการค้นหา คุณควรจัดทำดัชนีรายการด้วยรายการควบคุมการเข้าถึง (ACL) จากที่เก็บขององค์กร คุณต้องสร้างโมเดล ACL ของที่เก็บ และรวม ACL เหล่านั้นเมื่อจัดทำดัชนีรายการในที่เก็บ Content Connector SDK มีชุดเมธอด ACL ที่สมบูรณ์ซึ่งมีประสิทธิภาพเพียงพอที่จะสร้างแบบจำลอง ACL ของที่เก็บส่วนใหญ่
สร้าง ACL
การสร้าง ACL เป็นกระบวนการที่มี 2 ขั้นตอน:
- สร้าง
Principal
โดยใช้เมธอดแบบคงที่ในคลาส ACL - ใช้คลาส
Acl.Builder
เพื่อสร้าง ACL โดยใช้รายการหลัก
ส่วนที่เหลือของเอกสารนี้ครอบคลุมแนวคิดบางอย่างที่คุณจำเป็นต้องทราบเพื่อสร้างแบบจำลองและสร้าง ACL เช่น การสืบทอดค่าและการกักเก็บ
สร้างรายการผู้ใช้หลักโดยใช้รหัสภายนอก
Google Cloud Search กำหนดให้ผู้ใช้และกลุ่มแก้ไขเป็นอีเมลของ Google เมื่อจัดทำดัชนีรายการที่เก็บ เครื่องมือเชื่อมต่อเนื้อหาอาจไม่มีอีเมลเหล่านี้ อย่างไรก็ตาม Content Connector SDK อนุญาตให้คุณใช้รหัสภายนอก (รหัสที่ให้สิทธิ์เข้าถึงรายการที่เก็บแก่ผู้ใช้หรือกลุ่ม) เพื่อจัดทำดัชนีรายการได้แทนการใช้อีเมล ใช้เมธอด getUserPrincipal()
หรือเมธอด getGroupPrincpal()
เพื่อสร้างผู้ใช้หลักที่มีรหัสภายนอก มีวิธีการแบบคงที่อื่นๆ อีกหลายวิธีในคลาส ACL
ที่ใช้สร้างออบเจ็กต์ Principal
การรับช่วงค่า ACL
การรับช่วงค่า ACL หมายถึงการให้สิทธิ์สำหรับรายการที่ระบุและผู้ใช้ที่เฉพาะเจาะจง โดยอิงตามผลลัพธ์ของการรวม ACL ของรายการและ ACL ของสายการรับค่า กฎที่ใช้พิจารณาการให้สิทธิ์จะขึ้นอยู่กับที่เก็บและคุณสมบัติของรายการ
ตั้งค่าการสืบทอด
แต่ละรายการอาจมีผู้ใช้หลักที่อนุญาตโดยตรงและผู้ใช้หลักที่ถูกปฏิเสธโดยตรง ซึ่งระบุโดยใช้เมธอด setReaders()
และ setDeniedReaders()
ผู้ใช้หลักที่ได้รับอนุญาตโดยตรงคือผู้ใช้ที่ระบุใน ACL ที่ช่วยให้เข้าถึงรายการที่เจาะจงได้โดยตรง ผู้ใช้หลักที่ถูกปฏิเสธโดยตรงคือผู้ใช้ที่ระบุใน ACL ว่าไม่มีสิทธิ์ในการเข้าถึงรายการที่เจาะจง
นอกจากนี้ รายการดังกล่าวยังอาจรับค่าผู้ใช้หลักที่อนุญาตโดยอ้อมและผู้ใช้หลักที่ถูกปฏิเสธโดยอ้อมโดยใช้เมธอด setInheritFrom()
ผู้ใช้หลักที่อนุญาตโดยอ้อมคือผู้ใช้ที่มีสิทธิ์เข้าถึงรายการเฉพาะหนึ่งๆ ผ่านการสืบทอด ACL ผู้ใช้หลักที่ถูกปฏิเสธโดยอ้อมคือผู้ใช้ที่ถูกปฏิเสธการเข้าถึงรายการเฉพาะผ่านการสืบทอด ACL
รูปที่ 1 แสดงวิธีใช้เมธอด setInheritFrom()
เพื่อรับการตั้งค่าผู้ใช้หลักที่อนุญาตทั้งโดยอ้อมและโดยอ้อม
![การวาดเส้นเชื่อมต่อระหว่างรายการต่างๆ](https://developers-dot-devsite-v2-prod.appspot.com/static/cloud-search/images/inherit-from-SDK.png?authuser=9&hl=th)
setInheritFrom()
การควบคุมการเข้าถึงเหล่านี้แสดงอยู่ในรูปที่ 1
- ผู้ใช้ 1 เป็นผู้ใช้หลักที่ได้รับอนุญาตโดยตรงของรายการ ก
- ผู้ใช้ 2 เป็นผู้ใช้หลักที่ได้รับอนุญาตโดยตรงของรายการ ข
- รายการ B รับค่า ACL ของรายการ A
กฎการเข้าถึงจะขึ้นอยู่กับการควบคุมการเข้าถึงดังต่อไปนี้
- ไม่จำเป็นต้องระบุผู้ใช้ 1 อย่างชัดเจนเป็นผู้ใช้หลักของรายการ B เพื่อเป็นผู้ใช้หลักที่อนุญาตโดยอ้อมของรายการ B จะได้รับสิทธิ์เข้าถึงเนื่องจากผู้ใช้ 1 อยู่ในรายการผู้ใช้หลักที่อนุญาตโดยตรงของรายการ A และรายการ B ได้รับ ACL มาจากรายการ A
- ผู้ใช้ 2 ไม่ใช่ผู้ใช้หลักที่อนุญาตโดยอ้อมของรายการ ก
ตั้งค่าประเภทการรับค่า
หากตั้งค่าการรับค่าโดยใช้เมธอด setInheritFrom()
คุณจะต้องตั้งค่าประเภทการรับค่าโดยใช้เมธอด setInheritanceType()
ประเภทการรับช่วงค่าจะกำหนดวิธีการรวม ACL ของผู้เผยแพร่โฆษณาย่อยกับ ACL ของระดับบน Acl.InheritanceType
ใช้การรับค่า 3 ประเภทดังนี้
BOTH_PERMIT
- ตั้งค่าประเภทการรับช่วงค่าเป็นBOTH_PERMIT
เพื่อให้สิทธิ์ผู้ใช้ในการเข้าถึงรายการเฉพาะเมื่อทั้ง ACL ของรายการย่อยและ ACL ของรายการระดับบนอนุญาตให้ผู้ใช้ดังกล่าวเข้าถึงรายการดังกล่าวได้CHILD_OVERRIDE
- ตั้งค่าประเภทการรับช่วงค่าเป็นCHILD_OVERRIDE
เพื่อบังคับให้ ACL ของรายการย่อยมีลำดับความสำคัญเหนือ ACL ของรายการหลักที่รับช่วงมา เมื่อรายการขัดแย้งกัน ดังนั้น หาก ACL ของรายการหลักปฏิเสธการเข้าถึงผู้ใช้ในฐานะผู้อ่านที่ถูกปฏิเสธ ผู้ใช้จะยังคงสามารถเข้าถึงได้หากมีสิทธิ์เข้าถึงรายการย่อยในฐานะผู้อ่าน ในทางกลับกัน แม้ว่า ACL ของรายการหลักจะให้สิทธิ์เข้าถึงแก่ผู้ใช้ ผู้ใช้จะไม่มีสิทธิ์เข้าถึงหากเป็นผู้อ่านย่อยที่ปฏิเสธPARENT_OVERRIDE
- ตั้งค่าประเภทการรับช่วงค่าเป็นPARENT_OVERRIDE
เพื่อบังคับให้ ACL ของรายการหลักมีลำดับความสำคัญเหนือ ACL ของรายการย่อยเมื่อรายการขัดแย้งกัน ดังนั้น หาก ACL ของรายการย่อยปฏิเสธการเข้าถึงผู้ใช้ในฐานะผู้อ่านที่ถูกปฏิเสธ ผู้ใช้จะยังสามารถเข้าถึงได้หากมีสิทธิ์เข้าถึงรายการระดับบนสุดในฐานะผู้อ่าน ในทางกลับกัน แม้ว่า ACL ของรายการย่อยจะให้สิทธิ์เข้าถึงแก่ผู้ใช้ แต่จะไม่มีสิทธิ์เข้าถึงหากผู้ใช้เป็นผู้อ่านรายการหลักที่ถูกปฏิเสธ
เมื่อประเมินสายการสืบทอด ACL ลำดับการประเมินสามารถเปลี่ยนผลของการตัดสินใจให้สิทธิ์ได้ Cloud Search ให้ลำดับการประเมินแบบต้นถึงรูทสำหรับสายการสืบทอด ACL กล่าวอย่างเจาะจงคือ การตัดสินใจของ ACL สำหรับห่วงโซ่เริ่มต้นด้วยการประเมินเด็กกับผู้ปกครอง และสามารถดำเนินการไปจนถึงระดับรูท
เช่น หากผู้เผยแพร่โฆษณาย่อยมีประเภทการรับค่า CHILD_OVERRIDE
และผู้ใช้มีสิทธิ์เข้าถึงระดับย่อย ไดรฟ์ก็จะไม่ต้องประเมินรายการระดับบน
แต่หากย่อยมี PARENT_OVERRIDE หรือ BOTH_PERMIT ไดรฟ์ จะประเมินการรับช่วงต่อในเชนต่อไป
การควบคุมและการลบรายการ
เมื่อจัดทำดัชนีรายการ คุณสามารถติดป้ายกำกับรายการเป็นคอนเทนเนอร์โดยใช้เมธอด setContainer()
ของคลาส IndexingItemBuilder
ความสัมพันธ์ของคอนเทนเนอร์/คอนเทนเนอร์จะสร้างลำดับชั้นทางกายภาพของรายการและช่วยให้มั่นใจว่ารายการจะถูกลบอย่างถูกต้อง
เมื่อลบคอนเทนเนอร์ รายการที่มีอยู่จะถูกลบไปด้วย
ความสัมพันธ์แบบเป็นอิสระต่อกันอย่างสิ้นเชิงจากกฎการสืบทอด ACL เช่น ไฟล์ในระบบไฟล์อาจอยู่ในโฟลเดอร์เพื่อวัตถุประสงค์ในการลบ แต่จะรับค่า ACL จากโฟลเดอร์อื่น การลบโฟลเดอร์จะไม่ลบรายการที่รับค่า ACL ของโฟลเดอร์ เว้นแต่รายการเหล่านั้นจะอยู่ในลำดับชั้นการจัดเก็บของโฟลเดอร์ด้วย
การควบคุมการเข้าถึงเหล่านี้แสดงอยู่ในรูปที่ 2
- ผู้ใช้ 1 เป็นผู้ใช้หลักที่ได้รับอนุญาตโดยตรงของรายการ ก
- ผู้ใช้ 2 เป็นผู้ใช้หลักที่ได้รับอนุญาตโดยตรงของรายการ ข
- ผู้ใช้ 3 เป็นผู้ใช้หลักที่ได้รับอนุญาตโดยตรงของรายการ ค
- รายการ C รับค่า ACL ของรายการ A
- รายการ B จะตั้งชื่อรายการ A เป็นคอนเทนเนอร์
- รายการ C จะตั้งชื่อรายการ B เป็นคอนเทนเนอร์
กฎการเข้าถึงจะขึ้นอยู่กับการควบคุมการเข้าถึงดังต่อไปนี้
- การเข้าถึงโดยอ้อมมาจากเมธอด
setInheritFrom()
ดังนั้น ผู้ใช้ 1 จะเข้าถึงรายการ C เนื่องจากรายการ C รับค่า ACL ของรายการ A - การเข้าถึงโดยอ้อมไม่ได้มาจากรายการ C ที่อยู่ในรายการ B ดังนั้น ผู้ใช้ 2 จึงไม่สามารถเข้าถึงรายการ C
![การวาดเส้นเชื่อมต่อระหว่างรายการต่างๆ](https://developers-dot-devsite-v2-prod.appspot.com/static/cloud-search/images/doc-hierarchy-SDK.png?authuser=9&hl=th)
setInheritFrom()
ที่ใช้งานอยู่การแยกการสืบทอด ACL จากลำดับชั้นการควบคุมทำให้คุณสามารถสร้างโมเดลโครงสร้างต่างๆ ที่มีอยู่มากมาย
สิ่งที่จะเกิดขึ้นเมื่อลบรายการเสร็จเรียบร้อยแล้ว
- รายการที่มีรายการที่ลบแล้วจะค้นหาไม่ได้และมีการกำหนดเวลาเพื่อลบจากแหล่งข้อมูลของ Google
- ระบบจะค้นหารายการที่ระบุรายการที่ถูกลบโดยใช้เมธอด
setInheritFrom()
ไม่ได้
หากทรัพยากรมีรายการที่ลบไปแล้วโดยใช้เมธอด setInheritFrom()
แต่ไม่มีชุดคอนเทนเนอร์ที่ใช้ setContainer()
หรือลำดับชั้นในการควบคุมไม่มีรายการที่ถูกลบ รายการนั้นและข้อมูลของรายการดังกล่าวจะยังคงอยู่ในแหล่งข้อมูลของ Google คุณมีหน้าที่รับผิดชอบในการลบรายการ
รูปที่ 3 แสดงตัวอย่างวิธีการลบในลำดับชั้นของรายการ
![การวาดเส้นเชื่อมต่อระหว่างรายการต่างๆ](https://developers-dot-devsite-v2-prod.appspot.com/static/cloud-search/images/doc-hierarchy-deletion-SDK.png?authuser=9&hl=th)
การควบคุมการเข้าถึงเหล่านี้แสดงอยู่ในรูปที่ 3
- ผู้ใช้ 1 เป็นผู้ใช้หลักที่ได้รับอนุญาตโดยตรงของรายการ ก
- ผู้ใช้ 2 เป็นผู้ใช้หลักที่ได้รับอนุญาตโดยตรงของรายการ ง
- ทั้งรายการ D และรายการ E รับค่า ACL ของรายการ A
- รายการ D ตั้งชื่อรายการ A เป็นคอนเทนเนอร์
- รายการ A และ E เป็นรายการระดับรากเนื่องจากไม่มีรายการคอนเทนเนอร์
ลบแบบ Cascade ผ่านการอ้างอิงคอนเทนเนอร์ สิ่งที่จะเกิดขึ้นเมื่อรายการ A ถูกลบ
- องค์ประกอบสืบทอดทั้งหมดของการอ้างอิง
setInheritFrom()
จะเข้าถึงผู้ใช้ทั้งหมดไม่ได้ - ไม่มีผู้ใช้ที่สามารถเข้าถึงรายการ A
- รายการ D ถูกลบโดยปริยาย ไม่มีผู้ใช้ที่สามารถเข้าถึงรายการ D
- รายการ E จะไม่ถูกลบ เนื่องจากการลบจะสืบทอดผ่านการอ้างอิงคอนเทนเนอร์เท่านั้น
- เข้าถึงรายการ E ไม่ได้ และไม่มีผู้ใช้ที่ค้นหารายการ E ได้