Eşleme EKL'leri

Yalnızca bir öğeye erişimi olan kullanıcıların söz konusu öğeyi arama sonucu içinde görmesini sağlamak için öğeleri kurumsal depodaki erişim kontrol listeleri (EKL'ler) ile 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 modelleyebilecek kadar güçlü bir EKL yöntemleri kümesi sunar.

Not: Content Connector SDK'sı tek alanlı EKL'leri destekler ancak alanlar arası EKL'leri desteklemez. Kuruluşunuzun dışındaki kullanıcı ve gruplara erişim izni veremezsiniz. Kuruluşunuzun dışındaki kullanıcılara veya gruplara referans veren EKL'lerin herhangi bir etkisi yoktur.

EKL oluşturma

EKL oluşturmak 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 belgenin geri kalanında, devralma ve kapsama gibi EKL'ler oluşturmak ve modellemek için bilmeniz gereken bazı kavramlar açıklanmıştır.

Harici kimlik kullanarak ana hesap oluşturma

Google Cloud Search, kullanıcıların ve grupların Google e-posta adresine çözüm üretmesini gerektirir. Kod deposu öğelerini dizine eklerken, içerik bağlayıcıları bu e-posta adreslerine sahip olmayabilir. Bununla birlikte, Content Connector SDK'sı bir öğeyi dizine eklemek için e-posta adresi yerine herhangi bir harici kimliği (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. Principal nesnelerini oluşturmak için kullanılan ACL sınıfında birkaç statik yöntem daha vardır.

Not: Harici kimlikleri Google hesaplarıyla senkronize edilene kadar kullanıcılar, arama sonuçlarındaki öğeleri görmez. Bu harici kullanıcı veya grup kimliklerinin bir Google e-posta adresiyle senkronize edilmesi, bir 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ı oluşturma bölümüne bakın.

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

EKL devralma

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

Devralmayı ayarla

Her öğede setReaders() ve setDeniedReaders() yöntemleri kullanılarak belirtilen doğrudan izin verilen ana hesaplar ve doğrudan reddedilen ana hesaplar bulunabilir. Doğrudan izin verilen ana hesap, EKL'de tanımlanan ve belirli bir öğeye doğrudan erişim sağlayan kullanıcıdır. Doğrudan reddedilen ana hesap, EKL'de belirli bir öğeye erişimi yok olarak tanımlanan bir kullanıcıdır.

Bir öğe, setInheritFrom() yöntemini kullanarak dolaylı olarak izin verilen ana hesapları ve dolaylı reddedilen ana hesapları da devralabilir. Dolaylı olarak izin verilen ana hesap, EKL devralma yoluyla belirli bir öğeye dolaylı erişimi olan bir kullanıcıdır. Dolaylı olarak reddedilen ana hesap, EKL devralma yoluyla belirli bir öğeye erişimi reddeden bir 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 için Devralma türünü ayarlama bölümüne bakın.

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

Şekil 1. setInheritFrom() yöntemi.

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

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

Erişim denetimlerine bağlı olarak şu erişim kuralları geçerli olur:

• 1. kullanıcının, B öğesinin dolaylı izin verilen ana hesabı olması için açık bir şekilde B öğesinin ana hesabı olarak belirtilmesi gerekmez. Erişim devralınır. Bunun nedeni, Kullanıcı 1'in A öğesinin doğrudan izin verilen ana hesabı olarak listelenmesi ve B öğesi, EKL'sini A öğesinden devralmasıdır.
• Kullanıcı 2, A öğesi için dolaylı bir izin verilen ana hesap değil.

Devralma türünü ayarla

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

• BOTH_PERMIT - Hem alt öğenin EKL'si hem de üst öğenin devralınan öğe EKL'si bir kullanıcının söz konusu öğeye erişmesine izin verdiğinde erişim izni vermek için devralma türünü BOTH_PERMIT olarak ayarlayın.

• CHILD_OVERRIDE - Alt öğenin EKL'sini, çakışma esnasında devralınan üst öğenin EKL'sine göre öncelikli olmaya zorlamak için devralma türünü CHILD_OVERRIDE olarak ayarlayın. Dolayısıyla, üst öğenin EKL'si reddedilen bir okuyucu olarak kullanıcının erişimini reddederse kullanıcı, alt öğeye okuyucu olarak erişebiliyorsa hâlâ erişebilir. Öte yandan, üst öğenin EKL'si kullanıcıya erişim izni verse bile, kullanıcı alt öğenin okuyucusu reddedildiyse kullanıcı erişimi olmaz.

• PARENT_OVERRIDE - Üst öğenin EKL'sini, üst öğenin EKL'si çakıştığında öncelikli olmaya zorlamak için devralma türünü PARENT_OVERRIDE olarak ayarlayın. Dolayısıyla, alt öğenin EKL'si reddedilen okuyucu olarak kullanıcıya erişimi reddederse kullanıcı, üst öğeye okuyucu olarak erişebiliyorsa erişim devam eder. Buna karşılık, alt öğenin EKL'si kullanıcıya erişim izni verse bile kullanıcı, üst öğenin okuyucusu reddedildiyse kullanıcı erişimi olmaz.

EKL devralma zinciri değerlendirilirken değerlendirme sırası, yetkilendirme kararının sonucunu değiştirebilir. Cloud Search, EKL devralma zincirleri için özellikten köke uzanan değerlendirme sırası sunar. Özellikle, bir zincir için EKL kararı, bir alt kuruluşun üst ekibiyle birlikte değerlendirilmesiyle başlar ve kök üst öğeye kadar ilerleyebilir.

Örneğin, alt çocuğun devralma türü CHILD_OVERRIDE ise ve kullanıcının alt öğeye erişimi varsa Drive'ın üst öğeyi değerlendirmesi gerekmez. Ancak alt alt öğede PARENT_OVERRIDE veya BOTH_PERMIT varsa Drive, devralmayı zincirde daha yukarılarda 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ı ilişkileri EKL devralma kurallarından tamamen bağımsızdır. Örneğin, dosya sistemindeki bir dosya, silme amacıyla bir klasörde bulunabilir ancak EKL'yi farklı bir klasörden devralabilir. Bir klasörü sildiğinizde, EKL'yi devralan öğeler klasörün kapsama hiyerarşisinde de olmadığı sürece silinmez.

Bu erişim denetimleri Şekil 2'de gösterilmektedir:

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

Erişim denetimlerine bağlı olarak şu erişim kuralları geçerli olur:

• Dolaylı erişim, setInheritFrom() yönteminden gelir. Bu nedenle, C öğesi A öğesinin EKL'sini devraldığı için 1. kullanıcı C öğesine erişebilir.
• Dolaylı erişim, B öğesinin içerdiği C öğesinden gelmez. Dolayısıyla, 2. kullanıcı C öğesine erişemez.

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

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

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

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

Bir kaynakta setInheritFrom() yöntemi kullanılarak silinen bir öğe varsa ancak setContainer() kullanılarak kapsayıcı grubu yoksa veya kapsayıcı hiyerarşisi silinmiş öğe içermiyorsa 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 nasıl çalıştığına dair bir örnek gösterilmektedir.

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

Bu erişim denetimleri Şekil 3'te gösterilmektedir:

• Kullanıcı 1, A öğesinin doğrudan izin verilen ana hesabıdır.
• Kullanıcı 2, D öğesinin doğrudan izin verilen ana hesabıdı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ı öğesi içermedikleri için kök düzeyinde öğelerdir.

Kapsayıcı referansları aracılığıyla basamakları siler. A öğesi silindiğinde:

• setInheritFrom() başvurusunun tüm alt öğeleri, tüm kullanıcılar için erişimi kaybeder.
• Hiçbir kullanıcı A öğesine erişemez.
• D öğesi örtülü bir şekilde silinir. Hiçbir kullanıcı D öğesine erişemez.
• Silme işlemi yalnızca kapsayıcı referansları üzerinden kademeli olarak gerçekleştiği için E öğesi silinmez.
• Öğe E'ye ulaşılamaz ve hiçbir kullanıcı E öğesini arayamaz.