LA GESTIONE UTENTI DEL CMS TYPO3

Come la maggior parte dei CMS, anche TYPO3 si divide in due parti distinte: il FE (Front-End), ovvero l'area pubblica dove vengono presentati i contenuti, e il BE (Back-End), l'area riservata all'amministrazione del sito.

Come si può vedere in Figura 1, l'area di BE si presenta suddivisa in tre zone distinte. La prima colonna, denominata Module Bar, presenta tutti i moduli a disposizione dell'amministratore e rappresenta un menu di primo livello per accedere alle diverse funzionalità presenti. La seconda colonna, denominata Navigation Area, presenta un menu interno relativo al modulo selezionato nella Module Bar e pertanto varia in base ai contenuti da presentare: nel caso per esempio ci si trovi nel modulo “Web” mostrerà l'albero delle pagine di cui si compone il sito, nel caso si selezioni il modulo “File”, invece, mostrerà l'albero delle sotto-directory della directory “fileadmin” (una zona in cui i redattori del sito possono caricare sul server i propri file). La terza colonna, denominata Detail View, rappresenta l'area di lavoro, ovvero la zona in cui si andrà ad operare in base al modulo selezionato.

Una trattazione completa di tutti i moduli disponibili richiederebbe troppo spazio, oltre ad essere piuttosto semplice (per chi è interessato consiglio [1] e [2]). Pertanto passeremo subito alla gestione degli utenti di BE, studio che comunque ci permetterà di introdurre alcuni dei moduli presenti.

Il primo passo, come detto, è la creazione del gruppo di BE, gruppo dal quale l'utente erediterà i relativi permessi. Iniziamo creando il gruppo “programmosubito”. Per far questo è necessario selezionare il modulo Web-->List e, nella Navigation Area, selezionare la root dell'albero delle pagine. A questo punto è sufficiente cliccare sulla voce “create new record” in fondo alla terza colonna e selezionare “Backend usergroup”. Il risultato è l'apertura di una form per la personalizzazione del nuovo gruppo. Dopo aver specificato il nome del gruppo (“programmosubito”, appunto) è possibile sfruttare l'opzione “Lock to domain” per limitare l'accesso agli utenti che provengono da un determinato dominio (per es. www.lorenzutti.net) in quanto TYPO3 consente di gestire con la stessa installazione un gran numero di siti e domini.

Selezioniamo ora la voce “Include Access List”. Otteniamo l'apertura di una form molto più estesa che ci consentirà di definire nel dettaglio i permessi di questo gruppo (per approfondimenti: [3]). La prima selezione (Figura 2) ci permette di scegliere a quali moduli avrà accesso questo gruppo. Nel nostro esempio abbiamo bisogno del modulo Web e di alcuni suoi sottomoduli, per la gestione delle pagine e dei contenuti del sito, del modulo File e del suo unico sottomodulo, per il caricamento di file sul server, e del modulo User col suo sottomodulo Setup, per permettere agli utenti di questo gruppo di modificare le proprie impostazioni personali (come ad es. la password di accesso al BE).

Nella seconda selezione, denominata “Tables (listing)”, possiamo selezionare la tipologia di contenuti che questo gruppo dovrà essere in grado di vedere. Sulla base della selezione presentata in Figura 3, notiamo come questo gruppo abbia il diritto di visualizzare le pagine e i contenuti di pagina ma non, ad esempio, i record di tipo “Website user”, ovvero gli utenti di FE. La selezione successiva, denominata “Tables (modify)”, permette di decidere quali tipologie di record potranno essere modificate dal gruppo in questione. Ovviamente queste saranno un sottoinsieme di quelle specificate in precedenza.

Poiché questo gruppo avrà la capacità di creare nuove pagine nel sito, è necessario specificare quali tipologie di pagine potrà creare ed è possibile farlo grazie all'apposita selezione che segue la precedente (anche in questo caso per una trattazione dei tipi di pagina disponibili rimando a [2]).

A questo punto siamo arrivati alla selezione più complessa e dettagliata a disposizione: la selezione dei singoli campi modificabili dal gruppo (Figura 4). In TYPO3 è possibile, infatti, specificare per ogni singolo tipo di contenuto i campi che possono essere modificati (denominati exclude-fields). Prendendo ad esempio le pagine, è possibile impedire all'utente di modificare il campo “TSConfig”, ovvero quel campo che permette una ulteriore personalizzazione della pagina e delle sottopagine sfruttando TypoScript (il linguaggio di configurazione di TYPO3). In questo modo quando un utente appartenente a questo gruppo aprirà in modifica una pagina o ne creerà una nuova, non avrà accesso a questo campo e quindi non potrà apportare modifiche che potrebbero causare problemi di gestione o, peggio, di sicurezza. Nella selezione di Figura 4 possiamo notare quali campi siano stati selezionati per questo gruppo relativamente ai contenuti di tipo pagina. Lo stesso livello di granularità è previsto anche per i contenuti di pagina e, in generale, per tutti i tipi di record, anche a quelli derivanti da estensioni sviluppate da terze parti (a patto però che tali estensioni siano state realizzate prevedendo questa possibilità). Un ultimo appunto: come vi sarete accorti alcuni campi non sono presenti in questa lista e quindi non possono essere vietati. Un esempio è il campo “Title” per le pagine. Questo campo, e molti altri, non sono presenti in quanto o sono campi obbligatori (pertanto non valorizzandoli il record non avrebbe senso) oppure sono campi “importanti”, campi cioè che pur non essendo obbligatori devono essere valorizzati per dare un significato concreto al record in questione.

