Cosa si intende per "Un utente non dovrebbe decidere se si tratta di un amministratore o meno. I privilegi o il sistema di sicurezza dovrebbero. "

L'esempio utilizzato nella domanda passa dati minimi nudi a una funzione che tocca il modo migliore per determinare se l'utente è un amministratore o meno. Una risposta comune è stata:

user.isAdmin()

Ciò ha provocato un commento che è stato ripetuto più volte e votato più volte:

Un utente non dovrebbe decidere se si tratta di un amministratore o meno. I privilegi o il sistema di sicurezza dovrebbero. Qualcosa che è strettamente accoppiato a una classe non significa che sia una buona idea farne parte.

Ho risposto,

L'utente non sta decidendo nulla. L'oggetto / tabella utente memorizza i dati relativi a ciascun utente. Gli utenti reali non possono cambiare tutto di se stessi.

Ma questo non è stato produttivo. Chiaramente c'è una differenza di prospettiva che sta rendendo difficile la comunicazione. Qualcuno può spiegarmi perché user.isAdmin () è male e dipingere un breve schizzo di come sembra fatto "giusto"?

Davvero, non vedo il vantaggio di separare la sicurezza dal sistema che protegge. Qualsiasi testo di sicurezza dirà che la sicurezza deve essere progettata in un sistema fin dall'inizio e considerata in ogni fase dello sviluppo, implementazione, manutenzione e persino del fine vita. Non è qualcosa che può essere imbullonato sul lato. Ma finora 17 voti positivi su questo commento dicono che mi manca qualcosa di importante.

Pensa all'utente come chiave e alle autorizzazioni come valore.

Contesti diversi potrebbero avere autorizzazioni diverse per ciascun utente. Poiché le autorizzazioni sono pertinenti al contesto, è necessario modificare l'utente per ciascun contesto. Quindi è meglio che metti quella logica altrove (ad esempio la classe di contesto) e cerchi le autorizzazioni dove necessario.

Un effetto collaterale è che potrebbe rendere il tuo sistema più sicuro, perché non puoi dimenticare di cancellare il flag di amministrazione per i luoghi in cui non è rilevante.

Quel commento era formulato male.

Il punto non è se l'oggetto utente "decide" se si tratta di un amministratore, un utente di prova, un superutente o qualcosa dentro o fuori dall'ordinario. Ovviamente non decide nessuna di queste cose, il sistema software in generale, come implementato da te, lo fa. Il punto è se la classe "utente" deve rappresentare i ruoli dell'entità rappresentata dai suoi oggetti o se questa è una responsabilità di un'altra classe.

Non avrei scelto di pronunciare il commento originale nel modo in cui è stato formulato, ma identifica un problema potenzialmente legittimo.

In particolare, le preoccupazioni che giustificano la separazione sono l' autenticazione e l' autorizzazione .

L'autenticazione si riferisce al processo di accesso e acquisizione di un'identità. È come i sistemi sanno chi sei e usato per cose come la personalizzazione, la proprietà degli oggetti, ecc.

L'autorizzazione si riferisce a ciò che ti è permesso fare e questo (generalmente) non è determinato da chi sei . Invece, è determinato da alcune politiche di sicurezza come ruoli o autorizzazioni, a cui non interessano cose come il tuo nome o indirizzo email.

Questi due possono cambiare ortogonalmente tra loro. Ad esempio, è possibile modificare il modello di autenticazione aggiungendo provider OpenID / OpenAuth. E potresti cambiare la politica di sicurezza aggiungendo un nuovo ruolo o passando da RBAC ad ABAC.

Se tutto ciò rientra in una classe o astrazione, il tuo codice di sicurezza, che è uno dei tuoi strumenti più importanti per la mitigazione del rischio , diventa, ironicamente, ad alto rischio.

Ho lavorato con sistemi in cui l'autenticazione e l'autorizzazione erano troppo strettamente accoppiate. In un sistema c'erano due database utente paralleli, ciascuno per un tipo di "ruolo". La persona o il team che lo ha progettato apparentemente non ha mai considerato che un singolo utente fisico potesse essere in entrambi i ruoli o che potrebbero esserci determinate azioni comuni a più ruoli o che potrebbero esserci problemi con le collisioni dell'ID utente. Questo è certamente un esempio estremo, ma è stato / è incredibilmente doloroso lavorare con.

