Newsgroup: it.comp.lang.delphi
Titolo: Utenti Firebird+ delphi

 Vorrei creare una applicazione dove gli utenti siano a livello di db 
per monitorare meglio l'applicazione... voi sapete che tabelle devo 
utilizzare ed eventuale codice per un inserimento.
Grazie Manuel
--- posted by geoForum on 
http://www.delphiedintorni.it

 Grazie Manuel
Non conosco FireBird e la sua gestione delle protezioni, quindi non sò 
se potrei esserti utile al 100%
Io con SQL Server opero in genere su due livelli.
Il primo è quello di gestione dei login al database, attribuendo 
autorizzazioni specifiche sui singoli oggetti in modo che eventuali 
utenti un pò più esperti possano operare direttamente su database, ma 
comunque con dei limiti già imposti. Per quanto relativo il login 
dell'applicazione, in genere utente e password li tengo in un file ini 
criptati o meno.
Definisco poi un livello di protezione a livello di applicazione, 
usufruendo di alcune tabelle specifiche. Inizialmente impostavo queste 
tabelle nel database insieme ai dati, ultimamente ho preso l'abitudine 
di creare un database specifico per la configurazione, ma questo è un 
altro discorso.
Nel dettaglio, definisco queste tabelle:
- tabella degli utenti: dati minimi sono ovviamente utente e password;
- tabella dei gruppi di utenti;
- ovviamente una tabella che associ gli utenti ai gruppi (oppure nella 
tabella degli utenti metti il campo "gruppo", dipende dal livello di 
granularità che desideri definire).
A questo punto hai una gestione minima degli Utenti.
Nell'applicazione puoi definire una maschera per effettuare il login e 
magari una classe connessa con una variabile a visibilità globale che 
permetta di effettuare il login e di verificare la correttezza dei dati 
inseriti.
Se poi vuoi gestire il livello di accesso a singole funzionalità o 
maschere dovrai aggiungere:
- una tabella con un'anagrafica delle funzionalità;
- una tabella con un'anagrafica delle maschere dell'applicazione;
- una tabella che associ funzionalità a utenti o gruppi: se il record è 
presente significa che l'utente o il gruppo può accedere ad una 
determinata funzionalità;
- una tabella che associ maschere a utenti o gruppi: se il record è 
presente uno specifico campo ti permette di definire il tipo di accesso 
(controllo completo, sola lettura, accesso negato alla maschera). 
Naturalmente l'assenza di un record indica la negazione dell'accesso.
La classe di gestione dell'utente corrente può essere estesa con dei 
metodi che ti dicano se l'utente può attivare una determinata 
funzionalità oppure il livello di accesso ad una certa maschera.
Per farti qualche esempio:
1. in tutti gli eventi associati al menu principale delle mie 
applicazioni inserisco:
"
...
if not CurrentUser.Logged then
   CurrentUser.DoLogin;
...
"
Dove CurrentUser.DoLogin apre la maschera di Login, richiede l'utente 
corrente ed eventualmente solleva un'eccezione se qualcosa non va 
(utente non esiste, password non valida, ecc.)
2. se in una form devo controllare il livello di accesso, nel FormCreate:
"
var
   fla: TFormLevelAccess;
...
fla := CurrentUser.LevelAccess(Self.Name) then
if fla = flaDenied then
   raise Exception.Create('...');
if fla = flaReadOnly then begin
   // disabiliti tutti i controlli che non devono essere gestiti
   // dall'utente, ecc.
end;
...
"
TFormLevelAccess è un'enumarazione che definisce i tre livelli di 
accesso. In relazione al valore verifico quali campi devo rendere 
ReadOnly, piuttosto che le modalità di apertura delle tabelle.
3. se devo verificare l'abilitazione ad una certa funzionalità, in un 
punto qualsiasi del codice:
"
...
if CurrentUser.CanDo(FNK_STAMPA_REPORT) then begin
   ...
end;
"
Questo si spiega da solo.
Questo direi è già una discreta gestione delle autorizzazioni. Puoi 
addentrarti fino a gestire i singoli campi (ma a mio avviso diventa un 
macello anche solo come interfaccia utente: meglio raggruppare i dati in 
più form a cui dare o meno l'accesso).
Poi dipende fin dove vuoi arrivare.
Mentre l'anagrafica delle maschere e delle funzionalità in genere è 
"hard coded", non c'è bisogno di creare interfacce specifiche per 
poterle definire (sostanzialmente dipende se servono a te o ad altri 
programmatori), il minimo è poi costruire una maschera di gestione dei 
gruppi, delle anagrafiche utenti e che permetta l'associazione (sempre 
se tu prevedi che degli utenti amministratori possano definire queste 
informazioni liberamente).
Infine, non so se esistano metodi per integrare il tutto con i Login del 
  Database Server ma, sinceramente, preferisco sempre tenere le due 
gestioni completamente separate.
Spero di averti dato qualche spunto.
Ciao,
Gianluca.

Diciamo che hai stabilito delle ottime regole per un sistema multiutente,
anch'io ho le mie e preferirei non modificarle per i vecchi programmi.
la questione è molto piu specifica e banale, la risumo in queste 
domande: 
 1-Quali sono le tabelle firebird per gli utenti.
 2-Come posso creare un nuovo utente.
 3-Quali sono le abilitazioni minime che devo fornigli.
Perchè utilizzando un solo utente DB il sistema non mi permette di 
monitorare gli utenti e fare quelle operazioni che un help desk deve 
poter eseguire su una applicazione multiutente tipo scollegare la 
sessione.
Ti ringrazio per la tua risposta diciamo che mi hai fornito una piccola 
lezione che terro' presente al momento di creare la mia prossima 
struttura del DB
;-)