A questo punto è possibile specificare quali tipi di contenuto di pagina vogliamo negare a questo gruppo. A differenza della selezione precedente in cui dovevamo esplicitamente selezionare i campi consentiti al gruppo, in questo caso vige il tacito assenso: se non neghiamo un tipo di contenuto questo è consentito. In Figura 5 possiamo vedere come in questo caso siano stati negati i contenuti di tipo “Form”, “Login” e “Script”, per evitare che utenti non autorizzati possano creare delle form di invio mail, delle aree riservate indipendenti o inserire degli script all'interno della pagina.

L'ultimo passo di questa selezione così dettagliata è costituita dalla lingua. In TYPO3 è infatti possibile realizzare dei portali multilingua ed è pertanto interessante la possibilità di limitare un gruppo ad operare sui contenuti di una determinata lingua (si pensi al vantaggio di creare un gruppo di traduttori senza doversi preoccupare che questi possano, magari inavvertitamente, alterare i contenuti della lingua originale). In questo caso semplice non abbiamo limitazioni di questo tipo.

A questo punto siamo giunti ad una selezione molto importante: il “DB Mount”. In questo campo possiamo specificare quali pagine del sito possono essere modificate da questo gruppo. In questo caso possiamo limitare questo gruppo alla sezione “Programmo subito”. È comunque possibile specificare molte più pagine del sito, indipendenti fra loro.

