Ruoli e permessi: un buon approccio nella definizione delle autorizzazioni?

Question

Ruoli e permessi: un buon approccio nella definizione delle autorizzazioni?

#1 da (4 voti)
#2 da (1 voti)

3

La mia applicazione ha utenti e amministratori. Gli amministratori si dividono in due: super-amministratore e amministratore limitato. Il super ottiene tutte le autorizzazioni mentre il limitato può essere configurato per ereditare solo le autorizzazioni di amministratore che sono specificamente necessarie.

Sto pensando di definire i miei permessi nel seguente modo. Qualsiasi autorizzazione utente ha un permesso di amministratore:
Utente:
- post_create
- post_update
- post_delete

Amministratore:
- administrator_post_create
- administrator_post_update
- administrator_post_delete

È un buon approccio? Dovrei piuttosto assegnare a un amministratore tutte le autorizzazioni degli utenti e poi un altro come "administrator_post_manage_all" che ignora il controllo della proprietà e consente a un amministratore di apportare modifiche?

Modifica
Le seguenti regole devono essere soddisfatte:

Solo alcuni utenti possono creare, aggiornare, eliminare post; tuttavia, devono essere i proprietari del post da aggiornare, eliminare. Ogni utente dell'applicazione dovrebbe essere in grado di leggere i post. I miei amministratori dovrebbero essere in grado di aggiornare ed eliminare i post di qualsiasi utente.

php mysql permissions roles

posta Cristian 08.10.2015 - 18:38

fonte

2 risposte

Leggi altre domande sui tag php mysql permissions roles

Meglio chiamare per immergersi nei sottomodelli o passare un risultato Quanto impegno devo dedicare alle specifiche funzionali?

score 4 · Answer 1

Ho avuto a che fare con questi problemi di autorizzazione in una dozzina di software fa, e lungo la strada ho trovato che questa fosse la soluzione migliore:

I permessi riflettono gli eventi (oi requisiti) del sistema;
Gli utenti possono essere assegnati a permessi specifici;
Utilizza solo 2 autorizzazioni singole per le operazioni CRUD per entità: leggi e modifica;

Operazioni CRUD: non ho mai affrontato una situazione che un utente può, ad esempio, eliminare o aggiornare un'entità ma non può crearla, quindi se l'utente può modificare un'entità, è inteso che può crearlo, aggiornarlo ed eliminarlo.

Tuttavia, in base alle tue esigenze, gli utenti possono leggere qualsiasi post e gli amministratori possono aggiornare / eliminare i post di altri utenti, quindi modellerei le autorizzazioni in questo modo:

post_modify - > Gli utenti possono creare, aggiornare ed eliminare i post;
post_modify_others - > Gli utenti possono aggiornare ed eliminare i post di altri utenti;

La cosa più importante qui è che la semantica e il significato delle autorizzazioni sono totalmente allineati alle tue esigenze, il che semplifica l'implementazione.

Quindi, gli amministratori verrebbero assegnati alle autorizzazioni post_modify e post_modify_others , mentre gli utenti verrebbero assegnati solo all'autorizzazione post_modify .

Gruppi di utenti: Solitamente memorizzo gli utenti e le relative autorizzazioni in una tabella specifica, ma se il numero di utenti e autorizzazioni inizia a crescere, è consigliabile creare un'altra tabella per collegare utenti e autorizzazioni (ad esempio, gruppo di utenti) al fine di rendere la gestione Più facile. Quindi avresti 2 gruppi - Amministratore e Utenti - e assegneresti gli utenti a questi gruppi, in base ai loro ruoli nel sistema, e le autorizzazioni sarebbero assegnate per gruppo e non per utente.

score 1 · Answer 2

Quindi suggerirei di pensare a un modello generale di dati per l'archiviazione delle autorizzazioni in grado di gestire situazioni più complesse in futuro. Questa risposta ha una buona astrazione link utilizzando una tabella per le autorizzazioni, un'altra per collegare i ruoli alle autorizzazioni e un'altra per collegare gli utenti a ruoli, e un altro per dare le autorizzazioni direttamente agli utenti. È possibile scegliere di utilizzare quel modello di dati e inserire manualmente le righe nelle tabelle e risolvere le query per caricare quali utenti dispongono di autorizzazioni. Quindi se la tua applicazione diventa più complessa puoi aggiungere più righe senza dover modificare le tue query.