Liste di controllo dell'accesso

Le Access Control Lists possono essere usate per concedere a degli specifici utenti o gruppi i diritti per svolgere specifiche azioni. Possono essere usate per:

Per poter usare le ACL è necessario avere accesso alla configurazione del wiki (per impostare le ACL globali) o il diritto di admin in pagine specifiche.

1. Contenuti

2. Fondamenti

I diritti ACL disponibili sono:

Per usare le ACL con MoinMoin è sufficiente includere una particolare riga di controllo all'inizio della pagina, per esempio:

#acl QualcheUtente:read,write All:read

Questo consentirà a QualcheUtente di leggere e scrivere quella pagina, mentre potrà essere solo letta da chiunque altro (a meno che non si configurato in maniera particolare il sito).

Gli allegati sono protetti dalle ACL della pagina in cui sono inseriti quando vengono gestiti dal motore moin del wiki.

3. Configurazione

Questi sono gli elementi per configurare ACL in moin.

Elemento

Valore predefinito

Descrizione

acl_rights_before

u""

Applicato prima della pagina o delle ACL predefinite

acl_rights_after

u""

Applicato dopo la pagina o le ACL predefinite

acl_rights_default

u"Trusted:read,write,delete,revert \
Known:read,write,delete,revert \
All:read,write"

Usato solo quando nessun altra ACL è fornita sulla pagina a cui si accede

acl_rights_valid

["read",  "write",  "delete",  "revert",  "admin"]

Questi sono i diritti accettabili (conosciuti) e dove poterli estendere

acl_hierarchic

False

Abilita l'elaborazione gerarchica delle ACL, consultare le gerarchie

Cosa significa tutto questo?

È molto utile pensare a questi diritti come se venissero elaborati prima, durante e dopo l'elaborazione degli ACL della pagina.

(!) La notazione u"" usata nelle stringhe di controllo è per l'uso di Unicode e deve essere presente, Consultare AiutoSuConfigurazione.

/!\ Se non vengono usati nome CamelCase per le definizioni, come GruppoPROGETTO, è necessario modificare la page_group_regex a u'^Gruppo.*'.

4. Sintassi

Ogni riga può avere questa sintassi:

#acl [+-]Utente[,QualcheGruppo,...]:[permesso[,permesso,...]] [[+-]AltroUtente:...] [[+-]Known:...] [[+-]All:...] [Default]

Dove:

5. Permessi disponibili

Questi sono i permessi disponibili che è possibile utilizzare nelle regole ACL:

read
Gli utenti specificati possono leggere il testo della pagina.
write
Gli utenti specificati potranno modificare il contenuto della pagina.
delete
Gli utenti specificati potranno cancellare la pagina e gli allegati.
admin
Gli utenti specificati sono gli amministratori della pagina. Questo significa che potranno cambiare le impostazioni ACL, compreso dare o togliere lo stato di amministratore agli altri utenti.

/!\ Non esiste un diritto di rinomina (rename) separato, la rinomina di una pagina richiede che un utente abbia i permessi per leggere, scrivere e cancellare una pagina.

6. Logica di funzionamento

Quando qualcuno accede a una risorsa protetta dalle ACL, le elaborazione vengono eseguite nell'ordine in cui sono specificati. La prima regola ACL che viene soddisfatta indica se l'utente ha o meno il permesso di accedervi.

(!) A causa dell'algoritmo della prima regola, è necessario mantenere un certo ordine nello specificare le ACL: prima i singoli utenti, poi i gruppi speciali, quindi i gruppo generici, Known e infine All.

Per esempio, la seguente ACL specifica che QualcheUtente può leggere e scrivere la pagina coperta da quelle regole, mentre i membri di QualcheGruppo (compreso QualcheUtente, se vi fa parte) può amministrarne i permessi; tutti gli altri possono leggerla.

#acl QualcheUtente:read,write QualcheGruppo:read,write,admin All:read

