Wiki

İzinler

Bir gruba veya kullanıcıya bir deponun klasörleri üzerinde read / write / none erişimi verin. Desenler, öncelik, varsayılan çözümleme, izin testi.

Giriş

Permissions sekmesi, belirli bir depo için kimin hangi klasörlerde okuma veya yazma yapabileceğini tanımlar. Bir izin bir grubu veya bir kullanıcıyı hedefler, bir yol desenine uygulanır ve bir düzey (write / read / none) taşır. Rol, bir hesabın ne yapabileceğini; izin ise hangi dosyalar üzerinde olduğunu söyler.

Erişim ve roller

Sekme, süper yöneticiye (tüm depolar) ve project_admin için (yönettiği depolar) açıktır. Kurallar her zaman seçili depoya bağlıdır.

Sekmenin üç paneli

Permissions sekmesi, yönetim panelinin PROJECT satırında bulunur: burada yaptığınız her şey yalnızca satırın başındaki seçicide gösterilen depo için geçerlidir. Hemen üstteki SERVER satırı ise tam tersine tüm sunucuyu ilgilendirir ve hesaplar ile gruplar oradadır.

Sekme, yukarıdan aşağıya üç ayrı paneli üst üste dizer. Bunlar üç farklı soruyu yanıtlar ve ilk ikisini klasör ağacıyla karıştırmak bu sayfadaki en sık destek çağrısı nedenidir.

Panel	Yanıtladığı soru	Kimin erişimi var
Project Admins	Bu projeyi kim yönetiyor?	Yalnızca süper yönetici
Build Access	Bu projenin build'lerini kim indirebilir?	Süper yönetici ve project_admin
İzin ağacı	Kim hangi klasörlerde okuyabilir veya yazabilir?	Süper yönetici ve project_admin

Yukarıdan görülen Permissions sekmesi, üç paneli üst üste dizilmiş ve dolu: bir proje yöneticisini listeleyen Project Admins, verilmiş bir erişimi listeleyen Build Access, ardından izin ağacının başlangıcı. Üstte PROJECT satırı ve depo seçicisi görünür.

Bu sayfanın geri kalanı önce ana panel olan izin ağacını, sonra diğer ikisini anlatır.

Üç düzey

Düzey	Etki
`write`	Kapsanan yollarda okuma ve yazma (check-out, check-in).
`read`	Salt okunur: eşitleyebilir, değiştiremez.
`none`	Erişim yok: daha geniş bir kural izin verecek olsa bile bir klasörü açıkça gizler.

Erişim verme

1. Doğru projede Permissions sekmesini açın

PROJECT satırı, satırın başındaki depo seçici: her şeyden önce gösterilen projeyi doğrulayın, kurallar yalnızca ona bağlanacaktır.

2. Özneyi seçin

Seçicide bir grup veya bir kullanıcı alın: liste Groups ve Users olmak üzere iki alt listeye ayrılmıştır. Bir kural birini veya diğerini hedefler, asla ikisini birden. Hiçbir özne seçilmediği sürece Apply düğmesi etkin değildir.

3. Klasörleri işaretleyin

Klasör ağacında ilgili olanları işaretleyin. Kutular üç durumludur (tümü, kısmi, hiçbiri) ve Filter folders... alanı proje büyük olduğunda ağacı daraltır.

4. Düzeyi seçin ve uygulayın

Bir klasör işaretlenir işaretlenmez bir çubuk belirir: seçilen klasör sayısını bildirir ve üç düzeyi (write, read, none) sunar. Birini seçin, ardından Apply düğmesine tıklayın. Öznenin kuralları o zaman aşağıda, Active rules tablosunda (Path Pattern, Permission, Priority) görünür ve bunları tek tek silebilirsiniz.

Birkaç klasörü işaretli klasör ağacı, sol üstteki özne seçici, seçilen klasör sayısını bildiren çubuk ile write, read ve none hapları ve sağdaki Apply düğmesi, ardından Active rules tablosu ve Path Pattern, Permission ve Priority sütunları.

Kullanıcı adıyla verme

"+ By username" düğmesi, görünür listede yer almayan birine tam adını yazarak erişim vermenizi sağlar. Bu, henüz hiçbir izne sahip olmayan bir playtester gibi, olağan kapsamınızın dışındaki bir hesaba erişim vermenin yoludur.

Ad tam olarak eşleşmelidir (ön ek yok). Alan yalnızca tanımlayıcıyı ve adı döndürür, asla rolü döndürmez; böylece mevcut hesapları yoklamak için kullanılamaz.

Desenler ve öncelik