Microsoft e Sun / Oracle (Java) si riferiscono all'aggregato delle informazioni di autenticazione e autorizzazione come Responsabile della sicurezza . Non è perfetto, ma funziona abbastanza bene. In .NET, ad esempio, hai IPrincipal, che incapsula il IIdentityprimo essendo un oggetto policy (autorizzazione) mentre il secondo è un'identità (autenticazione). Potresti ragionevolmente mettere in dubbio la decisione di metterne uno dentro l'altro, ma la cosa importante è che la maggior parte del codice che scrivi sarà solo per una delle astrazioni, il che significa che è facile testare e refactoring.

Non c'è niente di sbagliato in un User.IsAdmincampo ... a meno che non ci sia anche un User.Namecampo. Ciò indicherebbe che il concetto di "Utente" non è definito correttamente e questo è, purtroppo, un errore molto comune tra gli sviluppatori che sono un po 'bagnati dietro le orecchie quando si tratta di sicurezza. In genere, l'unica cosa che dovrebbe essere condivisa dall'identità e dalla politica è l'ID utente, che, non a caso, è esattamente come viene implementato nei modelli di sicurezza Windows e * nix.

È completamente accettabile creare oggetti wrapper che incapsulino identità e criteri. Ad esempio, faciliterebbe la creazione di una schermata del dashboard in cui è necessario visualizzare un messaggio "ciao" oltre a vari widget o collegamenti a cui l'utente corrente può accedere. Fintanto che questo wrapper avvolge solo le informazioni sull'identità e sulla politica e non pretende di possederlo. In altre parole, purché non sia presentato come radice aggregata .

Un modello di sicurezza semplicistico sembra sempre una buona idea quando si progetta per la prima volta una nuova applicazione, a causa di YAGNI e tutto il resto, ma quasi sempre finisce per tornare a morderti più tardi, perché, sorpresa sorpresa, vengono aggiunte nuove funzionalità!

Quindi, se sai cosa è meglio per te, manterrai le informazioni di autenticazione e autorizzazione separate. Anche se "l'autorizzazione" in questo momento è semplice come un flag "IsAdmin", starai comunque meglio se non fa parte della stessa classe o tabella delle informazioni di autenticazione, quindi se e quando la tua politica di sicurezza deve cambiare, non è necessario eseguire interventi di chirurgia ricostruttiva sui sistemi di autenticazione che funzionano già bene.

Beh, almeno viola il principio della singola responsabilità . Dovrebbero esserci cambiamenti (livelli amministrativi multipli, ruoli ancora più diversi?) Questo tipo di design sarebbe abbastanza disordinato e terribile da mantenere.

Considerare il vantaggio di separare il sistema di sicurezza dalla classe utente, in modo che entrambi possano avere un ruolo unico e ben definito. Si finisce con un design più pulito, più facile da mantenere nel complesso.

Penso che il problema, forse formulato male, sia che dà troppo peso alla Userclasse. No, non esiste alcun problema di sicurezza nell'avere un metodo User.isAdmin(), come è stato suggerito in questi commenti. Dopotutto, se qualcuno è abbastanza in profondità nel tuo codice per iniettare codice dannoso per una delle tue classi principali, hai seri problemi. D'altra parte, non ha senso Userdecidere se si tratta di un amministratore per ogni contesto. Immagina di aggiungere ruoli diversi: moderatori per il tuo forum, redattori che possono pubblicare post sulla prima pagina, scrittori che possono scrivere contenuti che gli editori possano pubblicare, e così via. Con l'approccio di metterlo Usersull'oggetto, finirai con troppi metodi e troppa logica che vivono su Userciò che non è direttamente correlato alla classe.

Invece, è possibile utilizzare un enum di diversi tipi di autorizzazioni e una PermissionsManagerclasse. Forse potresti avere un metodo come PermissionsManager.userHasPermission(User, Permission), restituire un valore booleano. In pratica, potrebbe apparire come (in Java):

if (!PermissionsManager.userHasPermission(user, Permissions.EDITOR)) {
  Site.renderSecurityRejectionPage();
}

