Esiste un modo migliore di gestire la logica di controllo degli accessi invece che nell'interfaccia utente?

Question

Esiste un modo migliore di gestire la logica di controllo degli accessi invece che nell'interfaccia utente?

#1 da (5 voti)
#2 da (2 voti)
#3 da (0 voti)

5

Attraverso la maggior parte della mia esperienza di sviluppo, non ho mai dovuto gestire una grande varietà di architetture per il controllo degli accessi.

Sono stati tutti molto semplici:

Group [Create, Update, Delete]
    - User 1
    - User 2

Group [Update, Delete]
    - User 2

Che, a tutti gli effetti, funziona bene. Il problema che ho è la sua effettiva implementazione. Tutte le soluzioni su cui ho lavorato garantiscono / negano la visibilità di un collegamento a un menu, o disabilitano un pulsante, ecc. Tutto questo è controllato dal livello più in alto dell'app, che sia un'interfaccia WebApp o WinForms.

Sono nelle prime fasi della progettazione di un sistema WinForms piuttosto grande, quindi mi piacerebbe avere l'architettura di sicurezza fin dall'inizio.

Sebbene non mi veda allontanarsi dal limitare visivamente l'utente dall'eseguire alcune azioni (disabilitando i controlli ristretti ecc.), sono sicuro che ci sono soluzioni migliori disponibili che svolgono gran parte del lavoro nell'interfaccia utente.

A quanto ho capito (e questi potrebbero essere limitati dalla mia ignoranza), queste sono le mie opzioni:

Inserisci la logica per restituire e verificare i diritti utente nel livello aziendale
Nell'evento form_load, ottieni queste regole e attiva / disattiva gli elementi dell'interfaccia utente
Lascia intatti gli elementi dell'interfaccia utente e interrompi l'operazione dal livello aziendale se l'utente non dispone dell'autorizzazione per l'azione (dirty!)

Sicuramente ci devono essere soluzioni più eleganti di questo. Qualcuno potrebbe fornirmi alternative o miglioramenti alle idee di cui sopra?

Ci sto pensando in modo errato? Devo rivalutare il mio design del database mentre ci sono?

c# architecture security database-design winforms

posta Daniel Minnaar 13.05.2013 - 22:09

fonte

3 risposte

2

Ciò che hai descritto è praticamente ciò che dovrai utilizzare. (Scusa)

Considerare il trattamento di ciascuna sezione principale dell'interfaccia utente come moduli / moduli separati. Quindi disponi di un modulo padre che può essere utilizzato per controllare se determinati moduli secondari verranno caricati in base alla tua logica aziendale.

Ciò consentirebbe di mantenere la logica di controllo degli accessi all'interno dei livelli della logica aziendale e basarsi solo minimamente su code-behind. Questo livello di controllo dell'autorizzazione potrebbe essere limitato allo spettacolo a grana grossa | disabilita | decisioni sul tipo "no-show".

Poiché l'app Winform verrà eseguita su un sistema esterno al tuo controllo, dovrai disporre di ulteriori gradi di verifica all'interno della logica aziendale che fornisce un'interfaccia al livello del database. Qui è dove si applicano controlli di autorizzazione a grana più fine.

Infine, considera di usare WPF invece di Winforms, se puoi. WPF è meglio strutturato per facilitare il modello di presentazione prescelto (MVC, MVVM, MVP, ecc.) Rispetto a quanto offerto in modo nativo da winform. Puoi ancora scrivere un'app sicura con winforms, ci vuole solo un po 'più impegno.

risposta data 14.05.2013 - 00:25

fonte

0

Penso che tu stia cercando il modello Model View Controller , o qualche leggera variazione di esso. Per quanto riguarda la sicurezza, ci sono ulteriori informazioni qui: link

risposta data 13.05.2013 - 22:21

fonte

Leggi altre domande sui tag c# architecture security database-design winforms

Revocabile BSD - Quali sono le implicazioni? Gestione di un repository SVN sotto copertura

score 5 · Accepted Answer

WPF incoraggia vivamente l'uso del pattern Command, che incapsula la logica per una determinata pressione pulsante o voce di menu in un oggetto ICommand , anziché come gestore di eventi code-behind. La parte interessante di questi oggetti è che, oltre al metodo standard Execute , ha anche un metodo standard CanExecute , che determina se il pulsante è abilitato o meno. Questo metodo può essere utilizzato sia dalla logica di convalida che dal livello delle autorizzazioni per determinare se l'elemento UI è attivo.

Ciò consente alla logica dell'autorizzazione di essere "lato server", come parte della logica aziendale, e di avere visibilità, "abilitazione" e funzionalità ad esso associate tramite l'associazione dati, piuttosto che passare manualmente sopra Elementi dell'interfaccia utente e attivazione / disattivazione di essi.

Questo si adatta alla filosofia generale di WPF di utilizzare lo schema MVVM, utilizzando i collegamenti dati tra l'interfaccia utente e i modelli di visualizzazione back-end per nascondere tutto ciò che è brutto "controlla il livello di autorizzazione e imposta la proprietà del pulsante di conseguenza".