Creiamo un utente
Lotus Notes permette la creazione di utenti e gruppi di utenti. Un utente non è altro che un documento presente in un database particolare, chiamato names.nsf.
In realtà esistono però vari modi con i quali possiamo fare quest'operazione. Il più semplice è sicuramente quello di aprire l’address book del server, names.nsf, ed inserire al suo interno un nuovo utente. È però possibile anche definire un address book specifico per il database che dobbiamo gestire, ma questa spiegazione implicherebbe la conoscenza della parte di amministrazione di Notes e rischierebbe di confondere leggermente le idee, portando fuori tema la puntata. Quindi, per non complicare troppo la spiegazione, mi limiterò ad utilizzare il metodo più semplice, che consiste nella gestione diretta dell’address book.
Tale soluzione, che può andar bene in molti casi, potrebbe non essere la migliore in ambienti enterprise, dove ogni applicazione ha una gestione a parte e dove capire quali utenti sono specifici di un database e quali di un altro potrebbe essere un problema, utilizzando un solo address book, così come potrebbe essere un problema creare un address book troppo grosso.
Vediamo ora com'è possibile creare degli utenti in questo database, in modo che ci supportino durante gli esempi.
 
 

La prima cosa da fare, è quella di aprire il Domino Administrator e spostarsi nella pagina relativa a People & Groups. A questo punto dovrebbe apparire la lista degli utenti del server che si sta gestendo. Nel caso che il server sia stato appena installato è probabile che tale lista comprenda un solo nome.
Sopra la lista vi sono dei pulsanti, il primo di tutti è Add Person, che sicuramente è il più interessante, e permette di aggiungere un nuovo utente.
Quello che faremo ora è creare due utenti, sui quali sperimenteremo i vari permessi di accesso.
Tali utenti saranno NORMALE e PRIVILEGIATO. In entrambi i casi andremo semplicemente ad indicare i campi Last Name, User Name e InternetPassword con gli stessi valori. Sono infatti queste le informazioni minime per poter creare un utente e garantirne l’utilizzo all’interno di un database.

Gestione degli utenti
Ora che abbiamo due utenti di test, possiamo iniziare ad usarli all’interno di un database. La prima cosa da fare è quella di aprire il database al quale vogliamo vincolare gli accessi ed andare a modificarne l’ACL, acronimo di Access Control List, che non è altro che la lista degli utenti che possono accedere a tale database.
Per fare questo occorre posizionarsi sul database, premere click destro e, dal menu contestuale, accedere alla voce Access Control. Se tutto è andato nel modo corretto dovreste trovarvi di fronte ad una maschera contenete una lista di voci, che rappresentano gli utenti o i server abilitati ad aprire tale database. Esiste però una voce di default, chiamata appunto “-Default-“. Tale voce, se non modificata, indica che, gli utenti che non si identificano all’ingresso nel database, hanno accesso di Designer. Per forzare così una validazione siamo costretti a modificare tale valore da Designer a No Access.
In questo modo, se proviamo a salvare e ad accedere al database tramite un browser, noteremo che ci verrà richiesta una Basic Autentification da parte del browser, tramite la classica maschera di richiesta di Login e Password.

Se non immettiamo nessun valore Notes si limiterà a non farci entrare, mostrando il classico errore 401, che indica che l’utente non è autorizzato a questa operazione.
Proviamo allora ad effettuare la prima modifica ad database, aggiungendo l’utente NORMALE all’ACL del database, ed attribuendogli il tipo Person e l’accesso come Designer.
Proviamo ora a salvare e a chiedere al browser un reload della pagina. Noteremo che, digitando NORMALE sia come utente che come password, sarà nuovamente possibile accedere ai documenti del database sul quale stiamo lavorando.
Ora però, a differenza di quello che accade normalmente, dall'interno del database o da un qualsiasi agente, sappiamo esattamente il nome dell’utente che lo sta utilizzando.
Esiste infatti una variabile CGI chiamata REMOTE_USER che possiamo interrogare per sapere chi si è identificato all’apertura del database.
Tanto per fare una prova, proviamo a scrivere il seguente agente:

