Fornitore/membro del ruolo? Come in asp.net web api?

Question

Sto creando un'applicazione asp.net mvc web api e non sono sicuro di come fare la roba di iscrizione.

Nel mio progetto attuale ho questo

mia Users Table e Role Table non sto usando l'appartenenza asp.net in quanto porta troppo bagaglio e non si adatta come voglio progettare il mio database (sicuro che posso per ma sembra proprio come a molto lavoro)

un user può avere molti ruoli e un role può avere molti utenti.

Sto utilizzando EF per eseguire quasi tutte le mie chiamate al database.

Nei progetti passati ho creato il mio Authorize Attribute cosa ha fatto la mia chiamata al mio database e controllato per vedere se l'utente aveva il ruolo corretto di ciò che era permesso su quel controller/metodo di azione.

Non facendo alcun abbonamento, ho perso alcune delle funzioni integrate come User.IsInRole. Ero ancora in grado di usare User.Identity.Name ma penso che fosse a causa del cookie che ho impostato.

Qual è il modo migliore per farlo ora in asp.net mvc 4/web api?

Mentre su google ho trovato "SimpleMembership" ma non ho ancora letto molto.

Su una nota a margine posso usare User.Identity.Name con my webapi se ho autenticato un utente?

Answer 1

Ecco uno article that describes how to create a custom authorize attribute for Web API's using SimpleMembership. Non è necessario utilizzare SimpleMembership, sebbene sia molto flessibile e facile da usare. Puoi prendere gli stessi concetti in questo articolo e utilizzare il tuo servizio di abbonamento, purché il tuo servizio possa verificare che un utente specifico abbia un ruolo, registrare un utente in entrata e in uscita e verificare che siano autenticati.

Se il servizio non verifica che siano autenticati, è possibile utilizzare User.Identity.IsAuthenticated ed è possibile utilizzare User.Identity.Name per ottenere il nome utente attualmente connesso; partendo dal presupposto che il servizio imposta correttamente Thread.CurrentPrincipal quando un utente esegue il login. È anche una pratica consigliata impostare HttpContext.Current.User. Ovviamente non devi preoccuparti di nulla se usi SimpleMembership.

Questo attributo di autorizzazione personalizzato supporta sia l'autenticazione di moduli che l'autenticazione di base nel caso in cui esporti le API al pubblico. È diverso da un attributo authorize utilizzato su un controller in quanto restituisce un codice di stato HTTP di Forbidden se non sono autorizzati e Non autorizzati se non sono autenticati; invece di reindirizzare a una pagina di accesso.

Answer 2

È ancora possibile scrivere un provider di appartenenze personalizzato e implementare solo i metodi che si desidera utilizzare. Per quanto riguarda lo User.IsInRole, è possibile scrivere un fornitore di ruoli personalizzato ereditando dalla classe RoleProvider e registrandolo nel proprio web.config.

E se non si desidera utilizzare nessuna di queste funzionalità incorporate, bene, quindi non utilizzarle e invece di scrivere User.IsInRole scrivere MyService.IsInRole. È davvero una questione di preferenze personali se si desidera eseguire il rollover dei provider personalizzati e utilizzare le funzioni integrate o semplicemente scrivere un livello di servizio che gestirà quello per voi. Penso che la scelta dipenda da molti fattori che dovresti prendere in considerazione e che sono legati alle specifiche del tuo progetto. Ad esempio, se in futuro si intende avere altri sviluppatori esterni che lavorano su questo progetto, sarebbe più saggio optare per l'appartenenza personalizzata e i provider di ruoli, poiché è probabile che quegli sviluppatori abbiano più familiarità con questa API piuttosto che dover apprendere la propria abitudine livello di servizio.