Eşleme EKL'leri

Bir öğeye yalnızca erişimi olan kullanıcıların bu öğeyi arama sonucunda görebilmesini sağlamak için öğeleri, kuruluş deposundaki erişim kontrol listeleriyle (EKL'ler) dizine eklemeniz gerekir. Deponuzun ACL'lerini modellemeli ve depodaki öğeleri dizine eklerken bu ACL'leri eklemeniz gerekir. Content Connector SDK'sı, çoğu deponun EKL'lerini modelleyecek kadar güçlü bir EKL yöntemleri grubu sağlar.

Not: Content Connector SDK'sı tek alan ACL'lerini destekler ancak alanlar arası ACL'leri desteklemez. Kuruluşunuzun dışındaki kullanıcılara ve gruplara erişim izni veremezsiniz. Kuruluşunuzun dışındaki kullanıcılara veya gruplara atıfta bulunan ACL'lerin hiçbir etkisi yoktur.

EKL oluşturma

ACL oluşturma işlemi iki adımdan oluşur:

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

Bu belgenin geri kalanında, ACL'leri modellemek ve oluşturmak için bilmeniz gereken bazı kavramlar (ör. devralma ve kapsayıcı) ele alınmaktadır.

Harici kimlik kullanarak bir asıl öğe 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 Content Connector SDK'sı, bir öğeyi dizine eklemek için e-posta adresi yerine herhangi bir harici kimliği (kullanıcıya veya gruba depo öğelerine erişim izni veren kimlik) kullanmanıza olanak tanır. Harici kimlikler içeren ilkeler oluşturmak için getUserPrincipal() veya getGroupPrincpal() yöntemini kullanın. ACL sınıfında, Principal nesneleri oluşturmak için kullanılan başka statik yöntemler de vardır.

Not: Kuruluş dışı kimlikleri Google Hesaplarıyla senkronize edilene kadar kullanıcılar arama sonuçlarında öğeleri görmez. Bu kuruluş dışı kullanıcı veya grup kimliklerinin bir Google e-posta adresiyle senkronizasyonu, 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ısı 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 devralınması, belirli bir öğe ve belirli bir kullanıcı için öğenin ACL'lerinin ve devralma zincirinin ACL'lerinin bir kombinasyonunun sonucuna dayalı yetkilendirmeyi ifade eder. Yetkilendirme kararı almak için kullanılan kurallar, depoya ve öğenin özelliklerine bağlıdır.

Devralmayı ayarlama

Her öğenin, setReaders() ve setDeniedReaders() yöntemleri kullanılarak belirtilen doğrudan izin verilen ilkeleri ve doğrudan reddedilen ilkeleri olabilir. Doğrudan izin verilen asıl kişi, ACL'de tanımlanan ve belirli bir öğeye doğrudan erişim sağlayan bir kullanıcıdır. Doğrudan reddedilen asıl öğe, ACL'de belirli bir öğeye erişimi olmadığı tanımlanan bir kullanıcıdır.

Bir öğe, setInheritFrom() yöntemini kullanarak dolaylı olarak izin verilen ilkeleri ve dolaylı olarak reddedilen ilkeleri de devralabilir. Dolaylı olarak izin verilen bir asıl öğe, ACL devralma yoluyla belirli bir öğeye dolaylı olarak erişimi olan bir kullanıcıdır. Dolaylı olarak reddedilen asıl kişi, ACL devralma yoluyla belirli bir öğeye erişimi reddedilen kullanıcıdır.

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

Şekil 1'de, dolaylı olarak izin verilen ve dolaylı olarak reddedilen ilkeleri devralmak için setInheritFrom() yönteminin 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 bir asıl kullanıcısıdır.
• 2. kullanıcı, B öğesinin doğrudan izin verilen bir asıl kişisidir.
• B öğesi, A öğesinin EKL'sini devralır.

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

• 1. kullanıcının, B öğesinin dolaylı olarak izin verilen bir öğesi olması için B öğesinin öğesi olarak açıkça belirtilmesi gerekmez. 1. kullanıcı, A öğesinin doğrudan izin verilen bir öğesi olarak listelendiği ve B öğesi EKL'sini A öğesinden devraldığı için erişim devralınır.
• 2. kullanıcı, A öğesine dolaylı olarak izin verilen bir asıl öğe değildir.

Devralınan veri türünü ayarlama

Devralımı setInheritFrom() yöntemini kullanarak ayarlarsanız devralma türünü setInheritanceType() yöntemini kullanarak ayarlamanız gerekir. Devralınma türü, alt öğenin ACL'sinin üst öğenin ACL'siyle nasıl birleştirileceğini belirler. Acl.InheritanceType sınıfı üç tür devralma uygular:

• BOTH_PERMIT: Bir kullanıcıya öğeye yalnızca hem alt öğenin ACL'si hem de üst öğenin devralınan öğe ACL'si bu 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ışan durumlarda alt öğenin ACL'sinin, devralınan üst öğenin ACL'sinden öncelikli olmasını sağlamak için devralma türünü CHILD_OVERRIDE olarak ayarlayın. Dolayısıyla, üst öğenin ACL'si kullanıcıya reddedilen okuyucu olarak erişim izni vermezse kullanıcı, alt öğeye okuyucu olarak erişebiliyorsa yine de erişebilir. Buna karşılık, üst öğenin ACL'si kullanıcıya erişim izni verse bile alt öğenin okuma izni verilmemişse kullanıcının erişimi yoktur.

• PARENT_OVERRIDE: Çakışan durumlarda üst öğenin ACL'sinin alt öğenin ACL'sinden öncelikli olmasını sağlamak için devralma türünü PARENT_OVERRIDE olarak ayarlayın. Dolayısıyla, alt öğenin ACL'si kullanıcıya reddedilen okuyucu olarak erişim izni vermese bile kullanıcı, üst öğeye okuyucu olarak erişebiliyorsa erişim elde eder. Buna karşılık, alt öğenin ACL'si kullanıcıya erişim izni verse bile kullanıcı, üst öğenin okuyucu izni yoksa erişemez.

Bir ACL devralma zinciri değerlendirilirken değerlendirme sırası, yetkilendirme kararının sonucunu değiştirebilir. Cloud Search, ACL devralma zincirleri için yapraktan köke doğru bir değerlendirme sırası sağlar. Daha açık belirtmek gerekirse, bir zincir için ACL kararı, alt öğenin ebeveynleriyle değerlendirilmesiyle başlar ve kök ebeveyne kadar ilerleyebilir.

Örneğin, alt öğenin devralma türü CHILD_OVERRIDE ise ve kullanıcı alt öğeye erişebiliyorsa Drive'ın üst öğeyi değerlendirmesi gerekmez. Ancak çocukta PARENT_OVERRIDE veya BOTH_PERMIT varsa Drive, zincirin üst kısmında devralmayı değerlendirmeye devam eder.

Kısıtlama 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, kapsayıcıdaki öğeler de silinir.

Kapsatma ilişkileri, ACL devralma kurallarından tamamen bağımsızdır. Örneğin, bir dosya sisteminde bulunan bir dosya, silme amacıyla bir klasör tarafından içerilebilir ancak ACL'yi farklı bir klasörden devralabilir. Bir klasör silindiğinde, klasörün ACL'sini devralan öğeler de silinmez (bu öğeler klasörün kapsayıcı hiyerarşisinde de bulunmadığı sürece).

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

• 1. kullanıcı, A öğesinin doğrudan izin verilen bir asıl kullanıcısıdır.
• 2. kullanıcı, B öğesinin doğrudan izin verilen bir asıl kişisidir.
• 3. kullanıcı, C öğesine doğrudan izin verilen bir asıl öğedir.
• C öğesi, A öğesinin EKL'sini devralır.
• B öğesi, A öğesini kapsayıcı olarak adlandırır.
• C öğesi, B öğesini kapsayıcı olarak adlandırır.

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

• Dolaylı erişim, setInheritFrom() yönteminden gelir. Bu nedenle, 1. kullanıcı C öğesine erişebilir çünkü C öğesi A öğesinin EKL'sini devralır.
• Dolaylı erişim, C öğesinin B öğesinde yer almasından kaynaklanmaz. Bu nedenle 2. kullanıcı C öğesine erişemez.

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

ACL devralımının kapsayıcı hiyerarşisi ile ayrılması, birçok farklı mevcut yapıyı modellemenize olanak tanır.

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

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

Bir kaynakta setInheritFrom() yöntemi kullanılarak silinmiş bir öğe varsa ancak setContainer() yöntemi kullanılarak ayarlanmış bir kapsayıcı yoksa veya kapsayıcı hiyerarşisi silinmiş öğe içermiyorsa söz konusu öğe ve verileri Google'ın veri kaynağında kalır. Öğeyi silmekten siz sorumlusunuz.

Şekil 3'te, öğe hiyerarşisi için silme işleminin nasıl çalıştığına dair bir örnek gösterilmektedir.

Şekil 3. Öğe silme ve ACL devralma

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

• 1. kullanıcı, A öğesinin doğrudan izin verilen bir asıl kullanıcısıdır.
• 2. kullanıcı, D öğesine doğrudan izin verilen bir asıl öğedir.
• D ve E öğeleri, A öğesinin EKL'sini devralır.
• D öğesi, kapsayıcısı olarak A öğesini adlandırır.
• A ve E öğeleri, kapsayıcı öğeleri olmadığı için kök düzeyinde öğelerdir.

Container referansları aracılığıyla basamaklı silme işlemi gerçekleştirir. 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 silinir. Hiçbir kullanıcı D öğesine erişemez.
• Silme işlemi yalnızca kapsayıcı referansları üzerinden basamaklandırıldığı için E öğesi silinmez.
• E öğesine erişilemez hale gelir ve hiçbir kullanıcı E öğesini arayamaz.