Eşleme EKL'leri

Bir öğeyi yalnızca erişimi olan kullanıcıların belirli bir erişim kontrol listeleri (EKL'ler) ile birlikte öğeleri dizine eklemelisiniz kurumsal depodan verilerdir. Deponuzun EKL'lerini modellemeli ve depodaki öğeleri dizine eklerken bu EKL'leri dahil etmelisiniz. İçerik Bağlayıcısı SDK, EKL'lerin EKL'lerini modellemeye yetecek kadar güçlü bir EKL yöntemleri kümesi sunar. depolarız.

EKL oluştur

EKL oluşturma iki adımlı bir işlemdir:

1. Bir metin oluştur: Principal statik yöntemleri kullanarak ACL sınıfını kullanır.
2. Acl.Builder'ı kullanma sınıfını kullanır.

Bu dokümanın geri kalanında, modelleme yapmak için bilmeniz gereken bazı kavramlar ve devralma ve saklama gibi EKL'ler oluşturabilirsiniz.

Harici kimlik kullanarak ana hesap oluşturma

Google Cloud Search, kullanıcıların ve grupların Google e-posta adresine çözümlenmesini gerektirir girin. Kod deposu öğeleri dizine eklenirken içerik bağlayıcıları bu öğelere sahip olmayabilir e-posta adresleri Ancak Content Connector SDK'si, harici kimlik (kullanıcıya veya gruba depo öğelerine erişim sağlayan kimlik) bir e-posta adresinin sahibi olarak ekleyebilirsiniz. Şunu kullanın: getUserPrincipal() yöntemini veya getGroupPrincpal() yöntemini kullanarak harici kimlikler içeren ana hesaplar oluşturma yöntemini kullanabilirsiniz. Birkaç tane daha veya ACL derleme için kullanılan sınıf Principal nesne.

EKL devralma

EKL devralma, belirli bir öğe ve belirli bir öğe için yetkilendirme anlamına gelir öğenin EKL'lerinin ve EKL'lerinin bir kombinasyonunun sonucuna göre Devralma zincirinin EKL'leridir. Yetkilendirme kararı vermek için kullanılan kurallar kod deposuna ve öğenin özelliklerine bağlıdır.

Devralmayı ayarlama

Her öğenin doğrudan izin verilen ana hesapları ve doğrudan reddedilen ana hesapları olabilir. setReaders() ve setDeniedReaders() yöntemler. Doğrudan izin verilen birincil hesap, EKL'de tanımlanmış ve kullanıcıya doğrudan erişim sağlayan belirli bir öğe. Doğrudan reddedilen ana hesap, EKL'de şu şekilde tanımlanan bir kullanıcıdır: erişimi vardır.

Bir öğe, dolaylı olarak izin verilen ana hesapları ve dolaylı olarak reddedilen ana hesapları, setInheritFrom() yöntemidir. Dolaylı olarak izin verilen ana hesap, EKL devralma yoluyla belirli bir öğeye dolaylı erişimi varsa. Dolaylı olarak reddedilen ana hesap, bir kullanıcıdır EKL devralma yoluyla belirli bir öğeye erişimi reddedilen kişiler.

Şekil 1, setInheritFrom() yöntemi, dolaylı olarak izin verilen ve dolaylı olarak reddedilen ana hesapları devralmak için kullanılır.

Bu erişim denetimleri Şekil 1'de gösterilmiştir:

• 1. Kullanıcı, A öğesinin doğrudan izin verilen ana hesabıdır.
• 2. Kullanıcı, B öğesi için doğrudan izin verilen bir ana hesaptır.
• B öğesi, A öğesinin EKL'sini devralır.

Erişim denetimlerine bağlı olarak erişim kuralları şunlardır:

• Kullanıcı 1'in, açıkça belirtilmek üzere B öğesinin ana hesabı olarak B öğesi için dolaylı olarak izin verilen ana para; erişim devralındı çünkü Kullanıcı 1, A ve B öğesi için doğrudan izin verilen ana hesap olarak listeleniyor EKL'sini A öğesinden devralır.
• 2. Kullanıcı, A öğesi için dolaylı olarak izin verilen bir ana hesap değil.

Devralma türünü ayarla

Devralmayı ayarlamak için setInheritFrom() yöntemini kullanıyorsanız devralma türünü setInheritanceType() yöntemidir. Devralma türü, alt yayıncının EKL, üst EKL'si ile birleştirilir. Acl.InheritanceType üç devralma türünü uygular:

• BOTH_PERMIT - Bir kullanıcıya erişim vermek için devralma türünü BOTH_PERMIT olarak ayarlayın öğesine yalnızca alt öğenin EKL ve üst öğenin devralınan öğe EKL'si olduğunda kullanıcının ilgili öğeye erişmesine izin verir.

• CHILD_OVERRIDE - Alt öğeyi zorunlu kılmak için devralma türünü CHILD_OVERRIDE olarak ayarlayın üst öğenin EKL'sine göre () öncelikli olmasını sağlayabilirsiniz. çatışmaya neden olabilir. Bu nedenle, üst öğenin EKL'si kullanıcının erişimi reddederse reddedilen bir okuyucu olarak, çocuğa erişimi olan kullanıcı da erişebilir okumayı öğreteceğim. Buna karşılık, üst öğenin EKL'si kullanıcı, alt yayıncının erişimine izin verilmeyen bir okuyucuysa erişim iznine sahip olmaz.

• PARENT_OVERRIDE -PARENT_OVERRIDE üst öğenin EKL'sinin, alt öğenin EKL'sinden önce çatışmaya neden olabilir. Bu nedenle, alt öğenin EKL'si kullanıcının erişimi reddedilmiş olarak reddederse erişimi varsa kullanıcı yine de otomatik olarak üst öğeye erişebilirse yardımcı olur. Buna karşılık, alt öğenin EKL'si kullanıcıya erişim izni olsa bile Kullanıcı, üst öğenin reddedilmiş okuyucusuysa erişimine sahip değildir.

EKL devralma zinciri değerlendirilirken değerlendirme sırası değişebilir kararının sonucuna göre hareket eder. Cloud Search yapraktan köke değerlendirme sırası. EKL kararı bir çocuğun ebeveynleriyle birlikte değerlendirilmesiyle başlar ve bu süreç kök üst yapıya kadar giderilir.

Örneğin, alt yayıncının CHILD_OVERRIDE devralma türü varsa ve kullanıcı çocuğa erişimi varsa Drive'ın üst öğeyi değerlendirmesine gerek yoktur. Ancak, alt yayıncıda PARENT_OVERRIDE veya BOTH_PERMIT varsa Drive devam eder daha üst sıralara doğru devri edineceksiniz.

Kapsam ve öğe silme

Bir öğeyi dizine eklerken, bir öğeyi kapsayıcı olarak etiketleyebilmek için setContainer() yöntemi IndexingItemBuilder sınıfını kullanır. Kapsayıcı/içerir ilişkisi, fiziksel aktiviteyi ve öğelerin uygun şekilde silinmesini sağlar. Bir kapsayıcı silindiğinde, içerdiği öğeler de silinir.

Kapsayıcılık ilişkileri, EKL devralma kurallarından tamamen bağımsızdır. Örneğin, dosya sistemindeki bir dosya olabilir, ancak ACL'yi farklı bir klasörden devralabilirsiniz. Bir klasörü, EKL'sini devralan öğeleri silmez (bu öğeler aynı zamanda dört hususu bulunuyor.

Bu erişim kontrolleri Şekil 2'de gösterilmiştir:

• 1. Kullanıcı, A öğesinin doğrudan izin verilen ana hesabıdır.
• 2. Kullanıcı, B öğesi için doğrudan izin verilen bir ana hesaptır.
• 3. Kullanıcı, C öğesi için doğrudan izin verilen bir ana hesaptır.
• C öğesi, A öğesinin EKL'sini devralır.
• B öğesi, A öğesini kapsayıcısı olarak adlandırır.
• C öğesi, B öğesini kapsayıcısı olarak adlandırır.

Erişim denetimlerine bağlı olarak erişim kuralları şunlardır:

• Dolaylı erişim, setInheritFrom() üzerinden gelir. yöntemidir. Dolayısıyla, kullanıcı 1 C öğesine erişebilir çünkü C öğesi şu öğenin EKL'sini devralır: A öğesi.
• Dolaylı erişim, B öğesi içinde bulunan C öğesinden gelmez. Bu nedenle, 2. kullanıcı C öğesine erişemez.

EKL devralmayı dahil etme hiyerarşisinden ayırmak, birçok farklı mevcut yapıda yer alır.

Bir öğe başarıyla silindiğinde:

• Silinmiş bir öğe içeren herhangi bir öğe aranamaz ve Google'ın veri kaynağından silinmek üzere programlandı.
• Silinen öğeyi setInheritFrom() yöntem arama yapılamaz.

Bir kaynakta setInheritFrom() yöntemidir ancak setContainer() veya içerme hiyerarşisinde silinmiş öğe yok, bu öğe ve verileri Google'ın veri kaynağında kalmaya devam eder. Öğeyi silmek sizin sorumluluğunuzdadır.

Şekil 3'te, bir öğe hiyerarşisi için silme işleminin işleyiş şekli gösterilmektedir.

Bu erişim kontrolleri Şekil 3'te gösterilmiştir:

• 1. Kullanıcı, A öğesinin doğrudan izin verilen ana hesabıdır.
• 2. Kullanıcı, D öğesi için doğrudan izin verilen bir ana hesaptır.
• Hem D hem de E öğesi, A öğesinin EKL'sini devralır.
• D öğesi, A öğesini kapsayıcısı olarak adlandırır.
• A ve E öğeleri, kapsayıcı öğedir.

Kapsayıcı referansları üzerinden geçen basamakları siler. A öğesi silindiğinde:

• setInheritFrom() öğesinin tüm alt öğeleri referans tüm kullanıcılar için erişimi kaybeder.
• Hiçbir kullanıcı A öğesine erişemez.
• D öğesi dolaylı olarak silinmiştir. Hiçbir kullanıcı D öğesine erişemez.
• Silme işlemi yalnızca kapsayıcı boyunca kademeli olarak gerçekleştiğinden E öğesi silinmez referanslar.
• E öğesine ulaşılamaz ve hiçbir kullanıcı E öğesini arayamaz.