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:
- Bir metin oluştur:
Principal
statik yöntemleri kullanarak ACL sınıfını kullanır. 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'sı,
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.