Moodle: l'API per il controllo degli accessi

Moodle utilizza un modello di controllo degli accessi basato sui ruoli. La maggior parte delle entità in Moodle (utenti, categorie, corsi, moduli e blocchi) sono rappresentate da contesti organizzati in una struttura ad albero.

I ruoli

Il ruolo è un insieme di definizioni di permessi, ciascun permesso definisce la possibilità dell'utente di fare qualcosa.

I ruoli sono definiti al livello più alto di sistema. Il controllo dell'accesso utente viene assegnato in base alle definizioni dei ruoli assegnati agli utenti.

All'utente che non ha ancora effettuato nessun accesso, ovvero non è loggato, viene automaticamente assegnato il ruolo "notloggedinroleid", fintantoché l'utente non si autentica può appartenere solo a questo ruolo.

Quest'ultimo è diverso dall'utente guest, ovvero l'utente che accede alla piattaforma con le credenziali di guest dove l'accesso guest è appunto abilitato. In questi casi il ruolo assegnato è "guestroleid".

Nella lezione precedente abbiamo visto che i permessi di un plugin vengono assegnati nell'array $capabilities contenuto nel file db/access.php:

$capabilities = array(
   'block/myblock:addinstance' => array(
       'riskbitmask' => RISK_SPAM | RISK_XSS,
       'captype' => 'write',
       'contextlevel' => CONTEXT_BLOCK,
       'archetypes' => array(
           'editingteacher' => CAP_ALLOW,
           'manager' => CAP_ALLOW
       ),
       'clonepermissionsfrom' => 'moodle/site:manageblocks'
   ),
);

Rischi e valori dei ruoli

Cosa significano le chiavi di questo array? Andiamo con ordine: riskbitmask, sono i "rischi" associati ai ruoli:

• RISK_SPAM: l'utente può aggiungere contenuto visibile al sito, inviare messaggi ad altri utenti;
• RISK_PERSONAL: accesso a informazioni personali private;
• RISK_XSS: l'utente può inviare contenuto non ripulito (sia HTML con contenuto attivo che file non protetti);
• RISK_CONFIG: l'utente può modificare la configurazione globale, le azioni mancano dei controlli di integrità
• RISK_MANAGETRUST: gestisce le maschere di bit di permessi degli altri utenti;
• RISK_DATALOSS: può distruggere grandi quantità di informazioni che non possono essere facilmente recuperate.

Per quanto riguarda i valori abbiamo invece:

• captype: tipo di permesso di lettura o scrittura, per ragioni di sicurezza il sistema impedisce tutte le funzionalità di scrittura per gli account guest e gli utenti non registrati;
• contextlevel: dichiara il livello di contesto in cui viene verificata questa funzionalità
• archetypes: specifica i valori predefiniti per i ruoli standard, questo viene utilizzato nelle installazioni, negli aggiornamenti e durante il ripristino dei ruoli per definire chi può operare;
• clonepermissionsfrom: quando aggiungi una nuova funzionalità, puoi ordinare a Moodle di copiare le autorizzazioni per ciascun ruolo dalle impostazioni correnti per un'altra capacità.

E' molto importante è ricordarsi di incrementare il numero di versione del plug-in dopo ogni modifica al file db/access.php, in modo che gli script di aggiornamento possano apportare le modifiche necessarie al database.

Per eseguire gli script di aggiornamento, è sufficiente accedere a Moodle come amministratore, dalla home page del sito verranno proposti i plugin da aggiornare mediante una procedura guidata.

has_capability() e require_login()

La funzione has_capability() è quella che ci permette di verificare se un utente ha un determinato permesso in uno specifico contesto. Si tratta di un approccio più corretto rispetto a quello che prevede di verificare il ruolo dell'utente e tramite il permesso stesso. La funzione ha questa definizione:

function has_capability($capability, context $context, $user = null, $doanything = true)

L'utente di solito non viene passato alla funzione in quanto viene verificato quello corrente, ma volendo potremmo verificare un utente diverso tramite l'id associato.

Un'altra funzione estremamente interessante è require_login(), essa permette di verificare che l'utente abbia effettuato l'accesso prima di accedere a qualsiasi corso o attività, verifica che l'utente sia iscritto o che abbia i permessi oppure che qualche plugin di iscrizione dia accesso temporaneo agli ospiti. Inoltre registra l'accesso ai corsi.