Di seguito viene descritto il flusso operativo per un utente standard (senza permessi speciali) e per un superutente (con permessi di amministrazione).
116
L’accesso al sito crea un oggetto di tipo User, inizialmente vuoto. Tale oggetto viene salvato nella sessione (PHP serializza automaticamente gli oggetti [51]) per essere riutilizzato nelle altre pagine del sito. Un controllo sulla variabile assicura che non venga sovrascritto il precedente oggetto.
1. $user = &$_SESSION['user']; 2. if (!isset($user))
3. $user = new User();
Il carattere &, permette di assegnare un riferimento alla variabile.
Apache è stato configurato per accettare sia client con un certificato valido che senza. La pagina di autenticazione (login.php) distingue i casi e risponde in maniera diversa. L’intero flusso di autenti-cazione è riassunto nel diagramma in Figura 8.2.
Autenticazione utente Ha un certificato valido? È registrato? SI Accedi con password SI Autenticazione con username e password NO La password è scaduta? Registra il certificato NO Cambia password SI Accedi NO Autenticazione con certificato
Figura 8.2. Diagramma di flusso dell'autenticazione.
Tramite la funzione della classe User, hasValidCert(), si verifica se il client ha fornito un certificato valido:
Se il certificato è valido, la chiamata alla funzione isCertRegistered() verifica se il sistema presenta già un certificato con quel seriale.
Se esiste, viene proposta una form in cui inserire la password per accedere al sito. Il controllo avviene tramite la funzione checkPsw($psw).
Se non esiste, viene proposta una form in cui registrare il certificato selezionando la password da utilizzare come autenticazione. La registrazione avviene tramite il me-todo registerCert($psw).
Se non viene fornito un certificato valido, la pagina propone di autenticarsi con username e password. Dopo essersi autenticati correttamente, con il metodo login($usr, $psw), viene eseguito in automatico un controllo sulla scadenza della password.
117
Se la password è scaduta, il sito reindirizza verso la pagina change_password.php, in cui si propone all’utente di inserire una nuova password (l’intera operazione è gestita dal metodo changePassword($newPsw) della classe User). A cambio effettua-to, l’utente viene reindirizzato alla pagina di accesso, user_account.php.
Se la password non è ancora scaduta, l’autenticazione reindirizza direttamente alla pagina utente, user_account.php.
L’immagine in Figura 8.3, mostra le diverse risposte dell’applicazione alla presenza (in alto) o meno (in basso) di un certificato valido.
Figura 8.3. Risposte dell'applicazione alla presenza o meno di un certificato valido.
Se si tenta di bypassare l’autenticazione, digitando direttamente nella barra degli indirizzi l’URL delle pagine protette, si viene reindirizzati alla pagina di login. Ciò è realizzato eseguendo un sem-plice controllo sulla variabile di stato $logged della classe User, accessibile tramite il metodo isLog-gedIn(). Viceversa, se si tenta di accedere alla pagina login.php dopo essersi già autenticati, si viene automaticamente reindirizzati alla pagina user_account.php.
A prescindere dal tipo di autenticazione utilizzata e dal tipo di utente (normale o superutente), dopo essersi correttamente autenticati, si viene reindirizzati sulla pagina user_account.php, che contiene tutti i dati relativi all’utente (inclusi i permessi a esso associati). L’immagine in Figura 8.4, per esempio, mostra la pagina di account dell’utente “client1”, appartenente al gruppo di default (id_group = 0), ossia senza un ruolo ben preciso e quindi privo di alcun permesso. A sinistra sono elencati i dati dell’utente, mentre a destra i permessi.
I permessi sono accessibili tramite il metodo getPermissions(), che restituisce un array 3-dimensionale con il codice univoco, la descrizione e il valore del permesso. La colonna “Tipo” defi-nisce se il permesso è concesso a livello di gruppo o di utente e il suo valore è determinato con l’ausilio della funzione isUserPermission($perm).
118
Figura 8.4. Pagina account di un utente normale.
I dati a sinistra sono modificabili con il metodo __set($field, $value) premendo il tasto “Salva modifiche”. I campi in sola lettura sono riconosciuti con il metodo isEditable($field) e non sono modificabili (i campi sono impostati a readonly). La pagina permette anche di aggiungere nuovi campi all’array utente. Come si può notare in Figura 8.4, infatti, sono presenti due riquadri, dove inserire il nome del nuovo campo e il suo valore associato. Premendo il tasto aggiungi, la nuova variabile viene aggiunta a quelle già esistenti (Figura 8.5). Infine, i campi “Cambia password” e “Conferma password” permettono la modifica controllata della password tramite il metodo change-Password($newPsw).
Figura 8.5. Aggiunta di un nuovo campo "new_field" alla lista delle variabili.
Trattandosi di un utente normale, privo di qualsiasi permesso, i link alle pagine di amministrazione non vengono visualizzati. Per fare un confronto con un superutente, si osservi la Figura 8.6. Come si può notare, nel menù in alto, sono presenti quattro link che in Figura 8.4 non sono presenti. Quei collegamenti fanno riferimento alle pagine di amministrazione racchiuse dal riquadro
tratteg-119
giato di Figura 8.1. Il controllo dei permessi dell’utente viene fatto chiamando la funzione hasPer-mission($perm). In particolare la pagina “Gestione utenti” e quella “Gestione gruppi”, controlla se l’utente dispone del permesso “MNGUSRGR” (numero 17 nella lista di Figura 8.6); la pagina “Ge-stione certificati” controlla il permesso “MNGCERT” (numero 32) e la pagina “Monitor Log” controlla il permesso “MNTRLOG”. Poiché il gruppo “superutente” (che nel sistema è indicato con id_group = 1) dispone di tutti i permessi, l’utente “max” ha accesso a tutte le pagine del siste-ma.
Figura 8.6. Pagina account di un superutente.
Ma nascondere i link non è sufficiente a impedire l’accesso a una pagina riservata. Cosa accade se l’utente normale di prima prova a scrivere il nome della pagina direttamente nella barra degli indi-rizzi? Viene accolto da una pagina di accesso negato. All’inizio di ogni pagina riservata, è presente, infatti, un controllo sul permesso necessario ad accedere a quella pagina. Se il permesso non è attivo, si viene automaticamente reindirizzati alla pagina di Figura 8.7.
120
Figura 8.7. Reindirizzamento alla pagina di accesso negato.
Per completare la panoramica sull’autorizzazione, vediamo un altro esempio illustrato in Figura 8.8.
Figura 8.8. Pagina di account per un utente del gruppo “tecnici”.
L’utente “tech”, appartenente al gruppo dei tecnici (id_group = 6) presenta un privilegio utente per l’accesso al monitoraggio dei log (permesso numero 33 a destra). Il fatto che si tratti di un permesso a livello utente, è evidenziato dalla colonna “Tipo”, che presenta la scritta blu “Utente” in corri-spondenza del permesso. A confermare l’attivazione del permesso, è la presenza del link alla pagina di monitoraggio dei log, “Monitor Log”, nel menù di navigazione in alto.
121