L'uso dei condizionali di sicurezza in una vista è una violazione di MVC?

10

Spesso ciò che viene visualizzato a un utente (ad es. Su una pagina Web) si basa in parte su controlli di sicurezza. Di solito considero la sicurezza a livello di utente / ACL come parte della logica aziendale di un sistema. Se una vista verifica esplicitamente la sicurezza per visualizzare condizionalmente gli elementi dell'interfaccia utente, sta violando MVC contenendo la logica aziendale?

— Matt S
fonte

Quale sarebbe l'alternativa?

1

Usi ciò che ti dà la migliore sicurezza anche se è considerato un anti-pattern da alcuni.

— zxcdw,

6

Possono esistere due tipi di condizionali di sicurezza, uno sul modello e un altro sulla vista. La vista controlla la visualizzazione degli elementi rilevanti in base alle autorizzazioni dell'utente corrente, ma il modello controlla l'accesso ai dati sottostanti. Finché il modello ha tutte le giuste verifiche / validazioni, anche se la vista è carente, c'è ancora sicurezza.

Di solito devi avere entrambi, poiché la vista deve cambiare per diversi livelli / ruoli. Il controller invia i dati rilevanti che cambieranno la vista, ma la vista deve comunque fare qualcosa con quei dati per nascondere / visualizzare il contenuto all'utente giusto.

Ecco perché la maggior parte dei framework di template ha elementi condizionali ( esempio di manubri ):

