Memorizzazione delle autorizzazioni dell'applicazione in un database

Question

Sto sviluppando un'applicazione per la nostra azienda che alla fine avrà molti modi per limitare gli utenti a particolari sezioni/moduli. Mentre l'applicazione è ancora piccola, mi piacerebbe passare a un nuovo metodo di archiviazione delle autorizzazioni che, man mano che l'applicazione cresce, rimarrà facile da gestire e interrogare.

Attualmente nel nostro database MySQL abbiamo una tabella chiamata "utente" che memorizza l'ID dell'utente, il nome utente e la password. In una tabella separata denominata "user_acl" è il seguente:

user_acl_id 
acl_root 
acl_news_read 
acl_news_write 
acl_news_modify 
acl_reports_read 
acl_reports_write 
acl_reports_modify 
acl_users_read 
acl_users_write 
acl_users_modify 

Abbiamo solo 3 moduli al minuto, ma con il tempo più sarà creato e dovranno essere aggiunti i permessi per ciascuno.

Piuttosto che creare una colonna per ogni permesso, c'è un altro modo o la memorizzazione di queste informazioni?

Answer 1

Lo farei in questo modo.

table name: permission 
columns: id, permission_name 

e poi posso assegnare più autorizzazioni per l'utente che utilizza una relazione molti a molti tabella di relazioni

table name: user_permission 
columns: permission_id, user_id 

Questo progetto mi permetterà di aggiungere il numero di permessi come voglio, e assegnarlo a come molti utenti come voglio

Mentre il progetto di cui sopra va con le vostre esigenze, ho il mio metodo per implementare ACL nella mia applicazione. Sto postando qui.

Il mio metodo di attuazione della ACL è questa:

1. utente sarà assegnato un ruolo (Admin, gli ospiti, il personale, pubblico)
2. Un ruolo avrà una o più autorizzazioni assegnate ad essi (user_write, user_modify, report_read) ecc.
3. Il permesso per l'utente verrà ereditato dal ruolo a cui è/o
4. L'utente può essere assegnato con autorizzazione manuale oltre all'autorizzazione ereditata dal ruolo.

Per fare questo, ho creato il seguente progetto di database.

role 
I store the role name here 
+----------+ 
| Field | 
+----------+ 
| id  | 
| roleName | 
+----------+ 

permission: 
I store the permission name and key here 
Permission name is for displaying to user. 
Permission key is for determining the permission. 
+----------------+ 
| Field   | 
+----------------+ 
| id    | 
| permissionName | 
| permissionKey | 
+----------------+ 

role_permission 
I assign permission to role here 
+---------------+ 
| Field   | 
+---------------+ 
| id   | 
| role_id  | 
| permission_id | 
+---------------+ 

user_role 
I assign role to the user here 
+---------------+ 
| Field   | 
+---------------+ 
| id   | 
| user_id  | 
| role_id  | 
+---------------+ 

user_permission 
I store the manual permission I may allow for the user here 
+---------------+ 
| Field   | 
+---------------+ 
| id   | 
| user_id  | 
| permission_id | 
+---------------+ 

Questo mi dà più controllo sull'ACL. Posso consentire ai superadmin di assegnare il permesso da soli e così via. Come ho detto questo è solo per darti l'idea.

Answer 2

Credo che dovresti fare queste autorizzazioni in formato jSON.

È possibile creare un'altra tabella con le autorizzazioni in cui è possibile aggiungere, modificare, eliminare le righe ogni volta che lo si desidera.

o

ogni volta che l'utente esegue l'autenticazione è possibile memorizzare tali autorizzazioni nella sessione e passarlo ai propri script.

Il mio suggerimento personale è la prima opzione.

Answer 3

Come dice Ibrahim, creare una nuova tabella specifica per le autorizzazioni.Assegna un valore numerico a un utente che rappresenta il loro livello di autorizzazione, ad esempio 1 = lettura, 2 = scrittura/lettura, 3 = modifica/scrittura/lettura. Quindi, nel codice, controllare il livello di autorizzazione appropriato prima di consentire a un utente di eseguire un'attività specifica. Se non hanno il valore richiesto (3 per modificare o> = 2 per scrivere) allora si blocca quell'abilità.

Answer 4

penso che si dovrebbe avere tavoli favoriti:

user 
user_x_profile 
profile 
profile_x_function 
function 

Si imposta vari profili "generici" "spettatore", "dipendente", "manager", ecc

Si imposta una "funzione "voce per ogni oggetto che si desidera controllare.

Quindi collegare le funzioni ai profili in profile_x_function.

Quindi assegnare uno o più profili a ciascun utente.

Questo riduce lo sforzo di amministrazione. Supponiamo di voler aggiungere un'altra funzione che solo i "gestori" possono utilizzare: basta aggiungere una nuova voce nella tabella delle funzioni, quindi aggiungere una voce nella tabella "profile_x_function" che collega al profilo "manager" l'autorizzazione al profilo gestore e è disponibile per tutti i gestori.

Per accedere alle query è necessario un join di cinque tabelle, ma si seleziona solo un attributo di permissione.