Segue la possibilità di associare un “File Mount”, ovvero una sotto-directory di fileadmin dove questo gruppo potrà caricare i propri file (in realtà il passaggio è un po' più complesso, trovate una spiegazione dettagliata in [3]). I campi seguenti ci permettono di personalizzare le opzioni relative ai workspaces (un concetto introdotto nella versione 4.0 per permettere un versioning evoluto dei contenuti), di selezionare un gruppo come base per il gruppo ora creato e di personalizzare ulteriormente il gruppo creato mediante TypoScript nel campo TSConfig.

Finalmente siamo giunti alla conclusione del gruppo “programmosubito”. E il gruppo “redattorecapo”? Gli utenti appartenenti a questo gruppo dovrebbero poter eseguire le stesse operazioni del gruppo precedente, con la differenza però che le possono svolgere su tutto l'albero “Gli articoli”. Ma allora la creazione di questo gruppo risulta veramente semplice: è sufficiente creare un nuovo gruppo di BE, dargli il nome corretto, impostare il nuovo “DB Mount” (selezionando “Gli articoli” dall'albero delle pagine) e, punto fondamentale, selezionare “programmosubito” come sottogruppo. In questo modo si ereditano tutte le impostazioni precedentemente definite, senza la necessità di personalizzare nuovamente questo gruppo (anche se i vantaggi non si limitano a questo, come vedremo nel proseguo dell'articolo).

Dopo aver definito correttamente i gruppi di BE, è possibile creare gli utenti ed associarli a tali gruppi. I primi passaggi sono simili a quelli sopra descritti, con la differenza che si deve creare un nuovo “Backend user” anziché un “Backend usergroup”. A questo punto vanno specificati il nome utente, la password e il gruppo di BE corrispondente. Esistono anche in questo caso numerosi parametri per personalizzare il singolo utente. È infatti possibile sovrascrivere alcune delle impostazioni date al gruppo al fine di specializzare ulteriormente determinati utenti all'interno dello stesso gruppo. Particolarmente interessanti sono i permessi relativi alle operazioni sui file che permettono di definire se un utente ha la possibilità di caricare, rinominare, spostare, ecc. file e directory. Va prestata molta attenzione a selezionare le voci relative alla sezione “Mount from groups” per ereditare i parametri di “DB Mount” e di “File Mount” dal gruppo, anziché sovrascriverli specificandoli per questo utente. Infine vi segnalo la possibilità di selezionare il flag “Admin” per creare degli utenti di tipo amministratori, vanificando così tutti i permessi precedentemente definiti.

A questo punto abbiamo creato anche gli utenti, non rimane che testarli. Se facciamo il login con uno dei due utenti, però, ci accorgiamo che non possiamo vedere nessuna pagina, tantomeno i contenuti di pagina. Questo è dovuto al fatto che abbiamo trascurato il punto 3 della scaletta descritta inizialmente: dobbiamo assegnare i permessi alle pagine. Se passiamo al modulo Web-->Access in modalità “Permissions” ci accorgiamo come ad ogni pagina sia possibile associare dei permessi relativi all'utente possessore, al gruppo possessore e a tutti gli altri, similmente a quanto avviene con i sistemi Unix-like. L'utente possessore della pagina è già selezionato ed è l'utente creatore della stessa. Tale utente ha tutti i permessi sulla pagina (visualizzazione, taglia, copia, modifica, cancellazione, creazione di nuove) e sui contenuti di pagina (creazione, modifica, taglia, copia). Come ormai sarà evidente, dobbiamo specificare un gruppo proprietario delle pagine interessate e i relativi permessi. Interessante è la possibilità di negare la capacità di cancellazione delle pagine a livello di gruppo per evitare che un utente possa cancellare le pagine create da un altro utente, anche se facenti capo entrambi allo stesso gruppo. I giusti permessi da settare per il nostro esempio sono riportati in Figura 6.

Come si può vedere in Figura 6, la pagina “Programmo Subito” è associata al gruppo “programmosubito”. In base al nostro esempio, però, abbiamo la necessità che anche gli utenti appartenenti al gruppo “redattorecapo” possano modificare tale pagina. Questa possibilità è implicita in quanto il gruppo “programmosubito” è un sottogruppo di “redattorecapo” e, come tale, propaga tutti i propri permessi a quest'ultimo. Se ora proviamo a fare il login con l'utente appartenente al gruppo “programmosubito” possiamo vedere come si presenta il BE.

Se effettuiamo il login con l'utente appartenente al gruppo “redattorecapo” ci accorgiamo di un problema: la pagina “Programmo Subito” viene presentata due volte. Questo problema deriva dal fatto che il gruppo “redattorecapo” eredita, oltre che tutti i permessi, anche il DB Mount dal suo sottogruppo. La soluzione a problemi di questo tipo è di ri-progettare la struttura dei gruppi di BE: è necessario creare un nuovo gruppo contenente tutti i permessi del gruppo “programmosubito” ma senza specificare alcun DB Mount e quindi impostarlo come sottogruppo di entrambi i gruppi creati. In questo modo i due gruppi condividono gli stessi permessi ma non lo stesso DB Mount. Attenzione però ai permessi delle pagine: è necessario cambiare il gruppo della pagina “Programmo Subito” e impostarlo al nuovo gruppo base creato, altrimenti gli utenti del gruppo “redattorecapo” non avranno più accesso alla pagina.

Per agevolarci durante la fase di verifica degli utenti creati ci viene in aiuto il modulo “Tools-->User Admin”, che ci permette di confrontare tutti gli utenti di BE del nostro sito e raggrupparli in base a numerose opzioni disponibili. Inoltre, è possibile effettuare lo switch-user per passare ad uno degli utenti presenti. Questa possibilità, disponibile solamente per gli utenti amministratori (come peraltro tutto il modulo “Tools”), risulta molto importante nel caso in cui gli utenti di BE abbiano la possibilità di cambiare la propria password. In questi casi, infatti, non è possibile venire a conoscenza della nuova password, nemmeno cercando nel DB in quanto viene codificata sfruttando l'algoritmo md5, ed è quindi l'unico modo per testare l'utente in caso di problemi.

Un ultimo particolare: se ora un utente amministratore crea una nuova sotto-pagina di “Gli Articoli”, questa in automatico avrà come proprietario l'utente amministratore e senza alcun gruppo di BE. Pertanto, ogni volta si presenti un caso come questo, l'amministratore dovrebbe ricordarsi di correggere i permessi della pagina attraverso il modulo “Web-->Access” visto in precedenza. Non è difficile immaginare come la maggior parte dei casi l'amministratore non si ricordi di apportare questa modifica. Per risolvere anche quest'ultimo particolare è possibile impostare dei permessi predefiniti alle nuove pagine. Ogni nuova sotto-pagina di “Gli Articoli” dovrà quindi avere un gruppo di riferimento (“redattorecapo”) e i giusti permessi per tale gruppo. Questa configurazione richiede l'inserimento del seguente codice nel campo TSConfig della pagine “Gli Articoli”:

TCEMAIN.permissions {

groupid = 2

user = show,edit,delete,new,editcontent

group = show,edit,new,editcontent

everybody =

}

Dove groupid=2 specifica il gruppo da associare alla nuova pagina (mediante l'id del gruppo) e le altre voci definiscono i permessi per l'utente, il gruppo e tutti gli altri.

Per quanto riguarda le nuove sotto-pagine di “Programmo Subito” è possibile specificare un gruppo di appartenenza diverso semplicemente riportando un codice simile al precedente nel campo TSConfig della pagina “Programmo Subito”, con l'opportuna modifica del gruppo da associare. In questo modo si vanno a sovrascrivere le impostazioni ereditate dalla pagina “Gli Articoli”.