Per rendere il sistema più flessibile, è possibile utilizzare dei modificatori: i prefissi '+' e '-'. Quando vengono usati, quella particolare regola verrà soddisfatta solo quando l'utente richiede quei particolari permessi. Per esempio, la ACL precedente può essere riscritta così:

#acl -QualcheUtente:admin QualcheGruppo:read,write,admin All:read

Questo esempio è valido solo per QualcheUtente, dato che quando vengono chiesti i diritti admin per QualcheUtente, verranno negati e l'elaborazione si ferma. In tutti gli altri casi l'elaborazione continua.

O anche:

#acl +All:read -QualcheUtente:admin QualcheGruppo:read,write,admin

+All:read indica che quando qualsiasi utente richiede il diritto di lettura (read), verrà concesso e l'elaborazione si ferma. In tutti gli altri casi, l'elaborazione continuerà. Se vengono chiesti i diritti admin per QualcheUtente, verranno negati e l'elaborazione si ferma. In tutti gli altri casi l'elaborazione continua. Infine, se un membro di QualcheGruppo richiede alcuni diritti, verranno garantiti se sono specificati, altrimenti no. Tutti gli altri utenti non hanno altri diritti, a meno che forniti dalla configurazione.

La seconda e la terza forma vengono raramente usate per specificare i permessi di una pagina wiki, ma possono essere utili nella configurazione globale del sito.

7. Utilizzo dei permessi predefiniti

Qualche volta può essere utile dare a qualcuno un certo permesso senza per questo ignorare le impostazioni globali del sito. Per esempio, supponiamo di avere le seguenti regole nella configurazione:

acl_rights_default = "GruppoFidato:read,write,delete All:read"
acl_rights_before  = "GruppoAdmin:admin,read,write,delete +GruppoFidato:admin"

Ora diciamo di voler dare a QualcheUtente il permesso di scrittura, ma di voler anche mantenere il comportamento specificato per All e per GruppoFidato. Questo è facilmente ottenibile usando la speciale regola Default:

#acl QualcheUtente:read,write Default

Questo inserirà le regole impostate in acl_rights_default esattamente dove appare la parola Default. In altri termini, la regola qui sopra con la configurazione indicata è equivalente a questa regola:

#acl QualcheUtente:read,write GruppoFidato:read,write,delete All:read

Sebbene raggiungano lo stesso risultato, sfruttando i valori di default si ha il vantaggio che eventuali modifiche a quelle impostazioni verranno applicate automaticamente.

Considerando il primo esempio di questa pagina:

acl_rights_before  = u"GruppoAdmin:admin,read,write,delete,revert +GruppoFidato:admin"

Le ACL vengono elaborate nell'ordine di "before" quindi "page/default" e infine "after", da sinistra a destra.

Inizia quindi alla "sinistra" di "before" con AdminGroup:... che corrisponde se si è membri del GruppoAdmin. In tal caso si ottengono quei diritti e l'elaborazione ACL si ferma.

Se non corrisponde, l'elaborazione continua con +GruppoFidato:... e se si fa parte di questo gruppo allora si ottengono tali diritti. L'elaborazione però continua, in modo che se è presente un altro gruppo, o il proprio utente oppure Known o All, si ottengono anche quei diritti.

Se non corrisponde ancora, l'elaborazione continua con le ACL della pagina (se presenti) o con le ACL predefinite (default) e infine con quelle "after".

Benché non cambi molto, ereditare dalle impostazioni predefinite ha il vantaggio di seguire automaticamente tutti gli aggiornamenti introdotti in questa categoria.

8. Elaborazione gerarchica degli ACL

{i} Nuova caratteristica della versione 1.6

Se è stato abilitato acl_hierachic (consultare più sopra), le pagine vengono trattate come una gerarchia e i permessi impostati al livello più alto possono influenzare i permessi degli utenti.

In poche parole, se un permesso non è trattato dalla pagina attuale, viene controllato l'ACL della pagina superiore e così via finché non ci sono più pagine superiori.

