Visualizzazione dei risultati da 1 a 7 su 7
  1. #1
    Utente di HTML.it
    Registrato dal
    Nov 2012
    Messaggi
    50

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

    Buon pomeriggio a tutti,
    per un progetto universitario devo creare un sistema che gestisce alcuni utenti. Diciamo che ho un accesso di primo livello che può vedere e manipolare l'intero db, e un accesso di secondo ordine che può vederne solo una parte.
    'Direttore' è del primo tipo e poi ci sono vari 'Responsabili' che possono accedere solo al db del proprio settore.

    Come faccio in Java a gestire questa cosa?

    grazie

  2. #2
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,284
    Quote Originariamente inviata da ReaSanka Visualizza il messaggio
    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) ?
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    java.util.function Interfaces Cheat SheetJava Versions Cheat Sheet

  3. #3
    Utente di HTML.it
    Registrato dal
    Jan 2006
    Messaggi
    19
    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

  4. #4
    Utente di HTML.it
    Registrato dal
    Nov 2012
    Messaggi
    50
    Quote Originariamente inviata da andbin Visualizza il messaggio
    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!

  5. #5
    Utente di HTML.it
    Registrato dal
    Jan 2006
    Messaggi
    19
    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

  6. #6
    Utente di HTML.it
    Registrato dal
    Nov 2012
    Messaggi
    50
    Quote Originariamente inviata da bp69 Visualizza il messaggio
    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ì...

  7. #7
    Utente di HTML.it
    Registrato dal
    Jan 2006
    Messaggi
    19
    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

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.