Come implementare l'accesso limitato alle funzionalità dell'applicazione

3

Attualmente sto sviluppando un'applicazione web, che fornisce un po ' servizio ' all'utente. L'utente dovrà selezionare un ' piano ' in base al quale a lui / lei sarà permesso di eseguire azioni specifiche dell'applicazione ma fino a un limite definito dal piano.
Un piano limiterà inoltre l'accesso a determinate funzionalità, che non saranno disponibili per alcuni piani.
Come esempio : diciamo che ci sono 3 piani , 2 azioni in tutta l'applicazione

  • gli utenti di plan-1 possono eseguire azioni-1 3 volte e non possono eseguire azione-2 affatto
  • gli utenti di plan-2 possono eseguire azioni-1 10 volte, action-2 5 volte
  • gli utenti di plan-3 possono eseguire azioni-1 20 volte, azione-2 10 volte

Quindi sto cercando il modo migliore per farlo, e le mie preoccupazioni principali oltre a implementarlo sono le seguenti (in nessun ordine particolare)

  • manutenibilità / modificabilità : il numero di piani e il tipo di funzionalità / azioni cambierà nel prodotto finale
  • standard del settore / best practice : per la prontezza futura
  • efficienza : ovviamente, voglio codice veloce !!

Non ho mai fatto nulla di simile prima, quindi non ho nessun indizio su come implementare queste funzionalità. Qualche consiglio / guida / schema / risorse / esempi?
Ho letto un po 'di ACL, RBAC, sono gli schemi che devo seguire?
Davvero, qualsiasi tipo di feedback sarà d'aiuto.

    
posta bool.dev 23.11.2011 - 00:34
fonte

1 risposta

5

Nella mia esperienza personale, questo può davvero trasformarsi in un incubo di manutenzione mentre le cose cambiano: la manutenzione è il problema principale.

Non mi preoccuperei troppo dell'ottimizzazione - lasciatelo per la fine del gioco, poiché il codice per filtrare le caratteristiche non dovrebbe essere più lento di qualsiasi altro codice - non è probabile che diventi un collo di bottiglia.

Per la manutenibilità, ho alcuni suggerimenti:

Costruisci un programma con molti switch.

Mantieni tutte le funzionalità disponibili nel modo più dettagliato possibile, con ciascuna funzionalità che può essere disabilitata singolarmente. È quindi possibile creare i piani come filtri per decidere quali funzionalità sono disabilitate, ma tale logica è separata e posta in primo piano.

Nel programma, dovresti sempre controllare se la funzione è disponibile (semplice sì / no) e MAI se c'è qualche piano particolare disponibile. Quindi, la disponibilità delle funzioni viene determinata in fase di esecuzione da un elenco booleano per l'account corrente e l'elenco viene impostato in un determinato punto in base al piano selezionato, ma il piano e i controlli delle funzionalità non vengono MAI attraversati - ognuno rimane nella propria parte di la lista.

Se possibile, bloccare l'accesso alle funzioni come prima / macro possibile. Ad esempio, se una caratteristica occupa poche righe di codice su un controller / classe, è una sorta di dolore nel calcio da mantenere. Se occupa una "pagina" completa del sito (tuttavia si rompe nella tua architettura) è molto più facile bloccare l'accesso (con privilegi a livello di pagina), o persino accedere a una "sezione" che però si rompe. In questo modo, stai bloccando l'accesso a una parte del sito, piuttosto che mostrare una pagina diversa con funzionalità quasi identiche a utenti diversi, che è meno gestibile.

Prova, se possibile, di nuovo se possibile, per evitare gerarchie di funzionalità, dal momento che non vorrai preoccuparti dell'accesso a funzioni secondarie e cose del genere.

Inoltre, se possibile, cerca di non sovrapporre le tue funzioni. Mantieni le linee tra le feature più nitide possibile, in modo da non districarle più tardi con una disattivata, ma oh, aspetta, abbiamo bisogno di una parte di essa.

Questo non significa che non si possa avere un insieme di funzionalità considerate una singola funzione, ma solo assicurarsi che non si vorrà mai romperla. In caso di dubbi, rendili più funzioni.

    
risposta data 23.11.2011 - 01:42
fonte