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 pannelli della scheda

La scheda Permissions vive nella riga PROJECT del pannello di amministrazione: tutto ciò che vi fate vale solo per il repository mostrato nel selettore, in testa alla riga. La riga SERVER, appena sopra, riguarda invece l'intero server, ed è lì che vivono gli account e i gruppi.

La scheda impila tre pannelli distinti, dall'alto verso il basso. Rispondono a tre domande diverse, e confondere i primi due con l'albero delle cartelle è la causa di richiesta di assistenza più frequente in questa pagina.

Il resto di questa pagina descrive prima l'albero delle autorizzazioni, che è il pannello principale, poi gli altri due.

I tre livelli

Concedere un accesso

1. Aprire la scheda Permissions sul progetto giusto

Riga PROJECT, selettore di repository in testa alla riga: verificate prima di tutto il progetto mostrato, le regole saranno associate soltanto a esso.

2. Scegliere il soggetto

Nel selettore, prendete un gruppo o un utente: l'elenco è diviso in due sottoelenchi, Groups e Users. Una regola riguarda l'uno o l'altro, mai entrambi. Finché non è scelto alcun soggetto, il pulsante Apply resta inattivo.

3. Spuntare le cartelle

Nell'albero delle cartelle, spuntate quelle interessate. Le caselle hanno tre stati (tutto, parziale, niente), e il campo Filter folders... riduce l'albero quando il progetto è grande.

4. Scegliere il livello e applicare

Una barra appare non appena una cartella è spuntata: indica il numero di cartelle selezionate e propone i tre livelli (write, read, none). Sceglietene uno, poi fate clic su Apply. Le regole del soggetto compaiono allora sotto, nella tabella Active rules (Path Pattern, Permission, Priority), 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 regola non punta a un file preciso ma a un pattern di percorso, ciò che si chiama un glob: una scrittura abbreviata in cui * sostituisce una qualsiasi sequenza di caratteri in un nome, e ** una qualsiasi sequenza di cartelle, a qualunque profondità. Così Content/Maps/** designa tutto ciò che si trova sotto Content/Maps, sottocartelle incluse. Non dovete scriverli a mano: spuntare una cartella nell'albero produce il glob corrispondente.

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 la lettura di una cartella a qualcuno che ha già accesso al repository, non basta non concedere nulla (il valore predefinito è read), serve una regola none esplicita.

Conseguenza pratica, e che evita lavoro inutile: un progetto nuovo senza alcuna regola è già chiuso a tutti, tranne che per i ruoli admin e lead e per i suoi stessi project_admin. Non è quindi necessario mettere regole none dappertutto per "chiudere" un progetto; basta concedere solo ciò che volete aprire. Le regole none servono a ritagliare all'interno di un accesso già concesso, per esempio per nascondere Content/Secret/ a un team che ha Content/.

Nominare un amministratore di progetto

Il pannello Project Admins, in cima alla scheda, designa chi amministra il repository selezionato. È riservato al super admin: concedere l'autorità è un gradino sopra l'esercitarla.

La procedura è in due tempi, in quest'ordine:

1. Dare il ruolo, nella scheda Users

Riga SERVER, scheda Users: date alla persona il ruolo project_admin. Finché questo ruolo non è assegnato, essa non compare nell'elenco di questo pannello, che del resto ve lo dice: "No one to add. Give someone the Project Admin role on the Users tab first".

2. Collegare la persona al repository

Tornate qui, verificate il repository mostrato nel selettore della riga PROJECT, poi nel pannello Project Admins fate clic su Add, scegliete la persona e fate clic su Grant. Essa compare subito nell'elenco del pannello.

Rimuovere un collegamento

La croce rossa a fine riga (Revoke) rimuove il repository dal suo ambito. Il ruolo senza il collegamento non dà nulla: un project_admin che non amministra più alcun repository perde l'accesso a Permissions, Rules, Webhooks, Files e alla gestione degli utenti. Rimuovere l'ultimo repository rimuove quindi tutta l'autorità.

Accesso alle build

Il pannello Build Access decide chi può vedere e scaricare le build pubblicate di questo progetto dalla pagina Games del client. È aperto al super admin e al project_admin sui suoi repository.

1. Aprire il modulo di aggiunta

Nel pannello Build Access, fate clic su Add. Compare una riga di inserimento, che inizia con la scelta di come designare il destinatario.

2. Designare il destinatario

• User: un account dell'elenco, cioè qualcuno che lavora già al progetto.
• Group: un intero gruppo, comodo per una classe di studenti o un team di test ricorrente.
• By username: un campo Exact username dove digitate il nome esatto dell'account. È la via normale per un playtester, dato che non figura in alcun elenco. Il nome deve corrispondere esattamente, senza prefisso.

3. Concedere o revocare

Fate clic su Grant per concedere. Su una riga esistente, Revoke rimuove l'accesso, con una conferma.

La regola applicata dal server, nell'ordine:

In altre parole: chi lavora già al progetto non ha bisogno di nient'altro qui. Questo pannello serve alle persone esterne al progetto, e un viewer resta escluso in ogni caso.

Testare un permesso

Il pannello Test Permission, in fondo alla scheda, risponde a "quale accesso effettivo ha questo utente su questo percorso?". È il modo più breve per sapere quale delle vostre regole decide davvero.

1. Scegliere l'utente e il percorso

Prendete un account in User, poi inserite un percorso in Path, per esempio /Content/Maps/Level01.umap. Il pulsante resta inattivo finché non sono compilati entrambi.

2. Avviare il test e leggere il risultato

Fate clic su Test. Il risultato mostra il livello effettivo, oltre alla fonte e al pattern che hanno deciso, il che permette 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, e agisce solo all'interno di un repository a cui la persona ha già accesso. Per chiudere una cartella a qualcuno che lavora al progetto, apponete una regola none esplicita su di essa.

"Il repository non compare nel suo elenco"

È normale finché non detiene nessuna regola diversa da none su questo repository. Il valore predefinito read non dà accesso al repository stesso. Concedetegli almeno una regola read o write, direttamente o tramite un gruppo, e il repository comparirà. Se si tratta di un playtester che deve solo recuperare le build, non è qui che bisogna agire: vedi Accesso alle build.

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).