import lotus.domino.*;
public class JavaAgent extends AgentBase {
 public void NotesMain() {
  try {
   Session session = getSession();
   AgentContext agentContext = session.getAgentContext();
   Document doc = agentContext.getDocumentContext();

   String cNome = doc.getItemValueString("REMOTE_USER");

   getAgentOutput().println( "Tu sei: " +cNome );

  } catch(Exception e) {
   e.printStackTrace();
  }
 }
}

Questo agente si limita ad accedere al documento corrente e ad interrogare la variabile CGI REMOTE_USER presentandola a video. Noteremo quindi, alla sua invocazione tramite URL:

http://127.0.0.1/iform.nsf/testCheckUser

che il browser risponderà con la seguente scritta:

Tu sei: NORMALE

che è il nome dell'utente col quale ci siamo identificati.
Se proviamo però a forzare l’ingresso con l’utente PRIVILEGIATO:

http://PRIVILEGIATO:PRIVILEGIATO@127.0.0.1/iform.nsf/testCheckUser

noteremo che  l’utente, dato che non è indicato all’interno dei nomi degli utenti abilitati all’ingresso in questo database, non verrà accettato dal server che, dopo averci chiesto, fino a 3 volte, il nome dell’utente, concluderà con un errore 401.
Se proviamo ora ad aggiungere tale utente, alla lista degli utenti che possono effettuare operazioni nel nostro ambiente di test, noteremo che anche l’utente PRIVILEGIATO potrà accedere al database.

Come avrete notato, per forzare un determinato accesso a iform.nsf, ho utilizzato la sintassi estesa con la quale è possibile invocare un URL.
Attenzione però all’utilizzo di tale sintassi. Pur essendo un modo comune di identificazione da parte di un browser, verso un server, i browser utilizzano tale accesso in maniera diversa.
Ad esempio, se utilizziamo Netscape ed entriamo su un certo server identificandoci in un certo modo:

http://PRIVILEGIATO:PRIVILEGIATO@127.0.0.1/iform.nsf/testCheckUser

e poi proviamo una connessione con un utente differente

http://NORMALE:NORMALE@127.0.0.1/iform.nsf/testCheckUser

il browser non si accorge del cambio di identità, e continuerà ad identificarci verso il server come se fossimo l’utente PRIVILEGIATO. Almeno questo accade dalla versione 4.05, all’ultima versione 4.x.

Figura 6 Errore di login
 
 

Figura 7 Controllo utente

Se invece utilizziamo un normale Internet Explorer l’utente viene correttamente modificato all’esecuzione del secondo utente. Per tale ragione consiglio l’utilizzo di Explorer, nel caso che si debbano fare numerosi tentativi con cambio di utente.
È comunque possibile continuare ad utilizzare Netscape, basta avere l’accortezza di usare una versione meno recente, oppure di uscire e rientrare dal programma in caso di cambio utente.
Finita questa doverosa puntualizzazione, che normalmente crea un notevole imbarazzo in fase di sviluppo di un sito sottoposto a identificazione, ed o ora che sappiamo come identificare una determinata persona all'interno di un database, vediamo come è possibile eseguire una serie di operazione in modo condizionato.

Form dinamiche
La prima modifica che andremo a fare è il classico condizionamento di visualizzazione.
Prendiamo ora una qualsiasi form e proviamo a condizionare il titolo in base all’utente. Andrò ad usare, per coloro che seguono il corso dalla prima puntata, la form di nome submit, che era un semplice esempio di uso dell’opzione submit.
Andiamo a modificare la prima riga, che riporta la scritta “esempio di uso di submit”, aggiungendo anche “per utente normale”. A questo punto, per poter sperimentare il cambio di utente, andiamo a copiare tale riga sulla seconda riga della form, andando ad indicare “per utente privilegiato” al posto di normale.

Non ci resta ora che condizionare tali due righe con una semplice formula.
Se, tramite il click destro del mouse, attiviamo la form di modifica dei parametri del testo, possiamo indicare la formula con la quale condizionare la visualizzazione.
Notes infatti ci permette di indicare una condizione per la quale un certo paragrafo, nel nostro caso la riga, non deve essere visualizzato. Dato che esiste una funzione in grado di restituire il nome dell'utente corrente, andremo ad inserire la seguente espressione che ci permette di nascondere il dato all’utente NORMALE:

@UserName="NORMALE"