Tutte le normali regole ACL sono valide, ma invece che controllare gli ACL sono della pagina attuale, l'ACL della pagina viene aggiunto con tutti gli ACL delle pagine nella gerarchia, fino alla pagina "radice" (dopo la quale non ce ne sono più). Considerare il seguente esempio per le pagina chiamate "A/B/C/D" per vedere come avviene l'elaborazione con e senza questa caratteristica abilitata:

acl_hierarchic

Sequenza di elaborazione

false

acl_rights_before, A/B/C/D, [acl_rights_default], acl_rights_after

true

acl_rights_before, A/B/C/D, A/B/C, A/B, A, [acl_rights_default], acl_rights_after

Nota che acl_rights_before, acl_rights_default e acl_rights_after non sono applicati una sola volta per pagina nella gerarchia, ma una sola volta in tutto durante l'elaborazione della pagina "A/B/C/D". I diritti predefiniti funzionano come prima, ma invece che essere inclusi quando la pagina attuali non contiene ACL, viene usata solo se nessuna delle pagine nella gerarchia contiene alcun ACL. Praticamente, la gerarchia di ACL non fa altro che sostituire gli ACL della pagina attuale con una concatenazione di tutte le righe ACL trovate nella gerarchia delle pagine.

9. Gruppi

Raggruppare gli utenti rende più facile gestire i permessi quando il numero di utenti è elevato. La pagina, per la lingua inglese, deve terminare con la parola Group, ma è possibile modificare questo comportamento, per maggiori informazioni consultare AiutoSuConfigurazione.

Solo gli amici di QualcheUtente possono leggere e modificare la pagina:

#acl QualcheUtente:read,write QualcheUtente/GruppoAmici:read,write

QualcheUtente/GruppoAmici a sua volta è una pagina della quale ogni elemento della lista al primo livello rappresenta il nome di un utente del sito wiki da considerare appartenente a quel gruppo:

#acl QualcheUtente:read,write,admin,delete
 * PaoloVerdi
 * MarioBianchi
 * RodolfoRossi

La pagina GruppoAdmin può definire un gruppo con quel nome e a sua volta può essere protetta con le regole ACL:

#acl GruppoAdmin:admin,read,write All:read
 * QualcheUtente
 * AltroUtente
   * Questa voce viene ignorata
Qualsiasi testo esterno all'elenco di primo livello viene ignorato.

/!\ Un elenco di primo livello è un elenco con un solo spazio prime dell'asterisco (e deve esserci anche un solo spazio dopo l'asterisco). L'esempio che segue non funziona:

  * some user
-- two spaces like so and it doesn't work

