เพื่อให้มั่นใจได้ว่าเฉพาะผู้ใช้ที่มีสิทธิ์เข้าถึงรายการดังกล่าวจะเห็นรายการดังกล่าวใน ผลการค้นหา คุณควรทำดัชนีรายการด้วยรายการควบคุมการเข้าถึง (ACL) จากที่เก็บขององค์กร คุณต้องสร้างโมเดล ACL ของที่เก็บและ รวม ACL เหล่านั้นเมื่อจัดทำดัชนีรายการในที่เก็บ เครื่องมือเชื่อมต่อเนื้อหา 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.google.cn/static/cloud-search/images/inherit-from-SDK.png?authuser=5&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 ของ รายการ ก. - การเข้าถึงโดยอ้อมไม่ได้มาจากรายการ C ที่อยู่ในรายการ B ดังนั้น ผู้ใช้ 2 จึงไม่สามารถเข้าถึงรายการ C
![การวาดเส้นเชื่อมต่อระหว่างรายการต่างๆ](https://developers.google.cn/static/cloud-search/images/doc-hierarchy-SDK.png?authuser=5&hl=th)
setInheritFrom()
ที่ใช้งานอยู่การแยกการสืบทอด ACL จากลำดับชั้นการควบคุมทำให้คุณสามารถสร้างโมเดล โครงสร้างที่มีอยู่มากมาย
สิ่งที่จะเกิดขึ้นเมื่อลบรายการเสร็จเรียบร้อยแล้ว
- รายการที่มีรายการที่ถูกลบจะค้นหาไม่ได้และ กำหนดเวลาเพื่อลบจากแหล่งข้อมูลของ Google
- รายการใดๆ ที่ระบุรายการที่ถูกลบโดยใช้
เมธอด
setInheritFrom()
จะไม่สามารถค้นหาได้
หากทรัพยากรมีรายการที่ลบไปแล้วโดยใช้
setInheritFrom()
แต่ไม่มีชุดคอนเทนเนอร์ที่ใช้
setContainer()
หรือลำดับชั้นในการควบคุมไม่มีรายการที่ถูกลบ รายการนั้นและข้อมูลของรายการ
ยังคงอยู่ในแหล่งข้อมูลของ Google คุณมีหน้าที่รับผิดชอบในการลบรายการ
รูปที่ 3 แสดงตัวอย่างวิธีการลบในลำดับชั้นของรายการ
![การวาดเส้นเชื่อมต่อระหว่างรายการต่างๆ](https://developers.google.cn/static/cloud-search/images/doc-hierarchy-deletion-SDK.png?authuser=5&hl=th)
การควบคุมการเข้าถึงเหล่านี้แสดงอยู่ในรูปที่ 3
- ผู้ใช้ 1 เป็นผู้ใช้หลักที่ได้รับอนุญาตโดยตรงของรายการ ก
- ผู้ใช้ 2 เป็นผู้ใช้หลักที่ได้รับอนุญาตโดยตรงของรายการ ง
- ทั้งรายการ D และรายการ E รับค่า ACL ของรายการ A
- รายการ D ตั้งชื่อรายการ A เป็นคอนเทนเนอร์
- รายการ A และ E เป็นรายการระดับรากเนื่องจากไม่มี รายการคอนเทนเนอร์
ลบแบบ Cascade ผ่านการอ้างอิงคอนเทนเนอร์ สิ่งที่จะเกิดขึ้นเมื่อรายการ A ถูกลบ
- องค์ประกอบสืบทอดทั้งหมดของ
setInheritFrom()
ไฟล์อ้างอิงเสียสิทธิ์เข้าถึงสำหรับผู้ใช้ทุกคน - ไม่มีผู้ใช้ที่สามารถเข้าถึงรายการ A
- รายการ D ถูกลบโดยปริยาย ไม่มีผู้ใช้ที่สามารถเข้าถึงรายการ D
- ไม่ได้ลบรายการ E เนื่องจากการลบแบบต่อเรียงผ่านคอนเทนเนอร์เท่านั้น ข้อมูลอ้างอิง
- เข้าถึงรายการ E ไม่ได้ และไม่มีผู้ใช้ที่ค้นหารายการ E ได้