為了確保只有具備項目存取權的使用者，才能在 搜尋結果，您應使用項目的存取控制清單 (ACL) 為項目建立索引 從企業存放區擷取您必須建立存放區的 ACL 模型 為存放區中的項目建立索引時納入這些 ACL。內容連接器 SDK 提供了豐富的 ACL 方法，這些 ACL 方法足以建立物件的 ACL 模型 大多數存放區
建立 ACL
建立 ACL 的程序包含兩個步驟：
- 撰寫
Principal敬上 您可以在 ACL 類別 - 使用
Acl.Builder類別，使用主體建構 ACL。
本文件的其餘部分將說明 並建立 ACL，例如繼承和遏制
使用外部 ID 建立主體
Google Cloud Search 規定使用者和群組必須連結至 Google 電子郵件地址
讓我們看看 DNS 解析
進一步探索內部和外部位址建立索引存放區項目時，內容連接器可能沒有這些項目
電子郵件地址。不過，Content Connector SDK 可讓您使用
外部 ID (將存放區項目存取權授予使用者或群組的 ID)，
電子郵件地址，以便將項目編入索引。使用
getUserPrincipal()敬上
方法，或
getGroupPrincpal()
方法來建立包含外部 ID 的主體。
靜態方法的
ACL敬上
用於建構應用程式的
Principal 物件。
ACL 繼承
ACL 繼承指的是特定項目和特定項目的授權 使用者，根據項目 ACL 的組合結果和 其繼承鏈的 ACL。做出授權決定的規則 取決於存放區和項目的屬性。
設定繼承
每個項目都可以有直接允許的主體和直接遭拒的主體。
方法是使用
setReaders()敬上
和
setDeniedReaders() 方法。直接允許
主體是 ACL 中識別的使用者，可讓使用者直接存取
特定項目直接拒絕的主體是在 ACL 中識別為的使用者
就能存取特定項目
項目也可以沿用間接允許的主體，並
間接遭拒主體
setInheritFrom()敬上
方法。間接允許的主體是指透過 ACL 繼承關係、
取得特定項目的間接存取權。間接遭拒的主體為使用者
透過 ACL 繼承關係，拒絕特定項目的存取權限。
圖 1 說明瞭
setInheritFrom() 方法用於繼承允許和間接拒絕的主體。
setInheritFrom() 方法。圖 1 呈現了這些存取控制：
- 使用者 1 是項目 A 的直接允許主體。
- 使用者 2 是項目 B 的直接允許主體。
- 項目 B 沿用項目 A 的 ACL。
根據存取權控管設定，存取規則將：
- 您不需要明確將使用者 1 明確指定為項目 B 的主體 項目 B 間接允許的主體；也會沿用 因為使用者 1 列為項目 A 和項目 B 的直接主體 沿用項目 A 的 ACL。
- 使用者 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 將存取權授予使用者， 如果使用者拒絕上層項目的讀取者，就不會獲得存取權。
在評估 ACL 繼承鏈時，評估的順序可能會改變 授權決定的結果。Cloud Search 提供從根層級到根層級 ACL 繼承鏈結的評估順序。具體來說，ACL 決定 鏈結的第一步是評估孩子及其父項，因此 全部流向根父項
舉例來說，如果子項是 CHILD_OVERRIDE 繼承類型且使用者
，因此雲端硬碟不需要評估家長權限。
不過，如果子發布商擁有 PARENT_OVERRIDE 或 BOTH_PERMIT，雲端硬碟就會繼續執行
評估繼承層面
遏制和刪除項目
將項目編入索引時，你可以使用
setContainer() 方法
IndexingItemBuilder
類別容器/容器關係會建立實體
並確保項目妥善刪除
刪除容器時，內含的項目也會一併刪除。
遏制關係完全獨立於 ACL 繼承規則。 例如，檔案系統中的檔案可以由 但沿用其他資料夾中的 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() 方法。將 ACL 繼承與遏制階層區隔開來可讓您建立模型 有許多不同的現有結構
成功刪除項目的影響如下：
- 內含已刪除項目的項目將不可搜尋，且 Google 資料來源中的預定刪除時間。
- 任何使用
setInheritFrom()方法 變成無法搜尋的程度
如果資源中有已刪除的項目，請使用
setInheritFrom()敬上
方法，但並沒有使用
setContainer()，或其隔離階層未包含已刪除的項目、該項目及其資料
仍保留在 Google 的資料來源中您必須自行負責刪除此項目。
圖 3 為項目階層刪除功能的運作方式範例。
圖 3 呈現了這些存取控制：
- 使用者 1 是項目 A 的直接允許主體。
- 使用者 2 是項目 D 的直接允許主體。
- 項目 D 和項目 E 皆沿用項目 A 的 ACL。
- 項目 D 將項目 A 命名為其容器。
- 項目 A 和 E 是根層級項目，因為他們沒有 容器項目
透過容器參照刪除串聯資料。刪除項目 A 時：
setInheritFrom()的所有子系 也失去了所有使用者的存取權- 所有使用者皆無法存取項目 A。
- 項目 D 已間接刪除。所有使用者皆無法存取項目 D。
- 項目 E 不會遭到刪除，因為刪除動作只會透過容器串聯 參照。
- 項目 E 無法存取，且使用者無法搜尋項目 E。