Autenticazione ASP.NET MVC tramite database personalizzato anziché ASPNETDB?

Question

Ho già una tabella User nel mio database dell'applicazione principale con un indirizzo email (che fungerà da nome utente) e una password. Mi piacerebbe autenticarmi usando il mio database invece del database di autenticazione predefinito (ASPNETDB).

Domande:

1. questa è una cattiva idea? È un enorme potenziale di worm utilizzare il mio DB per l'autenticazione?

2. Quanto lavoro sto aggiungendo facendo questo? Ho già il codice per hashing della password e una query che controllerà se l'e-mail e la password corrispondono al DB. Quindi, non vorrei iniziare da zero.

3. Cosa dovrei fare per utilizzare il mio database invece di ASPNETDB? Spero che questo possa essere descritto in pochi semplici passaggi, ma in caso contrario, potresti indicarmi una buona fonte?

Aggiornamento

Sono ancora alla ricerca di un po 'più in dettaglio qui sul mio terza questione. Devo scrivere il mio MembershipProvider? Quali modifiche devo apportare al mio file web.config? L'attributo [Authorize] funzionerà ancora se scrivo la mia soluzione? Posso usare l'AccountController generato automaticamente con alcune piccole modifiche o devo sostanzialmente riscrivere il controller dell'account da zero?

Answer 1

È abbastanza semplice, è necessario derrive MembershipProvider e implementare il metodo ValidateUser. Dai un'occhiata a questo post. Sto usando un provider di abbonamento personalizzato con Postgres e MVC.

Answer 2

1. No. E ho il sospetto maggior parte delle persone non si fidano che il meccanismo cruddy

2. Non molto a tutti, soprattutto perché si ha la tabella di già.

3. Date un'occhiata a questo, ad esempio: http://forums.asp.net/t/1250726.aspx

Answer 3

Stiamo facendo esattamente questo in una delle nostre applicazioni, e trovo molto semplice. Abbiamo un servizio di autenticazione (chiamato dal controller) che gestisce i meccanismi di hashing della password inserita per vedere se è una corrispondenza, quindi restituisce semplicemente un bool per un metodo che chiamiamo "IsValidLogon".

Nel nostro caso, lo scopo era quello di mantenere la gestione di quello che dovrebbe essere un compito piuttosto semplice il più leggero possibile.

Abbiamo completamente ignorato ASPNETDB interamente. Se riceviamo una risposta valida dal nostro controllo utente/password, chiamiamo semplicemente lo standard FormsAuthentication.RedirectFromLoginPage (username, createCookieBool);

Spero che questo aiuti.

Answer 4

solo la costruzione dello stesso, in modo da rispondere a 1 non deve essere :) Sto usando l'autenticazione forme asp.net standard, dove io uso il metodo FormsAuthentication.RedirectFromLoginPage (nome utente, createCookieBool) per registrare un utente in. Ho dato a un utente un guid unico (è possibile utilizzare qualsiasi altro ID utente) e lo sto memorizzando nel parametro UserName insieme al nome utente (da visualizzare nella pagina principale: Html.Encode (Page.User.Identity.Name. Split ("|".ToCharArray()) [1]))

In ogni controller/metodo in cui devo sapere quale utente è connesso (tramite User.Identity.Name, dividere la stringa e ottenere l'utente). Anche io decorare quelle routine con l'attributo [Autorizza].

Answer 5

risponderò alle vostre domande aggiornati:

Devo scrivere il mio MembershipProvider?

Se (a) desidera continuare a utilizzare le forme di autenticazione, e (b) hanno una struttura di tabella di autorizzazione che non segue le stesse convenzioni come l'ASPNETDB, allora sì. Se non hai bisogno di FormsAuth (vedi sotto), puoi eliminare completamente lo MembershipProvider, ma non lo consiglierei. Oppure, se si utilizzano le stesse tabelle di sicurezza di ASPNETDB, ma si desidera semplicemente indirizzarlo a un altro database, è possibile continuare a utilizzare il provider predefinito e modificare semplicemente la sua configurazione.

Quali modifiche devo apportare al mio file web.config?

Se si sta utilizzando il proprio personalizzato MembershipProvider, allora avete bisogno di registrarlo nella sezione <providers> dell'elemento <membership> e modificare la proprietà defaultProvider. Se si utilizza lo standard AspNetSqlProvider, probabilmente è sufficiente modificare la stringa di connessione.

L'attributo [Autorizza] funziona ancora se scrivo la mia soluzione?

Sì, se vi limitate a Forms Authentication (utilizzare il AspNetSqlProvider o scrivere e registrare il proprio provider di appartenenza). No, se si abbandona l'autenticazione basata su form (di nuovo, non consigliato).

Posso utilizzare l'accountController generato automaticamente con alcune modifiche minori o devo sostanzialmente riscrivere il controller di account da zero?

È necessario riscrivere lo AccountController in ogni caso: non lasciare codice demo in un'app di produzione. Ma se è necessario - sì, lo AccountController funzionerà alle stesse condizioni di cui sopra.

Answer 6

Ciao, Basta seguire questi semplici passi:

In primo luogo, è possibile eliminare il file mdf nella cartella App_Data. Dal momento che non abbiamo bisogno di nessuno di questi tavoli. Quindi, è necessario aggiornare la stringa di connessione predefinita in web.config in modo che punti al nostro database.

<connectionStrings> 
    <add name=”DefaultConnection” connectionString=”Data Source=SERVER\INSTANCENAME;Initial Catalog=DBNAME;Integrated Security=True” providerName=”System.Data.SqlClient” /> 
    </connectionStrings> 

Terzo, Open Nuget Package Manager e scrivere i seguenti comandi:

Enable-Migrations 
Add-Migration Init 
Update-Database 

Scopri il database, tutte le tabelle di appartenenza ASP.NET con prefisso Asp sono stati creare e quindi è possibile verificare fuori eseguendo la tua applicazione ed esegui azioni di adesione come la registrazione o l'accesso alla tua applicazione.

tabelle create dopo l'esecuzione sopra comandi:

• AspNetRoles
• AspNetUserClaims
• AspNetUserLogins
• AspNetUserRoles
• AspNetUsers
• __MigrationHistory

Fonte: https://blogs.msmvps.com/marafa/2014/06/13/how-to-create-asp-net-mvc-authentication-tables-in-an-existing-database/