Pattern MVP: modi per limitare l'azione dell'utente in base ai privilegi di sicurezza

Question

Pattern MVP: modi per limitare l'azione dell'utente in base ai privilegi di sicurezza

#1 da (1 voti)

0

In un'applicazione MVP, quale dovrebbe essere il modo più appropriato per implementare la restrizione ad alcune azioni dell'interfaccia utente in base ai privilegi dell'utente corrente?

Ad esempio, in una sicurezza basata sui ruoli, diversi ruoli avranno un accesso diverso ad alcune interazioni dell'interfaccia utente nella stessa vista. Se, ad esempio, disponiamo di un negozio online, nella pagina dell'elenco dei prodotti i clienti possono solo visualizzare i dettagli e aggiungere articoli al loro carrello, ma un amministratore deve essere presentato anche con i pulsanti Add Product e Delete su ciascun elemento .

Domande simili sono già state poste qui ma l'OP chiede che l'interfaccia utente effettui i controlli di autorizzazione. Sono certo che l'interfaccia utente (view) non dovrebbe essere responsabile della convalida del permesso, ma deve ancora sapere se visualizzare o meno determinati componenti dell'interfaccia utente. Quindi, c'è un modello ben definito o ampiamente adottato per dire alla vista quali interazioni UI dovrebbe non consentire? Posso pensare ad alcune soluzioni, ma se esiste una versione standard e comprovata, preferirei seguirla piuttosto che reinventare la ruota.

Aggiorna

Per chiarire un po 'di più, come suggerito nelle risposte di seguito, sto considerando l'approccio di avere la vista di accettare le informazioni sui privilegi dal presentatore. È la forma di quell'informazione che mi infastidisce: se uso flag come bit mask o qualche rappresentazione troppo generica, io lo farò:

(+) Ottieni coerenza nel passaggio delle autorizzazioni alla vista
(-) Accoppia la vista con la logica per risolvere i flag.

L'altra cosa che ho in mente è che la Vista esponga tutte le bandiere di cui ha bisogno come proprietà modificabili per il presentatore (come view.IsDeleteItemAllowed ). Quindi lo farò:

(+) Non ha una logica aggiuntiva per le autorizzazioni nella vista
(-) Aggiungi complessità aggiuntiva al relatore per adattare i flag di autorizzazione alle proprietà della vista.

Quindi, sto pensando di utilizzare l'approccio successivo, perché in questo modo posso riutilizzare il presentatore con diverse implementazioni di visualizzazione; e non si baserà sulla vista per capire il sistema di permessi (che può essere soggetto di cambiamenti). C'è qualcosa di cui dovrei preoccuparmi?

security mvp

posta Ivaylo Slavov 18.04.2013 - 11:03

fonte

1 risposta

Leggi altre domande sui tag security mvp

È 'sicuro' aspettarsi che myClasses accetti di non chiamare solo i metodi del pacchetto scope da altri metodi di scope del pacchetto? Forzatura degli aggiornamenti dell'applicazione ExtJS dopo la distribuzione

score 1 · Accepted Answer

Non penso che ci sia uno schema specifico per questo. Ci sono due ovvie soluzioni a questo:

Il Presenter fornisce flag / un valore alla vista che indica il livello di privilegio dell'utente corrente.
La vista richiede l'oggetto Modello CurrentUser per il suo livello di privilegio / se ha il privilegio X.

Quale di questi due usi dovrebbe dipendere in gran parte dalla quantità di interazione consentita tra la vista e il modello (ad esempio la vista può chiedere informazioni al modello o deve essere fornita dal relatore).

Se utilizzare i flag o un singolo valore dovrebbe dipendere dal design del sistema dei privilegi. Per una serie di privilegi che possono essere concessi o negati in modo indipendente, una serie di flag sarebbe molto utile. Per i livelli crescenti, dove il livello X + 1 può fare tutto del livello X più un po 'di più, vorrei andare per un singolo valore.

Aggiorna

Se il tuo sistema di autorizzazione è soggetto a modifiche, il modo migliore per mantenere tali modifiche fuori dalla vista è di dare alla View il proprio sistema di autorizzazione basato su flag a grana fine ( isInsertionAllowed , isDeletionAllowed , ecc.) e lascia che Presenter esegua la mappatura tra i due sistemi di autorizzazione.

Ciò che dovresti fare attenzione con l'utilizzo delle singole proprietà è che, se una vista richiede una proprietà aggiuntiva dopo una modifica, anche il relatore per quella vista deve essere aggiornato.

Si noti inoltre che quando parlo di flag, questo può essere implementato sia come bit-flags, sia come proprietà / argomenti booleani. Questo non fa davvero la differenza per il design.