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:
- nascondere alcune pagine dalla visualizzazione pubblica
- pubblicare solo alcune pagine al pubblico
- concedere solo a qualcuno o a un gruppo i permessi di scrittura su una o più pagine
- consentire o bloccare la cancellazione delle pagine
- controllare chi può modificare le regole di amministrazione di una pagina
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.
Contenuti
<<TableOfContents: execution failed [list index out of range] (see also the log)>>
Fondamenti
I diritti ACL disponibili sono:
read: chi può leggere la pagina
write: chi può modificare la pagina
delete: chi può modificare la pagina
revert: chi può ripristinare i contenuti della pagina
admin: chi può modificare la riga #acl in una pagina
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
È necessario disporre dei diritti admin per poter aggiungere o modificare una riga ACL, consultare AiutoSuConfigurazione oppure AiutoSuAutoAmministrazione.
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.
Gli allegati non sono protetti quando il server è configurato per il diretto accesso agli allegati (quando l'opzione attachments è usata in wikiconfig.py).
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 \ |
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?
"before" indica la forzatura (questo è dovuto all'algoritmo). Usare quest'opzione per gli amministratori o gli editori dell'intero sistema.
"default" indica cosa viene fatto se non è presente alcuna ACL nella pagina. Equivale alla scrittura della stessa riga ACL all'interno della pagina. Sono i diritti che vengono uniti se viene scritto Default tra gli ACL della pagina.
"after" indica le cose da non dimenticare per sbaglio (come dare accesso in lettura a tutti).
È 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.*'.
Sintassi
Ogni riga può avere questa sintassi:
#acl [+-]Utente[,QualcheGruppo,...]:[permesso[,permesso,...]] [[+-]AltroUtente:...] [[+-]Known:...] [[+-]All:...] [Default]
Dove:
Utente è il nome dell'utente e viene applicata solo se i nomi combaciano.
QualcheGruppo indica una pagina che corrisponde all'espressione regolare page_group_regex (consultare Configurazione) e che contiene delle righe nel formato " * Membro" (consultare Gruppi).
Known è un gruppo speciale che contiene tutti gli utenti registrati.
All è un gruppo speciale che contiene tutti (sia gli utenti registrati che quelli anonimi).
Default è una voce particolare che viene sostituita con le impostazioni prese da acl_rights_default (consultare #Default).
permesso è una parola tipo read, write, delete, admin. Solo le parole elencate in acl_rights_valid verranno accettate, le altre saranno ignorate. È consentito non specificare nessun permesso, a significare che non ne viene concesso alcuno.
Non posizionare spazi bianchi tra il nome è i diritti, "All: write,read" non è una stringa ACL valida.
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.
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.
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.
Elaborazione gerarchica degli ACL
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.
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/.
Esempi di utilizzo
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).
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
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:
- su una pagina nuova, l'autore può impostare qualsiasi permesso desideri
- sulle pagine esistenti, che non hanno ancora regole ACL, qualsiasi utente può impostarne i permessi di accesso
tutti quanti (eccetto WikiAdmin e IlGrandeCapo) possono venire esclusi da chiunque (registrato) sulle pagine che non hanno una loro regola.
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:
- in modo predefinito sia gli utenti riconosciuti che quelli anonimi possano solo leggere le pagine
su una nuova pagina, i membri di GruppoFidati possono specificare qualunque regola
sulle pagine esistenti che non abbiano una propria regola, i membri di GruppoFidati possono inserire qualunque controllo di accesso desiderato
tutti quanti, eccetto i membri del GruppoAdmin possono venire esclusi da una certa pagina, o dagli amministratori o dai collaboratori fidati
le persone nel GruppoFidati possono esercita i loro diritti di amministratore su qualsiasi pagina abbiano il permesso di scrittura, anche se questa specifica proprie regole di accesso
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.
Ulteriori risorse
AiutoSuAutoAmministrazione: consente di concedere i diritti agli utenti a una sottosezione del wiki