Eşleme EKL'leri

Bir öğeyi yalnızca erişimi olan kullanıcıların arama sonucunda görebilmesini sağlamak için öğeleri kurumsal depodaki erişim kontrol listeleriyle (EKL'ler) birlikte dizine eklemeniz gerekir. Deponuzun erişim kontrol listelerini modellemeniz ve depodaki öğeleri dizine eklerken bu erişim kontrol listelerini eklemeniz gerekir. İçerik Bağlayıcı SDK'sı, çoğu depodaki EKL'leri modellemek için yeterince güçlü olan zengin bir EKL yöntemi grubu sağlar.

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şunuzun dışındaki kullanıcıları veya grupları ifade eden tüm erişim kontrol listelerinin (ACL) etkisi olmaz.

EKL oluşturma

EKL oluşturmak 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 belgenin geri kalanında, devralma ve kapsama gibi, modelleme ve ACL oluşturma için bilmeniz gereken bazı 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 adresine çözümlenmesini 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 herhangi bir 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 kullanıcılar oluşturmak için getUserPrincipal() yöntemini veya getGroupPrincpal() yöntemini kullanın. Principal nesneleri oluşturmak için kullanılan ACL sınıfında başka birkaç statik yöntem vardır.

Not: Kullanıcıların harici kimlikleri Google Hesaplarıyla senkronize edilene kadar arama sonuçlarında öğeler gösterilmez. Bu harici kullanıcı veya grup kimliklerinin bir Google e-posta adresiyle senkronizasyonu, bir kimlik bağlayıcı kullanılarak gerçekleştirilebilir. Kimlik bağlayıcılar hakkında daha fazla bilgi için Kimlik bağlayıcı oluşturma başlıklı makaleyi inceleyin.

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

ACL devralma, belirli bir öğe ve belirli bir kullanıcı için yetkilendirmeyi ifade eder. Bu yetkilendirme, öğenin ACL'leri ile devralma zincirinin ACL'lerinin bir kombinasyonunun sonucuna dayanır. Yetkilendirme kararı verilirken kullanılan kurallar, depoya ve öğenin özelliklerine bağlıdır.

Devralmayı ayarlama

Her öğe, setReaders() ve setDeniedReaders() yöntemleri kullanılarak belirtilen doğrudan izin verilen asıl kullanıcılar ve doğrudan izin verilmeyen asıl kullanıcılar içerebilir. Doğrudan izin verilen asıl, bir ACL'de tanımlanan ve belirli bir öğeye doğrudan erişim izni veren kullanıcıdır. Doğrudan erişimi reddedilen asıl, bir öğeye erişimi olmadığı bir erişim kontrol listesinde (ACL) 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 asıl, ACL devralma yoluyla belirli bir öğeye dolaylı erişimi olan kullanıcıdır. Dolaylı olarak erişimi reddedilen asıl, ACL devralma yoluyla belirli bir öğeye erişimi reddedilen kullanıcıdır.

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

Şekil 1'de, dolaylı olarak izin verilen ve dolaylı olarak reddedilen asıl kullanıcıların devralınması için setInheritFrom() yönteminin nasıl kullanıldığı gösterilmektedir.

1. şekil. setInheritFrom() yöntemi.

Bu erişim kontrolleri Şekil 1'de 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 sorumlusudur.
• B öğesi, A öğesinin EKL'sini devralır.

Erişim denetimlerine göre erişim kuralları şunlardır:

• Kullanıcı 1'in, B öğesinin dolaylı olarak izin verilen sorumlusu olması için B öğesinin sorumlusu olarak açıkça belirtilmesi gerekmez. Erişim, Kullanıcı 1, A öğesinin doğrudan izin verilen sorumlusu olarak listelendiği ve B öğesi EKL'sini A öğesinden devraldığı için devralınır.
• 2. kullanıcı, A öğesi için izin verilen dolaylı bir asıl sorumlu 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 öğenin ACL'sinin üst öğenin ACL'siyle nasıl birleşeceğini belirler. Acl.InheritanceType üç devralma türünü uygular:

• BOTH_PERMIT - Bir kullanıcıya öğeye yalnızca hem alt öğenin ACL'si hem de üst öğenin devralınan öğe ACL'si kullanıcının öğeye erişmesine izin verdiğinde erişim izni vermek için devralma türünü BOTH_PERMIT olarak ayarlayın.

• CHILD_OVERRIDE - Çakıştıklarında alt öğenin ACL'sinin devralınan üst öğenin ACL'sinden öncelikli olmasını zorlamak için devralma türünü CHILD_OVERRIDE olarak ayarlayın. Bu nedenle, üst öğenin ACL'si kullanıcıya okuyucu olarak erişimi reddediyorsa kullanıcı, alt öğeye okuyucu olarak erişebiliyorsa erişimi devam eder. Aksine, üst öğenin erişim kontrol listesi kullanıcıya erişim izni verse bile kullanıcı, alt öğenin okuma erişimi reddedilen bir okuyucusuysa erişime sahip olmaz.

• PARENT_OVERRIDE - Çakıştıklarında üst öğenin ACL'sinin alt öğenin ACL'sinden öncelikli olmasını zorlamak için devralma türünü PARENT_OVERRIDE olarak ayarlayın. Bu nedenle, alt öğenin ACL'si kullanıcıya okuyucu olarak erişimi reddediyorsa kullanıcı, üst öğeye okuyucu olarak erişebildiği sürece erişmeye devam edebilir. Aksine, alt öğenin erişim kontrol listesi kullanıcıya erişim izni verse bile, kullanıcı üst öğenin okuma erişimi reddedilmiş bir okuyucusuysa erişemez.

Bir ACL 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 doğru değerlendirme sırası sağlar. Özellikle, bir zincir için erişim kontrol listesi kararı, bir alt öğenin üst öğeleriyle birlikte değerlendirilmesiyle başlar ve kök üst öğeye kadar ilerleyebilir.

Örneğin, çocuğun CHILD_OVERRIDE devralma türü varsa ve kullanıcının çocuğa erişimi varsa Drive'ın üst öğeyi değerlendirmesi gerekmez. Ancak çocuğun hesabında PARENT_OVERRIDE veya BOTH_PERMIT varsa Drive, zincirde daha yukarıdaki devralma işlemlerini 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. Kapsayıcı/kapsanan ilişkisi, öğelerin fiziksel hiyerarşisini oluşturur ve öğelerin düzgün şekilde silinmesini sağlar. Bir kapsayıcı silindiğinde, içerdiği öğeler de silinir.

Kapsama ilişkileri, tamamen ACL devralma kurallarından bağımsızdır. Örneğin, bir dosya sistemindeki bir dosya, silme amacıyla bir klasörde yer alabilir ancak farklı bir klasördeki erişim kontrol listesini (ACL) devralabilir. Bir klasörü silmek, klasörün kapsama hiyerarşisinde de yer almadığı sürece, klasörün erişim kontrol listesini devralan öğeleri silmez.

Bu erişim kontrolleri Şekil 2'de 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 sorumlusudur.
• 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.

Erişim denetimlerine göre erişim kuralları şunlardır:

• Dolaylı erişim, setInheritFrom() yönteminden gelir. Bu nedenle, kullanıcı 1, öğe C, öğe A'nın EKL'sini devraldığı için öğe C'ye erişebilir.
• Dolaylı erişim, C öğesinin B öğesi tarafından kapsanmasından kaynaklanmaz. Bu nedenle, 2. kullanıcı C öğesine erişemez.

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

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

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

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

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

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

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

• 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 öğesi ve 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ı öğeleri olmadığı için kök düzeyindeki öğelerdir.

Silme işlemleri, kapsayıcı referansları boyunca kademeli olarak gerçekleşir. A öğesi silindiğinde:

• setInheritFrom() referansının tüm alt öğeleri, tüm kullanıcılar için erişimini kaybeder.
• Hiçbir kullanıcı A öğesine erişemez.
• D öğesi örtülü olarak silinir. Hiçbir kullanıcı D öğesine erişemez.
• Silme işlemi yalnızca kapsayıcı referansları üzerinden yapıldığından E öğesi silinmez.
• E öğesine ulaşılamaz ve hiçbir kullanıcı E öğesini arayamaz.