Separazione dell'autorizzazione e del database dei ruoli

Question

Separazione dell'autorizzazione e del database dei ruoli

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

0

Qualcosa mi infastidisce molto del modo in cui l'autorizzazione tende a essere eseguita con i ruoli in ASP.NET MVC.

Il modo in cui è normalmente fatto è che hai una tabella utenti e una tabella ruoli. Un utente può avere molti ruoli.

Quindi decori i tuoi controller / azioni con un attributo authorize che dice quali ruoli vuoi consentire l'accesso al controller / azione:

[Authorize(Roles = "Admin")]
public ActionResult AdminOnlyAction()
{
}

Il problema con questo è che il tuo codice dipende dai dati all'interno del database.

Ovviamente, all'avvio dell'applicazione potresti seminare il tuo database con i ruoli necessari se non sono presenti ma c'è ancora una fragile dipendenza dai dati nel database (ad esempio potrebbe essere cancellato, rinominato, ecc. ecc.) .

Avere un enum o qualcosa di simile con i livelli di ruolo in invece di memorizzarli nel database sembra ragionevole, ma mi lascia ancora una sensazione acida.

Esiste un'alternativa elegante alla quale non mi sono imbattuto?

authentication asp.net-mvc mvc separation-of-concerns

posta dav_i 15.08.2014 - 10:33

fonte

2 risposte

Leggi altre domande sui tag authentication asp.net-mvc mvc separation-of-concerns

vendere applicazioni eseguite solo su un server GPL v2 [chiuso] Stato degli articoli selezionati in view o viewmodel?

score 2 · Answer 1

Obviously you could, at application start, seed your database with the roles needed ...

Suggerirei di farlo al momento dell'installazione , non all'avvio dell'applicazione. Probabilmente una connessione "a livello utente" non dovrebbe avere il permesso di fare comunque quel tipo di modifica.

... there's still a fragile dependency on the data in the database ...

Cosa c'è di "fragile" a riguardo? Non è diverso da [praticamente] ogni altra applicazione scritta che usi un database. Se le strutture della tabella non sono impostate nel modo in cui l'applicazione si aspetta, si blocca e si brucia.

Sicuramente il problema importante qui è che le relazioni tra Utenti e Ruoli vivono al di fuori del tuo codice.
I decoratori di accesso che aggiungi al tuo codice sono statici . Contrassegni un metodo come "Solo amministratori" e basta.

L'associazione di un utente con un ruolo è dinamica . Persone diverse avranno ruoli diversi nel tempo ; questo è tutto catturato nel database e il tuo codice non cambia.

score 0 · Answer 2

In primo luogo, se stai assicurando che vengano creati - e non sono d'accordo con Phill W. qui e noti che avere un compito di "assicurare i ruoli" all'avvio è un approccio eccezionale - quindi non sono fragili.

Se gli utenti finali stanno facendo qualcosa di simile alla modifica manuale del database, questo entra in garanzia annullando la manomissione, quindi le cose non funzionanti sono previste nel mio libro.

Infine, puoi creare attributi personalizzati che ti consentono di fare più di Hardcode Role = Admin. Un'app che avevamo legato a Windows aveva uno schema di mappatura personalizzato piuttosto elegante in cui i gruppi interni erano mappati a gruppi NT esterni, quindi gli amministratori non erano bloccati con gruppi specificatamente denominati. Questa app creerebbe anche i propri gruppi NT se lo avessi permesso.