Eşleme EKL'leri

Yalnızca erişimi olan kullanıcıların arama sonuçlarında görebilmesi için öğeleri kurumsal depodaki erişim kontrol listeleriyle (EKL'ler) birlikte indeksleyin. Depo erişim kontrol listelerini modellemeniz ve öğeleri dizine eklerken bunları dahil etmeniz gerekir. Content Connector SDK, çoğu deponun erişim kontrol listelerini modelleme yöntemleri sunar.

Not: İçerik Bağlayıcı SDK'sı, tek alanlı erişim kontrol listelerini destekler ancak alanlar arası erişim kontrol listelerini desteklemez. Kuruluşunuzun dışındaki kullanıcılara ve gruplara erişim izni veremezsiniz. Kuruluşunuz dışındaki kullanıcıları veya grupları ifade eden erişim kontrol listelerinin etkisi yoktur.

EKL oluşturma

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

1. ACL sınıfındaki statik yöntemleri kullanarak Principal oluşturun.
2. ACL'yi asıl kullanıcıyı kullanarak oluşturmak için Acl.Builder sınıfını kullanın.

Bu belgede, devralma ve kapsama gibi erişim kontrol listelerini modelleme ve oluşturma kavramları ele alınmaktadır.

Harici kimlik kullanarak asıl oluşturma

Google Cloud Search, kullanıcıların ve grupların Google e-posta adreslerine yönlendirilmesini gerektirir. İçerik bağlayıcılar, depo öğelerini dizine eklerken bu e-posta adreslerine sahip olmayabilir. Ancak İçerik Bağlayıcı SDK, bir öğeyi dizine eklemek için e-posta adresi yerine harici kimlik (bir kullanıcıya veya gruba depo öğelerine erişim izni veren kimlik) kullanmanıza olanak tanır. Harici kimlikler içeren asıl öğeler oluşturmak için getUserPrincipal yöntemini veya getGroupPrincipal yöntemini kullanın. ACL sınıfı, Principal nesneleri oluşturmak için birkaç başka statik yöntem içerir.

Not: Kullanıcılar, harici kimlikleri Google Hesaplarıyla senkronize edilene kadar arama sonuçlarında öğe görmez. Harici kullanıcı veya grup kimliklerini Google e-posta adresiyle senkronize etmek için bir kimlik bağlayıcı kullanabilirsiniz. Daha fazla bilgi için Kimlik bağlayıcı oluşturma başlıklı makaleyi inceleyin.

Bir öğenin kimliğini 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 başlıklı makaleyi inceleyin.

EKL devralma

EKL devralma, belirli bir öğe ve kullanıcının yetkilendirmesini ifade eder. Bu yetkilendirme, öğenin ve devralma zincirinin birleştirilmiş EKL'lerine dayanır. Yetkilendirme kararıyla ilgili kurallar, depoya ve öğe özelliklerine bağlıdır.

Devralmayı ayarlama

Her öğe, doğrudan izin verilen asıl kullanıcılar ve doğrudan izin verilmeyen asıl kullanıcılar içerebilir. Bu kullanıcılar, setReaders ve setDeniedReaders yöntemleri kullanılarak belirtilir. Doğrudan izin verilen asıl, bir öğeye doğrudan erişimi olan bir öğe ile tanımlanan bir kullanıcıdır. Doğrudan erişimi reddedilen asıl, bir öğeye erişimi olmadığı bir ACL'de tanımlanan kullanıcıdır.

Bir öğe, setInheritFrom yöntemini kullanarak dolaylı olarak izin verilen asıl kullanıcıları ve dolaylı olarak reddedilen asıl kullanıcıları da devralabilir. Dolaylı olarak izin verilen bir asıl, EKL devralma yoluyla bir öğeye dolaylı erişime sahiptir. Dolaylı olarak reddedilen bir asıl, devralma yoluyla erişimden reddedilir.

Not: Devralmayı setInheritFrom yöntemini kullanarak ayarlarsanız devralma türünü de setInheritanceType yöntemini kullanarak ayarlamanız gerekir. Devralma türleri hakkında bilgi için Devralma türünü ayarlama başlıklı makaleyi inceleyin.

Şekil 1'de, asıl kullanıcıları devralmak için setInheritFrom yönteminin nasıl kullanılacağı gösterilmektedir.

Şekil 1. setInheritFrom yöntemi.

Şekil 1'de şu erişim kontrolleri gösterilmektedir:

• 1. kullanıcı, A öğesinin doğrudan izin verilen asıl sorumlusudur.
• Kullanıcı 2, B öğesinin doğrudan izin verilen asıl öğesidir.
• B öğesi, A öğesinin EKL'sini devralır.

Bu denetimlere göre erişim kuralları şunlardır:

• Kullanıcı 1, açıkça belirtilmeden öğe B'nin dolaylı olarak izin verilen sorumlusudur. Erişim, öğe A'dan devralınır.
• 2. kullanıcı, A öğesinin dolaylı olarak izin verilen asıl sahibi değil.

Devralma türünü ayarlama

Devralmayı setInheritFrom yöntemiyle ayarlarsanız devralma türünü setInheritanceType yöntemiyle ayarlamanız gerekir. Devralma türü, alt ACL'nin üst ACL ile nasıl birleşeceğini belirler. The Acl.InheritanceType üç türü uygular:

• BOTH_PERMIT - Yalnızca hem çocuğun hem de ebeveynin EKL'si izin verdiğinde erişim izni verin.
• CHILD_OVERRIDE - Çakışma olması durumunda alt EKL, üst EKL'ye göre önceliklidir. Kullanıcı, ebeveyn izin vermese bile çocuğa erişebilir veya ebeveyn izin verse bile çocuğa erişimi engellenebilir.
• PARENT_OVERRIDE - Çakışma olması durumunda üst EKL, alt EKL'ye göre önceliklidir.

Cloud Search, EKL devralma zincirlerini yapraktan köke doğru değerlendirir. Değerlendirme, çocuk ve ebeveynleriyle başlar ve kök ebeveyne kadar ilerleyebilir.

Örneğin, çocuk CHILD_OVERRIDE kullanıyorsa ve kullanıcının erişimi varsa Cloud Search'ün üst öğeyi değerlendirmesi gerekmez. Ancak çocuk PARENT_OVERRIDE veya BOTH_PERMIT kullanıyorsa Cloud Search, zincir boyunca değerlendirmeye devam eder.

Kapsama ve öğe silme

Bir öğeyi dizine eklerken IndexingItemBuilder sınıfının setContainer yöntemini kullanarak öğeyi kapsayıcı olarak etiketleyebilirsiniz. Bu ilişki, fiziksel hiyerarşiyi oluşturur ve uygun şekilde silinmesini sağlar. Bir kapsayıcıyı sildiğinizde, kapsayıcının içerdiği öğeler de silinir.

Kapsama ilişkileri, EKL devralma kurallarından bağımsızdır. Örneğin, bir klasör silme amacıyla bir dosya içerebilir ancak dosya, ACL'sini farklı bir klasörden devralabilir. Bir klasörün silinmesi, kapsama hiyerarşisinde de bulunmadıkları sürece, erişim kontrol listesini devralan öğeleri silmez.

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

• 1. kullanıcı, A öğesinin doğrudan izin verilen asıl sorumlusudur.
• Kullanıcı 2, B öğesinin doğrudan izin verilen asıl öğesidir.
• 3. kullanıcı, C öğesinin doğrudan izin verilen asıl sorumlusudur.
• 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.

Bu denetimlere göre erişim kuralları şunlardır:

• Dolaylı erişim, setInheritFrom yönteminden gelir. 1. kullanıcı, A öğesinden devraldığı için C öğesine erişebilir.
• Dolaylı erişim, kapsama alanından gelmez. 2. kullanıcı C öğesine erişemez.

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

ACL devralma özelliğinin kapsama özelliğinden ayrılması, birçok yapıyı modellemenize olanak tanır.

Bir öğeyi sildiğinizde:

• Silinen öğeyi içeren tüm öğeler aranamaz hale gelir ve silinmek üzere planlanır.
• setInheritFrom içinde silinen öğeyi belirten tüm öğeler aranamaz hale gelir.

Bir kaynak, silinen bir öğe için setInheritFrom kullanıyorsa ancak kapsayıcı ayarlanmamışsa veya hiyerarşisinde silinen öğe yoksa öğe veri kaynağında kalır. Bu dosyayı silmek sizin sorumluluğunuzdadır.

Şekil 3'te, bir öğe hiyerarşisinin silinmesiyle ilgili bir örnek gösterilmektedir.

Şekil 3. Öğe ve ACL devralma silme.

3. şekil, şu erişim denetimlerini gösterir:

• 1. kullanıcı, A öğesinin doğrudan izin verilen asıl sorumlusudur.
• 2. kullanıcı, D öğesinin doğrudan izin verilen asıl sorumlusudur.
• D ve E öğeleri, A öğesinden devralınır.
• D öğesi, A öğesini kapsayıcısı olarak adlandırır.
• A ve E öğeleri, kök düzeyindeki öğelerdir.

Silme işlemleri, kapsayıcı referansları arasında kademeli olarak gerçekleşir. A öğesini sildiğinizde:

• setInheritFrom referansının tüm alt öğeleri erişimi kaybeder.
• Kullanıcılar artık A öğesine erişemez.
• D öğesi örtülü olarak silinir ve erişilemez hâle gelir.
• E öğesi silinmez ancak ulaşılamaz ve aranamaz hale gelir.