allo stesso modo potremmo fare per l’utente privilegiato:

@UserName="PRIVILEGIATO"

Se proviamo ora le due diverse visualizzazioni, noteremo come, l’aspetto della form muterà di conseguenza:

http://PRIVILEGIATO:PRIVILEGIATO@127.0.0.1/iform.nsf/submit
http://NORMALE:NORMALE@127.0.0.1/iform.nsf/submit

La comprensione di questo aspetto è fondamentale, in quanto, con questa semplice tecnica è possibile adattare completamente il layout di una form ad un certo utente.
 

I ruoli
Giustamente chi gestisce un database Notes potrebbe non voler legare il disegno di una form ad un certo utente, ma magari ad un gruppo di utenti perché probabilmente, non è possibile sapere, all’atto della costruzione delle maschere, quali sono gli utenti che possono fare un qualcosa, ma neppure quali sono esattamente i gruppi che si verranno a creare.
In fase di progettazione, normalmente, si conoscono solo quali sono le funzionalità che deve avere un database, senza sapere chi e come le andrà a sfruttare.
Per tale ragione sono stati inventati i ruoli.
Se provate ad aprire la maschera contenente la lista degli utenti che possono usare il database noterete che, sulla parte sinistra, esiste una piccola icona che riporta la frase: “roles”.
I ruoli non sono altro che delle etichette che si possono creare in maniera completamente autonoma ed associare ad un determinato gruppo o ad un determinato utente.
Ipotizziamo che all’interno del database ci siano tre aree: A, B e C. In tali aree devono accedere solamente degli utenti autorizzati.
 
 

A questo punto ipotizziamo che ci siano due utenti o due gruppi con caratteristiche differenti. Il primo gruppo può accedere solamente all’area A, mentre il secondo all'area A e B, ma non a C.
Come possiamo risolvere tale problema? Condizionando le maschere in base all'utente? Sicuramente no, perché se ci fosse un altro utente da inserire, che magari non deve vedere l’area A e B, ma solo C, sarebbe dispendioso andare a modificare l’intero archivio per gestire quest’eccezione.
Per tale ragione, l’approccio migliore che possiamo avere è quello di definire dei ruoli.
Nel nostro caso creeremo tre ruoli chiamati appunto A, B e C. Una volta confermata l’informazione, se proviamo a posizionarci nella lista dei nomi presenti in ACL, noteremo che, in basso a destra, la finestrella con indicati i roles andrà a visualizzare i tre valori appena inseriti.
Proviamo ora ad selezionare i ruoli A, per l’utente NORMALE e A e B per l’utente PRIVILEGIATO.
A questo punto rientriamo nella form che avevamo precedentemente configurato per visualizzare delle informazioni diverse in base all’utente, e proviamo ad inserire tre nuove righe per verificare l’avvenuta gestione dei ruoli.
In queste righe andremo a verificare singolarmente se i tre ruoli sono stati gestiti nella maniera corretta, inserendo le seguenti condizioni di non visualizzazione:

!@IsMember("[A]"; @UserRoles)
!@IsMember("[B]"; @UserRoles)
!@IsMember("[C]"; @UserRoles)

ovviamente useremo la prima condizione per la prima riga, la seconda per la seconda e così via.
Quello che noteremo ora, entrando nelle maschere, è che, le righe condizionate in base ai ruoli, varieranno la loro visualizzazione in base all’utente, non in base al nome, ma in base al parametro ulteriore che abbiamo indicato. Questa particolarità ci permette quindi di lavorare su un livello di astrazione maggiore non sul singolo utente, ma su delle funzionalità che debbono o meno essere attivate.

Conclusioni
Come abbiamo visto, in modo molto semplice ed intuitivo, è possibile applicare una gestione utenti, ad un qualsiasi database Notes. Dal punto di vista della sicurezza si può però obiettare che, una basic autentification, non è sicuramente un modo sicuro di proteggere dei dati in rete, ma se pensiamo questo approccio, all'interno di una connessione SSL, noteremo subito che la tecnica diventa estremamente sicura.
Nella prossima puntata andremo in maggior dettaglio sulla gestione utenti, vedendo come, da codice, possiamo fare tutte le operazioni che qui abbiamo fatto manualmente.