Autorizzazioni

Introduzione

La scheda Permissions definisce, per un dato repository, chi può leggere o scrivere in quali cartelle. Un permesso ha come destinatario un gruppo o un utente, si applica a un pattern di percorso e porta un livello (write / read / none). Il ruolo dice ciò che un account può fare; il permesso dice su quali file.

Accesso e ruoli

La scheda è disponibile per il super admin (tutti i repository) e per il project_admin (i repository che amministra). Le regole sono sempre associate al repository selezionato.

I tre livelli

Concedere un accesso

1. Selezionate il repository, poi la scheda Permissions.
2. Scegliete il soggetto nel selettore: un gruppo o un utente (due sottoelenchi "Groups" e "Users"). Una regola riguarda l'uno o l'altro, mai entrambi.
3. Nell'albero delle cartelle, spuntate le cartelle interessate (le caselle hanno tre stati: tutto / parziale / niente). Un campo di ricerca filtra l'albero.
4. Nella barra che appare, scegliete il livello (write / read / none) e fate clic su Apply.

Le regole attive del soggetto sono mostrate in una tabella (pattern, livello, priorità) dove potete eliminarle una a una.

Concedere per nome utente

Il pulsante "+ By username" consente di concedere l'accesso a qualcuno che non compare nell'elenco visibile, digitando il suo nome esatto. È il modo per concedere l'accesso a un account al di fuori del vostro ambito abituale, ad esempio un playtester che non detiene ancora alcun permesso.

Il nome deve corrispondere esattamente (nessun prefisso). Il campo restituisce solo l'identificativo e il nome, mai il ruolo, per non servire a sondare gli account esistenti.

Pattern e priorità

Una cartella spuntata Foo/Bar diventa il pattern Foo/Bar/** (la cartella e tutto ciò che contiene, a qualsiasi profondità). La radice del repository diventa /**.

Ogni regola riceve una priorità automatica pari alla profondità della cartella (numero di segmenti, radice = 0). Una regola più specifica (più profonda) prevale quindi su una più generale. Esempio: write su Content/** e none su Content/Secret/** dà accesso in scrittura ovunque in Content/ tranne in Secret/.

Risoluzione predefinita

Quando nessuna regola esplicita copre un percorso, l'accesso effettivo segue questo modello:

• Per impostazione predefinita, l'accesso è read (lettura) quando nessuna regola corrisponde.
• admin e lead hanno write ovunque (bypass di ruolo).
• Un project_admin ha write sui repository che amministra e nulla di speciale altrove.
• Altrimenti si applica la regola più specifica; in mancanza di essa, la lettura predefinita.

In altre parole: per vietare a qualcuno la lettura di una cartella, non basta non concedere nulla (il valore predefinito è read), serve una regola none esplicita.

Testare un permesso

Il pannello Test Permission risponde a "quale accesso effettivo ha questo utente su questo percorso?". Scegliete un utente, inserite un percorso (es. /Content/Maps/Level01.umap) ed eseguite il test. Il risultato mostra il livello effettivo, oltre alla fonte e al pattern che hanno deciso, permettendovi di capire perché un accesso è concesso o negato.

Per un utente che non avete il diritto di vedere, il test restituisce lo stesso "non trovato" di un account inesistente, così da non rivelare l'esistenza degli account.

Trappole comuni

"Non ho concesso nulla, eppure può leggere"

È il valore predefinito read. Per chiudere una cartella, apponete una regola none esplicita su di essa.

Due regole si contraddicono

Vince la più specifica (profondità maggiore). Usate il test per vedere quale decide.

Un lead resta in scrittura nonostante una regola none

I ruoli admin e lead bypassano le regole di percorso (write ovunque). Una regola none non li limita. Lo stesso vale per un project_admin sui propri repository.

Accesso tramite gruppo vs. accesso diretto

Un accesso può provenire dall'account stesso o da un gruppo di cui è membro. Se rimuovere una regola non cambia nulla, cercate l'altra fonte (il test indica quale si applica).