Metodo per restringere la visuale di un database in base a nome utente e password

[andbin]

Come faccio in Java a gestire questa cosa?

In che senso?

Precisiamo una cosa: un conto è se ci sono dei "grant" a livello di DB per cui l'account "pippo" del DB può fare quello che vuole con qualsiasi tabella mentre l'account "paperino" può solo fare SELECT sulla tabella X, SELECT/INSERT sulla tabella Y e nulla sulla tabella Z.
Questi sono grant rinforzati a livello di DB, lato Java non puoi farci nulla. Se la connection Java verso il DB usa l'account "paperino", vedrai appunto i limiti dati dai grant.

Un altro conto è la gestione degli utenti come si fa solitamente nelle comuni applicazioni (webapp ma anche in generale), dove la/e connection al DB usano un account che può fare tutto quanto è lecitamente possibile per il buon funzionamento della applicazione ma gli utenti e le relative autorizzazioni e privilegi sono gestiti a livello "applicativo".

Quindi in quale scenario sei (o vuoi essere) ?

[bp69]

Ciao,
se ti può essere utilie io ho sviluppato un'applicazione in parte simile, usando il secondo metodo citato da andbin.
Mi connetto al DB sempre con lo stesso utente del database.
Nel DB c'è una tabella relativa agli utenti dell'applicazione, la quale oltre alle credenziali contiene un campo che indica il tipo di "gruppo" al quale appartiene l'utente, con i relativi permessi.
L'applicazione anche se in javaSE è comunque strutturata model + view (che contiene il relativo controller come innerclass).
Nel model che gestisce l'accesso ai dati ho messo comunque tutte le funzioni possibili: select, add, update, delete, ecc...
Nella view invece, in base al "tipo di utente" che mi tiro dietro dal login iniziale, personalizzo il menu e quindi quello che l'utente può fare.
In questo modo oltre che alle limitazioni sul DB, posso anche definire per le varie view non solo "cosa" fare vedere, ma anche eventualmente "come".
Ciao

[ReaSanka]

In che senso?

Precisiamo una cosa: un conto è se ci sono dei "grant" a livello di DB per cui l'account "pippo" del DB può fare quello che vuole con qualsiasi tabella mentre l'account "paperino" può solo fare SELECT sulla tabella X, SELECT/INSERT sulla tabella Y e nulla sulla tabella Z.
Questi sono grant rinforzati a livello di DB, lato Java non puoi farci nulla. Se la connection Java verso il DB usa l'account "paperino", vedrai appunto i limiti dati dai grant.

Un altro conto è la gestione degli utenti come si fa solitamente nelle comuni applicazioni (webapp ma anche in generale), dove la/e connection al DB usano un account che può fare tutto quanto è lecitamente possibile per il buon funzionamento della applicazione ma gli utenti e le relative autorizzazioni e privilegi sono gestiti a livello "applicativo".

Quindi in quale scenario sei (o vuoi essere) ?

Grazie ad entrambi per la risposta!
Cito un attimo andbin. Io vorrei essere nel secondo scenario. A livello di database non ho impostato (almeno per ora) alcun 'grant'. In parole povere ho un database con 3 tabelle: strumentazioni, dipendenti, e spazi (di un'azienda). In realtà ne ho 4 perchè una è la tabella che contiene appunto le credenziali. Prendiamo per esempio la tabella dei dipendenti: ha una colonna "settore" che distingue i vari dipendenti. Per esempio ho tizio X che lavora nel settore A1, e tizi Y,Z che lavorano nel settore A2 e via dicendo.. però sono tutti nella stessa tabella! Quello che vorrei fare io è questo: il responsabile del settore A1 può gestire e manipolare unicamente i dipendenti del suo settore e con gli altri non può fare nulla.
A livello java io per adesso, quando inserisco le credenziali del direttore(che può fare e vcedere tutto) e quando inserisco quelle dei responsabili, non ho differenze, proprio perché non so come fare questa cosa che voglio fare.
Spero di essere stata chiara!

Grazie ancora!

[bp69]

Ciao,
personalmente lo gestirei a livello di "model", cioè la classe che dovrebbe contenere i metodi per interagire con il DB.
Nel DB dovrà esserci una tabella (potrebbe essere sempre quella dei dipendenti) che in base al responsabile da qualche parte ha scritto di quale settore.
Sulla base di questo, quando dalla view richiedi al model di modificare un dipendente (per esempio passandogli come argomenti il bean del dipendete con i dati da aggiornare + un riferimento al responsabile loggato, e quindi al settore che può modificare, il model inizia a caricare il record del dipendente dal DB e verifica se il campo settore del dipendente corrisponde a quello relativo al responsabile.
Se si, modifica e quindi notifica alla view mostrando i dati modificati, se no invia un messaggio indicando che il responsabile sta cercando di modificare un settore diverso dal suo e l'aggiornamento non è possibile.
Spero di averti dato un'indicazione sulla quale ragionare.
Ciao

[ReaSanka]

Ciao,
personalmente lo gestirei a livello di "model", cioè la classe che dovrebbe contenere i metodi per interagire con il DB.
Nel DB dovrà esserci una tabella (potrebbe essere sempre quella dei dipendenti) che in base al responsabile da qualche parte ha scritto di quale settore.
Sulla base di questo, quando dalla view richiedi al model di modificare un dipendente (per esempio passandogli come argomenti il bean del dipendete con i dati da aggiornare + un riferimento al responsabile loggato, e quindi al settore che può modificare, il model inizia a caricare il record del dipendente dal DB e verifica se il campo settore del dipendente corrisponde a quello relativo al responsabile.
Se si, modifica e quindi notifica alla view mostrando i dati modificati, se no invia un messaggio indicando che il responsabile sta cercando di modificare un settore diverso dal suo e l'aggiornamento non è possibile.
Spero di averti dato un'indicazione sulla quale ragionare.
Ciao

Purtroppo non so cosa siano le model e non sto ancora gestendo le view (sono l'interfaccia grafica vero?)
Quindi forse dovrei prima vedere un po' queste interfacce grafiche e vedere di gestire la cosa da lì...

[bp69]

Ciao,
scusa se ho dato per scontate alcune cose (in rete puoi comunque trovare molte info sul pattern Model-View-Controller).
In pratica il "model" è la parte di codice che definisce "la logica dell'applicazione", la "view" la parte che definisce la sola "visualizzazione".
Tieni conto che questo è un consiglio di buona pratica, ma non è obbligatorio.
Comunque, senza dilungarmi oltre, il tutto era per dirti che quello che vuoi fare io lo gestirei a livello di codice java, magari in una classe che si chiama DipendentiModel...
Ciao