È possibile configurare quali nomi di pagina debbano essere considerati delle definizioni di gruppo (per esempio per wiki in lingue diverse dall'inglese):

page_group_regex =  '^Gruppo.*'    # questo è adatto all'italiano

/!\ Se le modifiche a una pagina di un gruppo non ha alcun effetto, è necessario far ricreare la chace a MoinMoin semplicemente rimuovendo tutti i file nella directory percorso_del_wiki/data/cache/wikidicts/.

10. Esempi di utilizzo

10.1. Un wiki pubblico su Internet

Il concetto fondamentale in questo caso è utilizzare le ACL solo quando sia realmente necessario. Generalmente i wiki si basano sulla libera accessibilità e modificabilità dei contenuti. I vincoli di sicurezza sono perciò minimi, limitati alla rimozione di materiale improprio. Per questi motivi non è spesso necessario utilizzare le ACL: utilizzandole a sproposito si rischia di compromettere la filosofia stessa di un wiki.

Questo è il motivo per cui le ACL non dovrebbero essere utilizzare (in modo predefinito è così). Qualora si decida di farlo, il file wikiconfig.py dovrebbe contenere qualche cosa del tipo:

acl_rights_before = 'NomeResponsabileWiki:read,write,admin,delete +GruppoAdmin:admin ImbrattatatoreSiti:' 

L'impostazione predefinita per acl_rights_default dovrebbe essere adatta:

acl_default = 'Known:read,write,delete All:read,write' 

Un buon consiglio è di avere solo pochi e ben fidati amministratori del wiki raggruppati in GruppoAdmin (che devono avere una buona conoscenza di come funziona un wiki perché altrimenti potrebbero, senza volerlo, comprometterne il senso stesso, che sta nell'essere aperto, non chiuso a chiave!).

Se si utilizza il GruppoAdmin è necessario creare una pagina GruppoAdmin elencandovi le persone che avranno i permessi di amministrazione. Specificando l'ImbrattatatoreSiti come mostrato sopra in pratica lo si chiude fuori: non potrà né leggere né tanto meno scrivere nulla da quell'account. Questo ha senso solo quando si tratta di una misura temporanea, altrimenti tanto varrebbe eliminare il suo account. Naturalmente questo ImbrattatatoreSiti può accedere anche come anonimo, rendendola una protezione non molto efficace (sicurezza leggera).

10.2. Il wiki come un semplice CMS

Se vuoi utilizzare il wiki come una maniera semplice per pubblicare contenuti sul web ma non desideri che sia pubblicamente modificabile (cioè vuoi permettere solo a alcuni webmaster di farlo), puoi inserire queste impostazioni nel tuo wikiconfig.py:

acl_rights_default = 'All:read' 
acl_rights_before  = 'WebMaster,AltroWebMaster:read,write,admin,delete' 

In questo modo tutti potranno leggere, ma solo i due autori indicati potranno fare tutto. Mentre stanno lavorando a una pagina, potranno inserirvi

#acl All: 

cosicché nessun altro potrà vedere la pagina incompleta. Una volta terminato il lavoro, dovranno ricordarsi di rimuovere la regola ACL in modo che vengano applicate quelle indicate da acl_rights_default.

Per far sì che alcune pagine consentano ai visitatori anonimi di inserire un loro commento (ad esempio la pagina CommentiDeiVisitatori), inserisci questa regola:

#acl All:read,write 

10.3. Wiki in una Intranet

Se si vuole utilizzare un wiki in una intranet e, fidandosi della buona fede dei propri collaboratori (nel senso che non compiano atti di sabotaggio tipo escludere qualcuno o rubare la proprietà delle pagine), è possibile dare loro il ruolo di amministratori:

acl_rights_default = 'Known:admin,read,write,delete All:read,write'
acl_rights_before  = 'WikiAdmin,IlGrangeCapo:read,write,admin,delete' 

In questo modo tutti possono leggere, modificare e cambiare i diritti di accesso, WikiAdmin e IlGrandeCapo hanno assicurato il permesso di fare qualunque cosa; gli utenti registrati ottengono questo diritto da acl_rights_default (così facendo ottengono questo beneficio solo nel caso in cui la pagina non specifichi sue particolari ACL).

Conseguenze:

10.4. Il wiki come sito pubblico aziendale

Se si vuole utilizzare il wiki come sito aziendale e non si vuole che chiunque sia in grado di modificarne i contenuti, usare una configurazione di questo tipo:

acl_rights_default = "GruppoFidati:admin,read,write,delete All:read"
acl_rights_before  = "GruppoAdmin:admin,read,write,delete +GruppoFidati:admin"

Questo significa che:

10.5. Commenti su pagine a sola lettura

È possibile facilmente ottenere una sezione commentabile in una pagina a sola lettura usando una sotto-pagina scrivibile. Per esempio, è possibile definire QualchePagina in questo modo:

#acl QualcheUtente:read,write All:read
'''Contenuto a sola lettura'''

...

''' Commenti dei visitatori '''
<<Include(QualchePagina/Commenti)>>

E in QualchePagina/Commenti mettere qualche cosa come:

#acl All:read,write
Aggiungi qui sotto le tue considerazioni su QualchePagina.

11. Ulteriori risorse