La logica di accesso dovrebbe andare nei controller?

5

Voglio sapere se tutta la logica relativa alle autorizzazioni e al controllo di accesso appartiene ai controller (logica dell'applicazione) o ai modelli (logica aziendale).

Attualmente ho un controller che fa qualcosa del genere:

function delete (resource) {
   if (resource.belongsTo (currentUser) {
       resource.delete ();
   }
   else {
       throw Exception ("you can't do this");
   }
}

Questo tipo di logica di applicazione logica o logica aziendale?

PS. Ho già letto dove mettere la logica di business in MVC design? , ma ho ancora dubbi

    
posta IAmJulianAcosta 11.11.2014 - 02:51
fonte

3 risposte

8

È perfettamente accettabile mettere la logica di sicurezza / permessi nel metodo del controllore.

Lo scopo del metodo controller è di coordinare le chiamate di servizio al livello di servizio o al livello o al repository della logica aziendale. Tecnicamente, la sicurezza è una preoccupazione ortogonale, ma molto importante per i metodi della logica aziendale. È ortogonale perché essenzialmente si riduce a una "porta" che è necessario attraversare: o il metodo della logica di business risultante viene eseguito, oppure no. Ma la stessa logica essenziale non cambia: supponendo che tu abbia i permessi, il risultato sarà sempre lo stesso.

La funzione di autorizzazione può essere fornita da un'altra libreria o servizio, ma ciò sottolinea ulteriormente il ruolo del metodo di controllo come coordinatore, poiché ora il metodo di controllo non fornirà nemmeno funzionalità di sicurezza (lo rimanderà a qualche altro meccanismo).

    
risposta data 11.11.2014 - 07:42
fonte
2

È utile distinguere tra due tipi di controllo degli accessi:

  • Verticale : funzioni a cui alcuni utenti possono accedere e alcuni utenti non possono. Ad esempio, chiunque può visualizzare la home page, ma solo l'amministratore può vietare un utente.
  • Orizzali : funzioni a cui possono accedere più utenti, ma i dati sono separati. Ad esempio, tutti possono accedere alla "Posta in arrivo", ma vedono solo i propri messaggi, non quelli di altre persone.

Il controllo dell'accesso verticale è quasi sempre applicato al livello controller.

La maggior parte delle applicazioni applica anche il controllo di accesso orizzontale a livello di controller. Funziona, ma c'è uno svantaggio: i controlli di accesso devono essere ripetuti in più punti, il che invita a commettere errori. Le applicazioni complesse richiedono molti controlli per applicare correttamente il controllo di accesso orizzontale.

Ma c'è un'alternativa: eseguire il controllo di accesso orizzontale nel modello. Questo tende a ridurre il numero di controlli necessari - ad es. hai un controllo del controllo accessi sull'oggetto Email, piuttosto che 15 controlli separati nei metodi del controllore che accedono all'oggetto. Una critica a questo approccio è che richiede che il modello sia consapevole dell'identità, il che potrebbe essere un accoppiamento indesiderato tra modello e controllore. Tuttavia, penso che ne valga la pena. Ho scritto più su questo argomento sul mio sito web.

    
risposta data 27.11.2014 - 22:31
fonte
1

Pratica assolutamente fantastica. Provare anche ad avere una sorta di controller di base che abbia tutti gli altri controller ad esso estesi per evitare controlli di controllo degli accessi ripetitivi. Diciamo che voglio limitare le persone a visitare il controller del profilo, posso avere un controllore genitore chiamato utente e, nel costruttore, farei un controllo per vedere se l'utente ha accesso altrimenti reindirizzerò. se decidi di sviluppare con java, dovresti probabilmente provare la sicurezza di primavera ( link ) che è fantastico ed elimina la necessità di lottare per i controlli di accesso dai controller.

    
risposta data 11.11.2014 - 16:20
fonte

Leggi altre domande sui tag