{{#if isCurrentUserAdmin}}
    ....
{{/if}

Ciò significa che non è una violazione, a condizione che i pezzi appropriati siano nella posizione corretta.

— knownasilya
fonte

4

Sì e no.

Se la decisione di sicurezza effettiva viene presa dalla vista, allora sì, stai violando MVC. Se, tuttavia, la vista delega la decisione effettiva al modello, allora stai bene. Non c'è nulla di sbagliato in una visione che prende decisioni su quali elementi mostrare, in base alle informazioni del modello.

Ad esempio, se si dispone di un pulsante "modifica" visibile solo agli utenti con autorizzazioni "editor", è consigliabile che la vista chieda al modello chi è l'utente corrente e se dispone dell'autorizzazione "editor", quindi utilizzando queste informazioni per decidere se mostrare il pulsante o meno. Se, tuttavia, la vista dovesse eseguire la stessa logica di autenticazione e autorizzazione, allora violeresti MVC.

— tdammers
fonte

2

Direi di no .

Ma per una ragione diversa da quella di @rvcoutinho (anche se cita Wikipedia che mi fa stare male nel mio pensiero)

Direi che eventuali problemi di sicurezza rilevanti dovrebbero essere condivisi dal Modello dato alla vista (a seconda del numero di combinazioni che potresti voler utilizzare un ViewModel per questo motivo), in quanto potresti avere degli switch per i bit di sicurezza.

Ciò consente la convalida della sicurezza a due livelli: a livello di interfaccia utente in modo da sovvertire un postback per il caso normale, nonché a livello di server per attori difettosi in cui il modello mantiene le conoscenze di sicurezza all'interno di se stesso in modo che il controller distribuisca le informazioni a il modello che lo lancia immediatamente.

La sicurezza a due livelli come questa è lo standard nel settore e in questo modo la tua logica di sicurezza deve esistere solo in due punti, quindi è un vantaggio, non appena inserisci la logica di sicurezza nel controller, la metti lì e nel Interfaccia utente e nel modello (il modello ne ha bisogno in quanto è l'ultima linea di difesa e particolarmente importante per qualsiasi utilizzo al di fuori di tale app Web MVC come un client desktop o qualsiasi strumento di gestione del server)

— Jimmy Hoffa
fonte

L'asserzione di Wikipedia secondo cui "Un controller può inviare comandi alla sua vista associata per cambiare la presentazione della vista del modello" sembra più adatta a Model-View-Presenter , poiché il modello interattivo che la frase sembra descrivere è possibile lì, mentre in MVC, una volta viene visualizzata la vista, non si verificano ulteriori azioni tra la vista e il controller.

— Robert Harvey,

1

@RobertHarvey Concordo sul fatto che l'affermazione non rientra nella mia definizione di MVC, ma fortunatamente noi lavoriamo in un settore in cui la correttezza è decisa da una pluralità di accordi piuttosto che da qualsiasi provabilità perché queste definizioni si muovono come dall'etere con una base in continua evoluzione che consente a tutti di farsi da soli. O in parole più semplici, probabilmente ho torto tanto quanto tutti gli altri qui.

— Jimmy Hoffa,

3

Questo è il motivo per cui penso che le persone siano troppo pedanti per questo genere di cose comunque.

— Robert Harvey,

1

@rvcoutinho Non direi che ero letterale; hai riferimenti dalla tua parte, tutto quello che ho è la mia opinione, quindi nella mia mente ciò significa che probabilmente sbaglio, motivo per cui l'ho menzionato. Penso che la mia opinione sia abbastanza plausibile da valere la pena condividerla anche se non ho riferimenti, quindi l'ho fatto comunque, indipendentemente dal fatto che, come ho detto, probabilmente sbaglio.

— Jimmy Hoffa,

1

@rvcoutinho: In realtà, mi riferivo alla domanda del PO. :) Non c'è niente di sbagliato nelle regole, a meno che le regole non impediscano di fare qualcosa.

— Robert Harvey,

2

Direi di no .

Di solito, questo tipo di controlli di sicurezza verrà eseguito dal controller.

Da Wikipedia :

Un controller può inviare comandi alla vista associata per modificare la presentazione della vista del modello

E non penso che dovrebbe essere fatto direttamente nella vista. Se è fatto tramite javascript, ad esempio, potrebbe essere un problema di sicurezza (si potrebbe disabilitare javascript e accedere ai dati riservati).

Ancora una volta, da Wikipedia :

Una vista richiede dal modello le informazioni necessarie per generare una rappresentazione di output .

— rvcoutinho
fonte

1

In molti sistemi software, la visualizzazione di un elemento dipende dal livello di sicurezza di un utente. Sebbene sia possibile inibire la visualizzazione di un elemento dati impostandolo su zero o null nel Modello vista, il nome o la descrizione dell'elemento dati verranno comunque visualizzati. L'unico punto in cui è possibile inibire la visualizzazione della descrizione dell'elemento dati (in modo pratico) è nella vista.

— Robert Harvey,

Tendo a non essere d'accordo. Direi che la vista richiederebbe i dati, il controller manipolerebbe il modello e la vista lo rappresenterebbe di nuovo. La vista dovrebbe essere responsabile solo per la rappresentazione dell'output.

— rvcoutinho,

Ecco perché la vista deve nascondere quegli elementi visivi che l'utente non deve vedere. Il Titolare non è responsabile della creazione della rappresentazione visiva dei dati; la vista è. Naturalmente, se ciò che si sta visualizzando è così sensibile da non poter essere nemmeno nella vista / sorgente, ciò che il controller deve fare è restituire una vista diversa .

— Robert Harvey,

1

Questo è il mio punto. La vista dovrebbe essere diversa. A quanto ho capito, sembra che la vista dovrebbe occuparsi solo della rappresentazione dei dati. Per rappresentazione, intendo come mostrare qualcosa, non quando mostrarlo. Eppure i tuoi commenti sono totalmente pertinenti.

— rvcoutinho,

Bene, penso che potremmo semplicemente usare la stessa espressione per due cose diverse. Qual è comunque una visione diversa? Ma penso che siamo d'accordo sulla questione più importante: se è sensibile alla sicurezza, non dovrebbe essere gestito dal punto di vista.

— rvcoutinho,

1

Ci sono diversi problemi coinvolti in questa domanda.

L'autenticazione (è questo l'utente che dice di essere) non dovrebbe essere una preoccupazione della vista.
Autorizzazione (è l'utente corrente ha permesso di fare questo ) è una preoccupazione della vista, perché può influenzare ciò che viene presentato all'utente. Pertanto, il codice per visualizzare un pulsante di modifica può essere racchiuso in un condizionale simile if model.userCanEdit() ... endif.
La determinazione di quali attributi di autorizzazione ha un utente, questa è la logica aziendale e deve essere inserita nel Modello. (Ad esempio, il privilegio di "modifica" richiede che tu abbia 2000 reputazione o che devi essere l'autore o un moderatore)

— Bart van Ingen Schenau
fonte

0

Se si tratta solo di visualizzare l'elemento dell'interfaccia utente, penso che sia ok (come altrimenti lo faresti comunque?). Se ci fossero dei dati in quegli elementi, il modello avrebbe dovuto assicurarsi che i contenitori fossero vuoti. E ovviamente il codice per ottenere i dati di autorizzazione avrebbe dovuto essere gestito prima della vista, quindi qui non c'è accesso attivo al modello.

— Thorsten Müller
fonte

0

Se una vista verifica esplicitamente la sicurezza per visualizzare condizionalmente gli elementi dell'interfaccia utente, sta violando MVC contenendo la logica aziendale?

Sì, è una violazione di MVC.

La vista è lì solo per visualizzare gli elementi e la logica dovrebbe essere nel modello. Avendo la vista fare qualcosa (nel tuo caso, controlla la sicurezza), stai inserendo la logica lì.

— BЈовић
fonte

Quindi come può la vista sapere se visualizzare o meno qualcosa come un pulsante di modifica?

— Matt S

@MattS Il relatore chiama una funzione nella vista per mostrare o nascondere quel pulsante (a seconda di uno stato nel modello).

— BЈовић,