È essenzialmente equivalente al metodo del before_filtermetodo Rails , che fornisce un esempio di questo tipo di controllo delle autorizzazioni nel mondo reale.

Object.isX () viene utilizzato per rappresentare una chiara relazione tra l'oggetto e X, che può essere espressa come risultato booleano, ad esempio:

Water.isBoiling ()

Circuit.isOpen ()

User.isAdmin () assume un unico significato di "Amministratore" in ogni contesto del sistema , che un utente è, in ogni parte del sistema, un amministratore.

Anche se sembra abbastanza semplice, un programma del mondo reale non si adatterà quasi mai a questo modello, ci sarà sicuramente un requisito per un utente di amministrare risorse [X] ma non [Y], o per tipi più distinti di amministratori (un [progetto ] amministratore vs un amministratore di [sistema]).

Questa situazione di solito richiede un'indagine sui requisiti. Raramente, se mai, un cliente vorrà la relazione che User.isAdmin () rappresenta effettivamente, quindi esiterei a implementare tale soluzione senza chiarimenti.

Il poster aveva semplicemente in mente un design diverso e più complicato. Secondo me User.isAdmin()va bene . Anche se in seguito introduci qualche complicato modello di autorizzazioni, vedo poche ragioni per spostarmi User.isAdmin(). Successivamente, potresti voler dividere la classe User in un oggetto che rappresenta un utente connesso e un oggetto statico che rappresenta i dati sull'utente. Oppure no. Risparmia domani per domani.

Non è davvero un problema ...

Non vedo problemi con User.isAdmin(). Lo preferisco sicuramente a qualcosa del genere PermissionManager.userHasPermission(user, permissions.ADMIN), che nel santo nome di SRP rende il codice meno chiaro e non aggiunge nulla di valore.

Penso che SRP venga interpretato un po 'alla lettera da alcuni. Penso che vada bene, anche preferibile che una classe abbia un'interfaccia ricca. SRP significa solo che un oggetto deve delegare ai collaboratori tutto ciò che non rientra nella sua unica responsabilità. Se il ruolo di amministratore di un utente è qualcosa di più coinvolto di un campo booleano, potrebbe avere molto senso che l'oggetto utente deleghi a un PermissionsManager. Ma ciò non significa che non sia anche una buona idea per un utente mantenere il suo isAdminmetodo. In realtà significa che quando l'applicazione passa da semplice a complessa, è necessario modificare il codice che utilizza l'oggetto Utente. IOW, il tuo client non ha bisogno di sapere cosa serve veramente per rispondere alla domanda se un utente è o meno un amministratore.

... ma perché vuoi davvero saperlo?

Detto questo, mi sembra che raramente hai bisogno di sapere se un utente è un amministratore se non per essere in grado di rispondere ad altre domande, ad esempio se a un utente è permesso o meno di eseguire un'azione specifica, ad esempio aggiornando un widget. In tal caso, preferirei avere un metodo su Widget, come isUpdatableBy(User user):

boolean isUpdatableBy(User user) {
    return user.isAdmin();
}

In questo modo un Widget è responsabile di sapere quali criteri devono essere soddisfatti per essere aggiornato da un utente e un utente è responsabile di sapere se si tratta di un amministratore. Questo design comunica chiaramente le sue intenzioni e semplifica il passaggio a logiche aziendali più complesse se e quando arriverà quel momento.

[Modificare]

Il problema di non avere User.isAdmin()e utilizzarePermissionManager.userHasPermission(...)

Ho pensato di aggiungere alla mia risposta per spiegare perché preferisco di gran lunga chiamare un metodo sull'oggetto Utente piuttosto che chiamare un metodo su un oggetto PermissionManager se voglio sapere se un utente è un amministratore (o ha un ruolo di amministratore).

Penso che sia giusto presumere che dipenderai sempre dalla classe User ovunque tu debba porre la domanda : questo utente è un amministratore? Questa è una dipendenza di cui non puoi liberarti. Ma se è necessario passare l'utente a un altro oggetto per porre una domanda al riguardo, ciò crea una nuova dipendenza da quell'oggetto in aggiunta a quella che si ha già sull'Utente. Se la domanda viene posta molto, sono molti i luoghi in cui crei una dipendenza aggiuntiva, ed è un sacco di posti che potresti dover cambiare se una delle dipendenze lo richiede.

