Aggiunta di livelli di autorizzazione in Rails

Question

Aggiunta di livelli di autorizzazione in Rails

#1 da (4 voti)

4

Quindi sto facendo un bug tracker per aiutarmi a imparare Ruby on Rails. La mia configurazione attuale è simile a questa:

Ogni Project has_many :metadata e has_many :permissions, through: :metadata . Anche alcune altre cose, ma questo è tutto ciò che è rilevante per questa domanda.
Ogni Metadatum (pessimo nome, lo so, ma funzionerà per ora) has_many :permissions e belongs_to entrambi :project e :person .
Ogni Permission belongs_to :metadatum e entrambi has_one :project, through: :metadatum e has_one :person, through: :metadatum . Rappresenta una persona in grado di fare una cosa su un progetto - per esempio, aggiungere un nuovo bug, o assegnare qualcuno a un bug, ecc. Ecc.

Ora, la mia domanda è se questo è un buon modo per aggiungere diversi livelli di permessi che sono diversi per ogni progetto - così, per esempio, la Eva di Project Manager non può modificare i progetti di Project Manager Bob solo perché è un Anche PM e QA James non possono aggiungere molti bug a un progetto che non dovrebbe testare.

Per me ha senso perché ogni progetto ha metadati che si applicano a tutti (che è memorizzato in Project ) e metadati individuali per ogni persona (che è in Metadatum e include cose come se l'hanno recitato o se gli hanno assegnato un nome personalizzato). Per me, è ragionevole che Metadatum memorizzi anche il livello di autorizzazione, dal momento che dipende dal progetto e dalla persona entrambi.

Tuttavia, sono preoccupato per l'utilizzo dello spazio, anche se non so se dovrei esserlo. Sarebbe piuttosto banale cambiarlo per usare un po 'di magia bitmasking per fare la stessa cosa, ma la mia preoccupazione è che è meno leggibile e consente solo di aggiungere una certa quantità di autorizzazioni prima di esaurire la stanza in un numero. Sono anche preoccupato che ci vorrà più tempo per controllare se qualcuno è autorizzato a fare qualcosa oltre alla maschera di bit, perché invece di permission & 1<<12 devi controllare project.permissions.find_by(person: person, allows: :allowance) , che implica il filtro due volte, e non è leggibile. Tuttavia, è concettualmente più semplice da comprendere e i metodi personalizzati possono essere facilmente scritti per semplificare la sintassi.

Ho il miglior approccio? Come posso farlo meglio?

design ruby-on-rails

posta Nic Hartley 22.12.2015 - 20:59

fonte

1 risposta

Leggi altre domande sui tag design ruby-on-rails

Comprensione del modello di deposito generico Come utilizzare un sistema di tipo strong per modellare i vincoli di business?

score 4 · Accepted Answer

Now, my question is if this is a good way to go about adding different levels of permission that are different for each project

È un buon inizio, ma ne risentirà se usato con un numero maggiore di utenti. La gestione delle autorizzazioni è gestita meglio attraverso i gruppi. Quindi Dev_Group è consentito Permissions A, B, C e IT_Admin_Group è permesso permessi C e D sullo stesso Project .

Il vantaggio qui è che quando Ishmael lascia il progetto, viene semplicemente rimosso dal IT_Admin_Group . E quando Helena si unisce al team, viene aggiunta a Dev_Group . Tutte le autorizzazioni necessarie vengono quindi automaticamente revocate o applicate in base alle circostanze. La gestione delle autorizzazioni di gruppo aiuta a evitare il problema di dimenticare accidentalmente di aggiornare un'area. E su progetti di grandi dimensioni, ciò accade abbastanza frequentemente quando vengono utilizzate le autorizzazioni individuali invece delle autorizzazioni di gruppo.

Puoi comunque utilizzare le autorizzazioni individuali per sovrascrivere le impostazioni del gruppo, se lo desideri. Quindi, se Helena era in un periodo di prova dopo essersi iscritta, potrebbe avere Dev_Group di permessi su A, B, C ma un singolo override per rimuovere C.

However, I'm concerned about space usage, though I don't know if I should be.

In questa fase dello sviluppo del tuo progetto, non dovresti esserne preoccupato. Err sul lato della leggibilità e facilità di manutenzione sopra ogni altra cosa. Se / quando questo diventa un progetto abbastanza grande, ti ringrazierai un milione di volte quando devi mantenere una sezione di codice che non hai toccato in 6 mesi.

Allo stesso modo, nella maggior parte degli ambienti in cui verrebbe utilizzato, l'utilizzo della memoria per le autorizzazioni è non un fattore limitante.

I'm also concerned that it'll take longer to check if someone is allowed to do something than bit masking

Ancora una volta, dalla parte della leggibilità e della facilità di manutenzione. Se si fa un buon lavoro di incapsulamento dell'implementazione dei controlli delle autorizzazioni, si sarà in grado di ricondurre più facilmente quella sezione a un approccio diverso quando le circostanze impongono un refactoring è necessario. Detto più chiaramente, i controlli delle autorizzazioni in un ambiente tipico non saranno il tuo fattore vincolante a fini di prestazioni.

In generale, il tuo obiettivo dovrebbe essere quello di portare il progetto a uno stato lavorativo in modo da poter raggiungere gli obiettivi di apprendimento che desideri. E mentre è bene tenere d'occhio queste considerazioni, farlo funzionare è più importante. Dopo aver scritto una suite di test unitaria completa, potrai accedere più facilmente alle sezioni che ti stanno ancora dando fastidio.