Bir kural belirli bir dosyayı değil, bir yol desenini, yani glob denen şeyi hedefler: bir kısaltma yazımıdır; burada * bir addaki herhangi bir karakter dizisini, ** ise herhangi bir derinlikteki herhangi bir klasör dizisini temsil eder. Böylece Content/Maps/**, Content/Maps altındaki her şeyi, alt klasörler dahil, belirtir. Bunları elle yazmanız gerekmez: ağaçta bir klasörü işaretlemek, karşılık gelen glob'u üretir.

İşaretlenmiş bir klasör Foo/Bar, Foo/Bar/** desenine dönüşür (klasör ve içerdiği her şey, herhangi bir derinlikte). Deponun kökü /** olur.

Her kural, klasörün derinliğine eşit otomatik bir öncelik alır (segment sayısı, kök = 0). Bu nedenle daha özgül (daha derin) bir kural, daha genel olana üstün gelir. Örnek: Content/** üzerinde write ve Content/Secret/** üzerinde none, Content/ içinde her yerde yazma erişimi verir, yalnızca Secret/ hariç.

Otomatik gruplama Bir klasörün tüm alt öğelerini işaretlerseniz, istemci bunları tek bir Parent/** kuralında gruplar (gelecekteki alt klasörleri de kapsar) ve gereksiz hale gelen alt kuralları kaldırır.

Varsayılan çözümleme

Açık hiçbir kural bir yolu kapsamadığında, etkin erişim şu modeli izler:

Varsayılan olarak, hiçbir kural eşleşmediğinde erişim read (okuma) olur.
admin ve lead her yerde write haklarına sahiptir (rol atlaması).
Bir project_admin, yönettiği depolarda write hakkına sahiptir, başka yerlerde özel bir şey yoktur.
Aksi halde en özgül kural uygulanır; o yoksa varsayılan okuma geçerlidir.

Başka bir deyişle: depoya zaten erişimi olan birine bir klasörün okunmasını yasaklamak için hiçbir şey vermemek yetmez (varsayılan read'tir), açık bir none kuralı gerekir.

Varsayılan read depoya değil, klasörlere ilişkindir Varsayılan read, "kişinin zaten erişimi olan bir deponun içindeki bu yol" sorusunu yanıtlar. Hiçbir depoyu herkese açık hale getirmez. Bir depo üzerinde none dışında hiçbir kurala (ne doğrudan ne de bir grup aracılığıyla) sahip olmayan bir hesap, o depoyu hiç göremez: ne depo listesinde ne de çalışma alanında görünür ve sunucu rotaları onu reddeder.

Pratik sonuç, ve gereksiz işten kurtarır: hiçbir kuralı olmayan yepyeni bir proje zaten herkese kapalıdır, yalnızca admin ve lead rolleri ile kendi project_admin'leri hariç. Bu nedenle bir projeyi "kapatmak" için her yere none kuralları koymak gerekmez; yalnızca açmak istediğinizi vermeniz yeterlidir. none kuralları, zaten verilmiş bir erişimin içini bölmeye yarar, örneğin Content/ sahibi bir takımdan Content/Secret/ klasörünü gizlemek için.

Bir proje yöneticisi atama

Sekmenin üstündeki Project Admins paneli, seçili depoyu kimin yönettiğini belirler. Bu panel yalnızca süper yöneticiye ayrılmıştır: yetkiyi vermek, onu kullanmanın bir üst basamağıdır.

Prosedür şu sırayla iki aşamalıdır:

1. Rolü Users sekmesinde verin

SERVER satırı, Users sekmesi: kişiye project_admin rolünü verin. Bu rol atanana kadar kişi bu panelin listesinde görünmez, panel de bunu zaten söyler: "No one to add. Give someone the Project Admin role on the Users tab first".

2. Kişiyi depoya bağlayın

Buraya dönün, PROJECT satırı seçicisinde gösterilen depoyu doğrulayın, ardından Project Admins panelinde Add düğmesine tıklayın, kişiyi seçin ve Grant düğmesine tıklayın. Kişi hemen panelin listesinde görünür.

Ekleme sırasındaki Project Admins paneli: Grant düğmesinin yanındaki Select a project admin menüsü, altında zaten bağlanmış bir kişi, ardından granted by ibaresi ve kırmızı Revoke çarpı işareti.

Bir bağlantıyı kaldırma

Satır sonundaki kırmızı çarpı işareti (Revoke) depoyu kapsamından çıkarır. Bağlantısız rol hiçbir şey vermez: artık hiçbir depoyu yönetmeyen bir project_admin, Permissions, Rules, Webhooks, Files ve kullanıcı yönetimine erişimini kaybeder. Bu nedenle son depoyu kaldırmak, tüm yetkiyi de kaldırır.

Build erişimi

Build Access paneli, bu projenin yayımlanmış build'lerini istemcinin Games sayfasından kimin görüp indirebileceğini belirler. Süper yöneticiye ve kendi depolarındaki project_admin'e açıktır.

Bir projeyi bir playtester'a açmanın tek yolu budur Bir playtester hesabı, tasarım gereği hiçbir yol iznine sahip değildir: projenin dosyalarını görmesini engelleyen budur. Bu nedenle hiçbir izin ağacında görünmez ve ona ağaç üzerinden "erişim veremezsiniz". Build Access paneli tam da bu durum için vardır: dosyalara erişim vermeden build'lere erişim verir.

1. Ekleme formunu açın

Build Access panelinde Add düğmesine tıklayın. Bir giriş satırı belirir; bu satır, hedefin nasıl belirtileceğinin seçimiyle başlar.

2. Hedefi belirtin

User: listedeki bir hesap, yani projede zaten çalışan biri.
Group: bütün bir grup; bir öğrenci topluluğu veya yinelenen bir test ekibi için pratiktir.
By username: hesabın tam adını yazdığınız bir Exact username alanı. Hiçbir listede görünmediği için bir playtester için normal yoldur. Ad, ön ek olmadan tam olarak eşleşmelidir.

Ekleme sırasındaki Build Access paneli: By username olarak ayarlanmış tür menüsü, doldurulmuş Exact username alanı, sağdaki Grant düğmesi ve altında zaten verilmiş bir satır ile kırmızı kaldırma çarpı işareti.

3. Verin veya geri alın

Vermek için Grant düğmesine tıklayın. Var olan bir satırda Revoke, bir onayla erişimi kaldırır.

Sunucunun uyguladığı kural, sırasıyla:

Kim	Build erişimi
`admin`	Tüm depolar.
`project_admin`	Yönettiği depolar.
Diğer tüm roller	`download_builds` yeteneğine sahip olmalı (`viewer` dışında tüm roller buna sahiptir) ve ya depoya erişimi olmalı ya da bu panelde doğrudan veya bir grup aracılığıyla bir satırı bulunmalıdır.

Başka bir deyişle: projede zaten çalışan birinin burada başka bir şeye ihtiyacı yoktur. Bu panel projenin dışındaki kişilere hizmet eder ve bir viewer her durumda dışarıda kalır.

Bir izni test etme

Sekmenin en altındaki Test Permission paneli, "bu kullanıcının bu yol üzerinde hangi etkin erişimi var?" sorusunu yanıtlar. Kurallarınızdan hangisinin gerçekten karar verdiğini öğrenmenin en kısa yoludur.

1. Kullanıcıyı ve yolu seçin

User içinde bir hesap alın, ardından Path içine bir yol girin, örneğin /Content/Maps/Level01.umap. İkisi de doldurulmadığı sürece düğme etkin değildir.

2. Testi çalıştırın ve sonucu okuyun

Test düğmesine tıklayın. Sonuç, etkin düzeyin yanı sıra kararı veren kaynağı ve deseni gösterir; böylece bir erişimin neden verildiğini veya reddedildiğini anlarsınız.

Etkin düzeyi ve karar veren kaynağı ve deseni gösteren bir sonuçla Test Permission paneli.

Görme hakkınız olmayan bir kullanıcı için test, var olmayan bir hesapla aynı "bulunamadı" yanıtını döndürür; böylece hesapların varlığı açığa çıkmaz.

Sık karşılaşılan tuzaklar

"Hiçbir şey vermedim, yine de okuyabiliyor"

Bu, read varsayılanıdır ve yalnızca kişinin zaten erişimi olan bir deponun içinde işler. Projede çalışan birine bir klasörü kapatmak için üzerine açık bir none kuralı koyun.

"Depo, kişinin listesinde görünmüyor"

Kişi bu depo üzerinde none dışında hiçbir kurala sahip olmadığı sürece bu normaldir. read varsayılanı deponun kendisine erişim vermez. Doğrudan veya bir grup aracılığıyla ona en az bir read veya write kuralı verin, depo görünecektir. Yalnızca build'leri alması gereken bir playtester ise, harekete geçilecek yer burası değildir: bkz. Build erişimi.

İki kural birbiriyle çelişiyor

En özgül olan (en büyük derinlik) kazanır. Hangisinin karar verdiğini görmek için testi kullanın.

none kuralına rağmen bir lead yazma durumunda kalıyor

admin ve lead rolleri yol kurallarını atlar (her yerde write). Bir none kuralı onları kısıtlamaz. Kendi depolarındaki bir project_admin için de aynısı geçerlidir.

Grup üzerinden erişim ile doğrudan erişim

Bir erişim hesabın kendisinden veya üyesi olduğu bir gruptan gelebilir. Bir kuralı kaldırmak hiçbir şeyi değiştirmiyorsa, diğer kaynağı arayın (test hangisinin geçerli olduğunu gösterir).