Confrontalo con lo spostamento della dipendenza nella classe User. Ora, improvvisamente hai un sistema in cui il codice client (codice che deve porre la domanda è questo utente un amministratore ) non è accoppiato all'implementazione di come questa domanda riceve risposta. Sei libero di cambiare completamente il sistema di autorizzazione e devi solo aggiornare un metodo in una classe per farlo. Tutto il codice client rimane lo stesso.

Insistere sul non avere un isAdminmetodo sull'Utente per paura di creare una dipendenza nella classe Utente dal sottosistema delle autorizzazioni, è secondo me simile a spendere un dollaro per guadagnare un centesimo. Certo, eviti una dipendenza nella classe Utente, ma a costo di crearne una in ogni luogo in cui è necessario porre la domanda. Non è un buon affare.

Questa discussione mi ha ricordato un post sul blog di Eric Lippert, che è stato portato alla mia attenzione in una discussione simile su design di classe, sicurezza e correttezza.

Perché vengono sigillate così tante classi quadro?

In particolare, Eric solleva il punto:

4) Sicuro. il punto centrale del polimorfismo è che puoi passare intorno a oggetti che sembrano animali ma in realtà sono giraffe. Ci sono potenziali problemi di sicurezza qui.

Ogni volta che si implementa un metodo che accetta un'istanza di un tipo non sigillato, È NECESSARIO scrivere quel metodo per essere robusto di fronte a istanze potenzialmente ostili di quel tipo. Non puoi fare affidamento su eventuali invarianti che sai essere veri per le TUE implementazioni, perché alcune pagine web ostili potrebbero sottoclassare la tua implementazione, sovrascrivere i metodi virtuali per fare cose che incasinano la tua logica e la passano. Ogni volta che sigillo una classe , Posso scrivere metodi che usano quella classe con la certezza di sapere cosa fa quella classe.

Questo può sembrare tangente, ma penso che sia in linea con il punto sollevato da altri poster sul principio della responsabilità singola SOLID . Considera la seguente classe dannosa come motivo per non implementare un metodo o una proprietà.User.IsAdmin

public class MyUser : User
{

    public new boolean IsAdmin()
    {
        // You know it!
        return true;
    }

    // Anything else we can break today?

}

Certo, è un po 'allungato: nessuno ha ancora suggerito di creare IsAmdminun metodo virtuale, ma potrebbe accadere se la tua architettura utente / ruolo finisse per essere stranamente complessa. (O forse no. Considera public class Admin : User { ... }: una classe del genere potrebbe contenere esattamente quel codice sopra.) L'inserimento di un binario dannoso non è un vettore di attacco comune e ha molto più potenziale per il caos di una oscura libreria di utenti - poi di nuovo, questo potrebbe essere il bug di escalation di privilegi che apre le porte ai veri shenanigans. Infine, se un'istanza binaria o oggetto dannosa si è fatta strada nel tempo di esecuzione, non è molto più lungo immaginare che il "Privilege or Security System" venga sostituito in modo simile.

Ma tenendo a cuore il punto di vista di Eric, se metti il ​​tuo codice utente in un particolare tipo di sistema vulnerabile, forse hai perso il gioco.

Oh, e solo per essere precisi per la cronaca, sono d'accordo con il postulato nella domanda: “Un utente non dovrebbe decidere se si tratta di un amministratore o meno. I privilegi o il sistema di sicurezza dovrebbero. ”Un User.IsAdminmetodo è una cattiva idea se si esegue il codice sul sistema in modo da non mantenere il controllo del codice al 100% - è necessario invece Permissions.IsAdmin(User user).

Il problema qui è:

if (user.isAdmin()) {
   doPriviledgedOp();
} else {
   // maybe we can anyway!
   doPriviledgedOp();
}

O hai impostato correttamente la tua sicurezza, nel qual caso il metodo privilegiato dovrebbe verificare se il chiamante ha autorità sufficiente, nel qual caso il controllo è superfluo. Oppure non hai e ti fidi di una classe non privilegiata per prendere le proprie decisioni in materia di sicurezza.