~funderscoreblog cgit wikiget in touch

Liste di controllo dell'accesso

Le Access Control Lists (ACL) possono essere usate per controllare i permessi di un utente o di un gruppo di utenti (che possono essere specificati, consultare AiutoSuGruppi). Si possono definire i permessi per l'intero wiki, o per pagine specifiche del wiki.

Utilizzando le ACL, è possibile configurare facilmente il wiki in modo che gli utenti anonimi possano solamente leggere, ma non modificare le pagine. Si possono creare delle pagine che gli utenti generici non possano leggere fino a che non si sia pronti per la pubblicazione. Si possono impostare i permessi in modo che solo determinati utenti siano in grado di effettuare modifiche.

Per poter usare le ACL è necessario avere accesso a wikiconfig.py (per impostare le ACL globali) oppure avere il diritto di admin sulle pagine specifiche ove si voglia impostare (o cambiare) le ACL.

Comprendere gruppi e permessi

Permessi basilari

I diritti disponibili che possono essere utilizzati in una ACL sono:

Non c'è alcun diritto separato di rinomina (rename). Rinominare una pagina richiede che un dato utente abbia i diritti di read, write e delete.

Gli utenti anonimi (cioè quelli che non hanno effettuato l'accesso) non possono cancellare o rinominare le pagine (anche se esplicitamente concesso al gruppo All).

Gli allegati sono protetti dalle ACL della pagina a cui sono collegati.

È necessario disporre preventivamente dei diritti di admin per poter aggiungere o modificare una riga ACL di una pagina. Nel caso degli amministratori del wiki, è importante assicurarsi di garantirsi i diritti di admin per l'intero wiki (consultare configurazione globale più avanti).

I permessi disponibili possono essere limitati con il parametro acl_rights_valid nel proprio file wikiconfig.py. Per esempio, si possono concedere tutti i diritti tranne delete per impedire che una pagina possa mai essere cancellata. (consultare configurazione globale più avanti).

Gruppi principali

Sintassi & utilizzo

Per usare le ACL con moin è sufficiente includere una riga di controllo nella pagina che si vuole controllare. Il comando ACL dovrebbe essere la linea in cima alla pagina wiki, e la sintassi è la seguente:

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

Dove Utente,QualcheGruppo e permesso (i permessi come lettura, scrittura, cancellazione, ripristino, admin) sono definiti nel paragrafo precedente.

Default è una voce particolare che viene sostituita in una data posizione con le impostazioni prese da acl_rights_default. Questo è spiegato con maggiori dettagli nella sezione #Default più avanti.

Non posizionare spazi bianchi tra il nome e i diritti. Per esempio, "All: write,read" non è una stringa ACL valida.

Un semplice esempio può essere:

#acl MarioRossi:read,write,delete,revert,admin GruppoEditori:read,write,revert All:read

In questo esempio, MarioRossi potrà leggere e scrivere, così come effettuare ogni altra azione su quella pagina, mentre tutti i membri del GruppoEditori saranno capaci di leggere, modificare e ripristinare la pagina. Tutti gli altri utenti potranno solo leggerla. Fare attenzione che i parametri di configurazione nel proprio wikiconfig.py potrebbero sovrascrivere alcune ACL specifiche di una data pagina. Consultare anche "Esempi di utilizzo" più avanti.

Configurazione globale

Questi parametri di configurazione sono utilizzati per impostare le ACL di un intero sito wiki, e sono inseriti nel file wikiconfig.py (consultare anche HelpOnConfiguration).

(!) I valori predefiniti che sono troppo lunghi nella tabella qui sotto sono visualizzati come "...". Spostate il puntatore del mouse sui puntini per visualizzare i valori predefiniti in un suggerimento.

Variable name Default Description
acl_hierarchic False True to use hierarchical ACLs
acl_rights_after u'' ACL that is processed after the on-page/default ACL
acl_rights_before u'' ACL that is processed before the on-page/default ACL
acl_rights_default ... ACL used if no ACL is specified on the page
acl_rights_valid ... Valid tokens for right sides of ACL entries.

Cosa significa tutto questo?

È 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 indica l'utilizzo di Unicode e deve essere presente.

Applicazione delle ACL

Questa sezione si applica a singole pagine wiki che contengono ACL ma si possono anche applicare all'intero wiki se l'ACL è inclusa nella configurazione globale del wiki (consultare HelpOnConfiguration).

Ordine di applicazione dei valori ACL

Quando qualcuno accede a una risorsa protetta dalle ACL, i valori ACL vengono eseguiti nell'ordine in cui sono specificati. Il primo valore ACL che viene soddisfatto dall'utente indica se l'utente ha o meno il permesso di accedervi e l'applicazione delle regole viene fermata. A causa dell'algoritmo della prima regola, è necessario mantenere il seguente 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 ogni altro utente che sia membro di QualcheGruppo può amministrarne i permessi; tutti gli altri possono leggerla.

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

Modificatori dei prefissi ACL

Per rendere il sistema più flessibile, è possibile utilizzare dei modificatori: i prefissi '+' e '-'. Quando vengono usati, l'elaborazione delle regole verrà fermata solo quando il permesso richiesto per un particolare utente corrrisponde all'utente e ai permessi nei valori ACL, ma continuerà se si stanno controllando per un alro permesso (o un altro utente). Quando il modificatore '+' sarà utilizzato il permesso verrà concesso, quando il modificatore '-' sarà utilizzato il permesso verrà negato (nel caso bloccante).

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

Questo esempio è particolare solo per QualcheUtente, dato che quando verranno chiesti i diritti admin per QualcheUtente, verranno negati e l'elaborazione si fermerà. In tutti gli altri casi (differente utente o differente richiesta di permessi) l'elaborazione continuerà.

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

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

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

Ereditarietà 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,revert All:read"
acl_rights_before  = "GruppoAdmin:admin,read,write,delete,revert +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 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,revert All:read

Considerando il primo esempio di questa sezione:

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 GruppoAdmin:... che corrisponde se si è membri del GruppoAdmin. In tal caso si ottengono quei diritti (arwdr) e l'elaborazione ACL si ferma.

Se non corrisponde, l'elaborazione continua con ` +GruppoFidato:admin` - questo corrisponde se si è membri di GruppoFidato.

Se corrisponde, si ottengono quei diritti (a) e - qui c'è la differenza dovuta al modificatore - l'elaborazione delle ACL PROSEGUE!, in modo che se è presente un altro gruppo, o il proprio utente oppure Known o All, si ottengono anche quei diritti. Se quindi c'è un'altra corrispondenza per quel gruppo o il proprio utente o Known: o All: si otterranno anche quei diritti.

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

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

Elaborazione gerarchica degli ACL

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.

Se la pagina corrente non contiene un comando #acl, allora viene utilizzato l'ACL della pagina superiore e così via finché non ci sono più pagine superiori.

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

Processing Sequence

False

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

True

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

Per quanto concerne i diritti predefiniti, questi funzionano come prima, ma invece che essere inclusi quando la pagina attuale non contiene ACL, vengono usati solo se nessuna delle pagine nella gerarchia contiene alcun ACL.

{i} Nota-- il comportamento ACL_hierarchic nelle versioni precedenti a moinmoin 1.8.4 è differente: le ACL della pagina superiore non sono ulteriormente aggiunte alle ACL della sotto-pagina. Tutte le ACL di una sotto-pagina devono essere elencate esplicitamente in tal caso.

Esempi di utilizzo

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 è generalmente necessario utilizzare le ACL: utilizzandole a sproposito si rischia di compromettere la filosofia stessa di funzionamento 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 = u'NomeResponsabileWiki:read,write,admin,delete,revert +GruppoAdmin:admin ImbrattatatoreSiti:' 

L'impostazione predefinita per acl_rights_default dovrebbe essere adatta:

acl_default = u'Known:read,write,delete,revert 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 con 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).

Il wiki come un semplice CMS

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

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

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), è possibile inserire questa regola:

#acl All:read,write 

Wiki in una Intranet

Se si vuole utilizzare un wiki in una intranet e, fidandosi della buona fede degli utenti (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 = u'Known:admin,read,write,delete,revert All:read,write'
acl_rights_before  = u'WikiAdmin,IlGrangeCapo:read,write,admin,delete,revert' 

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:

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 = u"GruppoFidati:admin,read,write,delete,revert All:read"
acl_rights_before  = u"GruppoAdmin:admin,read,write,delete,revert +GruppoFidati:admin"

Questo significa che:

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