Eşleme EKL'leri

Yalnızca öğeye erişimi olan kullanıcıların bir arama sonucundaki öğeyi görebildiğinden emin olmak için öğeleri kurumsal depodaki erişim kontrol listeleriyle (ACL'ler) birlikte dizine eklemeniz gerekir. Deponuzun EKL'lerini modellemeniz ve depodaki öğeleri dizine eklerken bu EKL'leri dahil etmeniz gerekir. Content Connector SDK'sı, çoğu deponun EKL'lerini modellemeye yetecek kadar güçlü olan zengin bir EKL yöntemleri grubu sağlar.

Not: Content Connector SDK'sı tek alan adı EKL'lerini destekler ancak alanlar arası EKL'leri desteklemez. Kuruluşunuz dışındaki kullanıcılara ve gruplara erişim izni veremezsiniz. Kuruluşunuz dışındaki kullanıcılara veya gruplara işaret eden EKL'lerin herhangi bir etkisi yoktur.

EKL oluştur

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

1. ACL sınıfında statik yöntemler kullanarak bir Principal oluşturun.
2. Ana hesabı kullanarak EKL'yi oluşturmak için Acl.Builder sınıfını kullanın.

Bu dokümanın geri kalanında, devralma ve kapsama gibi, EKL'leri modellemek ve oluşturmak için bilmeniz gereken bazı kavramlar anlatılmaktadır.

Harici kimlik kullanarak ana hesap oluşturma

Google Cloud Search, kullanıcıların ve grupların Google e-posta adresine çözümlenmesini gerektirir. Depo öğeleri dizine eklenirken içerik bağlayıcıları bu e-posta adreslerine sahip olmayabilir. Ancak Content Connector SDK, bir öğeyi dizine eklemek için e-posta adresi yerine herhangi bir harici kimlik (kod deposu öğelerine kullanıcı veya grup erişimi veren kimlik) kullanmanıza olanak tanır. Harici kimlikler içeren ana hesaplar oluşturmak için getUserPrincipal() veya getGroupPrincpal() yöntemini kullanın. ACL sınıfında Principal nesneleri derlemek için kullanılan birkaç statik yöntem daha vardır.

Not: Kullanıcılar, harici kimlikleri Google Hesaplarıyla senkronize edilene kadar arama sonuçlarında öğeleri görmez. Bu harici kullanıcı veya grup kimliklerinin bir Google e-posta adresiyle senkronize edilmesi kimlik bağlayıcısı kullanılarak gerçekleştirilebilir. Kimlik bağlayıcıları hakkında daha fazla bilgi için Kimlik bağlayıcısı oluşturma bölümüne bakın.

Uyarı: Bir öğenin kimliğini başka bir kimlikle yeniden eşledikten sonra, yeni kimliğin geçerli olması için öğeleri yeniden dizine eklemeniz gerekir. Daha fazla bilgi için Kimlikleri yeniden eşleme bölümüne bakın.

EKL devralma

EKL devralma, öğenin EKL'lerinin ve devralma zincirinin EKL'lerinin bir kombinasyonunun sonucuna göre belirli bir öğe ve belirli bir kullanıcı için yetkilendirmeyi ifade eder. Yetkilendirme kararı vermek için kullanılan kurallar depoya ve öğenin özelliklerine bağlıdır.

Devralmayı ayarlama

Her öğenin, setReaders() ve setDeniedReaders() yöntemleri kullanılarak belirlenen doğrudan izin verilen ana hesapları ve doğrudan reddedilen ana hesapları olabilir. Doğrudan izin verilen ana hesap, bir EKL'de tanımlanmış ve belirli bir öğeye doğrudan erişim sağlayan bir kullanıcıdır. Doğrudan reddedilen ana hesap, ACL'de belirli bir öğeye erişimi olmadığı tespit edilen bir kullanıcıdır.

Bir öğe ayrıca setInheritFrom() yöntemini kullanarak dolaylı olarak izin verilen ana hesapları ve dolaylı olarak reddedilen ana hesapları devralabilir. Dolaylı olarak izin verilen ana hesap, EKL devralma yoluyla belirli bir öğeye dolaylı erişimi olan kullanıcıdır. Dolaylı olarak reddedilen ana hesap, EKL devralma yoluyla belirli bir öğeye erişimi reddedilen kullanıcıdır.

Not: Devralmayı setInheritFrom() yöntemini kullanarak ayarlarsanız devralma türünü setInheritanceType() yöntemini kullanarak ayarlamanız gerekir. Devralma türleri hakkında bilgi edinmek için Devralma türünü ayarlama bölümüne bakın.

Şekil 1'de, setInheritFrom() yönteminin dolaylı izin verilen ve dolaylı olarak reddedilen ana hesapları devralmak için nasıl kullanıldığı gösterilmektedir.

Şekil 1. setInheritFrom() yöntemi.

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, B öğesinin dolaylı olarak izin verilen ana hesabı olması için B öğesinin ana hesabı olarak açıkça belirtilmesi gerekmez. Kullanıcı 1, A öğesinin doğrudan izin verilen ana hesabı olarak listelendiği ve B öğesi, EKL'sini A öğesinden devraldığı için erişim devralınır.
• 2. Kullanıcı, A öğesi için dolaylı olarak izin verilen bir ana hesap değil.

Devralma türünü ayarla

Devralma işlemini setInheritFrom() yöntemini kullanarak ayarlarsanız devralma türünü setInheritanceType() yöntemini kullanarak ayarlamanız gerekir. Devralma türü, bir alt hesabın EKL'sinin üst öğesinin EKL'si ile nasıl birleşeceğini belirler. Acl.InheritanceType, üç devralma türü uygular:

• BOTH_PERMIT - Yalnızca hem alt öğenin EKL'si hem de üst öğenin devralınan öğe EKL'si kullanıcının ilgili öğeye erişmesine izin verdiğinde bir öğeye kullanıcı erişimi vermek için devralma türünü BOTH_PERMIT olarak ayarlayın.

• CHILD_OVERRIDE - Çalıştığında alt öğenin EKL'sinin, devralınan üst öğenin EKL'sine göre öncelikli olmasını sağlamak için devralma türünü CHILD_OVERRIDE olarak ayarlayın. Bu nedenle, üst öğenin EKL'si reddedilen bir okuyucu olarak kullanıcıya erişimi reddederse kullanıcı, okuyucu olarak alt öğeye erişimi varsa yine de erişime sahip olur. Buna karşılık, üst öğenin EKL'si kullanıcıya erişim izni vermiş olsa bile, alt öğe okuyucusu olan kullanıcı erişim sağlayamaz.

• PARENT_OVERRIDE - Alt öğenin EKL'si çakıştığında üst öğenin EKL'sinin, her bir alt öğenin EKL'sinden öncelikli olmasını sağlamak için devralma türünü PARENT_OVERRIDE olarak ayarlayın. Bu nedenle, alt öğenin EKL'si kullanıcının erişimi reddedilen bir okuyucu olarak reddederse, okuyucu olarak üst öğeye erişimi varsa kullanıcı yine de erişime sahip olur. Buna karşılık, alt öğenin EKL'si kullanıcıya erişim izni olsa bile, üst öğenin reddedilmiş okuyucusu olan kullanıcı erişim sağlayamaz.

EKL devralma zinciri değerlendirilirken değerlendirme sırası yetkilendirme kararının sonucunu değiştirebilir. Cloud Search, EKL devralma zincirleri için yapraktan köke değerlendirme sırası sunar. Özellikle bir zincirle ilgili EKL kararı, bir alt hesabın üst öğeleriyle birlikte değerlendirilmesiyle başlar ve kök üst öğeye kadar ilerleyebilir.

Örneğin, alt yayıncının CHILD_OVERRIDE devralma türü varsa ve kullanıcının alt öğeye erişimi varsa Drive'ın üst öğeyi değerlendirmesine gerek yoktur. Ancak, alt öğede PARENT_OVERRIDE veya BOTH_PERMIT varsa Drive, devralmayı zincirin daha üst kısımlarında değerlendirmeye devam eder.

Kapsam ve öğe silme

Bir öğeyi dizine eklerken IndexingItemBuilder sınıfının setContainer() yöntemini kullanarak öğeyi kapsayıcı olarak etiketleyebilirsiniz. Kapsayıcı/kapsayıcı ilişkisi, öğelerin fiziksel hiyerarşisini oluşturur 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, silme amacıyla bir klasör içine alınabilir ancak EKL'yi farklı bir klasörden devralabilir. Bir klasör silindiğinde, klasörün kapsama hiyerarşisinde de bulunmayan öğeler, EKL'sini devralan öğeler silinmez.

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() yönteminden gelir. Dolayısıyla, öğe C, A öğesinin EKL'sini devraldığı için 1. kullanıcı C öğesine erişebilir.
• Dolaylı erişim, B öğesi içinde bulunan C öğesinden gelmez. Bu nedenle, 2. kullanıcı C öğesine erişemez.

Şekil 2. Kullanımdaki setInheritFrom() yöntemi.

EKL devralmanın kapsam hiyerarşisinden ayrılması, birçok farklı mevcut yapıyı modellemenize olanak tanır.

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

• Silinmiş bir öğe içeren tüm öğeler aranamaz hale gelir ve Google'ın veri kaynağından silinmek üzere programlanır.
• Silinmiş öğeyi setInheritFrom() yöntemini kullanarak belirten herhangi bir öğe aranamaz hale gelir.

Bir kaynakta setInheritFrom() yöntemi kullanılarak silinmiş bir öğe varsa ancak setContainer() kullanılarak oluşturulmuş bir kapsayıcı kümesi yoksa veya içerme hiyerarşisinde silinmiş öğe yoksa bu öğe ve verileri Google'ın veri kaynağında kalır. Öğeyi silmek sizin sorumluluğunuzdadır.

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

Şekil 3. Bir öğeyi ve EKL devralmayı silme.

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, bir kapsayıcı öğesine sahip olmadıkları için kök düzeyinde öğelerdir.

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

• setInheritFrom() referansının tüm alt öğeleri, 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 container referansları aracılığıyla kademeli olarak gerçekleştiğinden E öğesi silinmez.
• E öğesine ulaşılamaz ve hiçbir kullanıcı E öğesini arayamaz.