Aiutami a decidere se utilizzare provider di appartenenze/ruoli ASP.NET predefiniti o scrivere provider personalizzati

Question

Ho trascorso gran parte della giornata di ieri a leggere sull'argomento e ancora mi sento incerto sulla strada da percorrere. Vengo da uno sfondo "roll your own" quando si tratta di autenticazione e autorizzazione. Non abbiamo mai utilizzato l'autenticazione basata su form, per non parlare dell'API Membership. Guardando il nostro vecchio codice useremmo le variabili di sessione per catturare/controllare se un utente è loggato ecc. Con questo nuovo progetto che sto per intraprendere, voglio rimetterci in pista con quello che dovremmo fare per cominciare, che è usare gli strumenti forniti dal framework.

Ho già uno schema di database con cui lavorerò, tuttavia non è impostato su pietra; Sono in grado di apportare modifiche ad esso, se necessario. In questo schema esiste già una tabella Utenti che utilizza un numero intero come chiave primaria. Questa tabella ha anche altre informazioni come Primo e Ultimo nome. Ho anche chiavi esterne basate sullo UserId su altre tabelle come Telefono e Indirizzo. Di seguito espongo alcuni dei pro/contro che vengono in mente.

provider predefinito

Pro

• meno codice.
• Possibilità di utilizzare tutti i controlli server associati come Login, ChangePassword.

Contro

• Alcuni controlli potrebbero non essere usedful per me fuori dalla scatola. Ad esempio, CreateUserWizard, sarà necessario acquisire altre informazioni durante la creazione dell'utente, ad esempio le informazioni su telefono e indirizzo sulle tabelle associate. Non sono sicuro se questo rende questo controllo inutile per me.
• Dovrò creare chiavi esterne nelle mie tabelle associate (telefono, indirizzo) al UserId che è un GUID nel provider predefinito.
• Se si creano questi vincoli di chiave esterna e non si utilizza l'eliminazione a cascata; Dovrò anche eliminare le righe associate nelle tabelle delle chiavi esterne. Potenzialmente è necessario utilizzare qualcosa come un oggetto TransactionScope per assicurarsi che tutto ciò sia un'operazione atomica.

provider personalizzato

Pro

• capacità di utilizzare le tabelle dello schema esistente.
• Più facile per estendere l'autenticazione/l'autorizzazione in un servizio lungo la linea.

Contro

• devono fornire l'implementazione per la maggior parte/tutto da solo.
• Per utilizzare uno dei controlli, dovrò fornire l'implementazione richiesta nel provider.

Potrebbero esserci altre cose che non ho ancora considerato, essendo che non l'ho mai usato prima, il che mi rende un po 'scomodo.

Grazie.

Answer 1

Recentemente ho dovuto fare la stessa scelta e ho deciso di creare un fornitore personalizzato.

Il mio più grande motivo per fare questo è venuto giù allo schema db predefinito. Tutti gli oggetti db predefiniti vengono creati nello schema dbo e hanno come prefisso "aspnet_" o "vw_aspnet", ecc. Per me è stato un vero e proprio bivio. Se non li hai ancora visti, esegui aspnet_regsql.exe per crearli.

Inoltre, Steven Sanderson dice con Pro ASP.NET MVC 2 quadro:

... SqlProfileProvider utilizza uno schema di database particolarmente disgustoso, in cui le voci del profilo vengono memorizzati come separata da due punti nome/valore coppie, quindi è praticamente impossibile interrogare.

In generale, vale la pena seguire l'API a causa della chiara separazione delle preoccupazioni, del riutilizzo tra i progetti e dell'integrazione con il resto di ASP.NET, ma si desidera utilizzare solo i provider di archiviazione SQL incorporati per le piccole o progetti a perdere.

Non ho ancora completato l'intero processo di creazione dei provider personalizzati (ho eseguito un'implementazione parziale mentre giocavo con lo spazio di archiviazione di Azure Table), ma ho intenzione di utilizzare questi provider su più progetti nel futuro, quindi ritengo che lo sforzo valga la pena.

Answer 2

Personalmente, vorrei andare con ciò che fornisce il quadro. In questo caso non c'è motivo di eseguire la propria autenticazione.

In passato, si potrebbe desiderare di fare le cose da soli, ma al giorno d'oggi non c'è motivo di farlo.

Penso che se si provasse a scrivere da soli, si sarebbe ricreato la ruota e ci sarebbe voluto troppo tempo e risorse per farlo bene. Soprattutto, quando si tratta di sicurezza.

Answer 3

Se si sta costruendo una nuova applicazione, non esiterei a utilizzare il provider predefinito di asp.net. puoi sempre decidere di non utilizzare i controlli predefiniti e crearne di tuoi. puoi anche risparmiare un sacco di tempo utilizzando qualsiasi strumento di gestione utenti pre creato da opensource. Allo stesso tempo puoi sempre estendere le informazioni contenute nelle tabelle predefinite.

Answer 4

Personalmente, utilizzo SqlMembershipProvider come entità autonoma mentre il resto del mio database è in Oracle. Non guardo mai il database, quindi i nomi e GUID non mi infastidiscono (lontano dagli occhi, lontano dalla mente). Funziona appena fuori dalla scatola, il che è fantastico!

Nel mio scenario, ho una tabella utente nel database Oracle che inserisco/elimina quando gli utenti di appartenenza sono creati/cancellati (senza GUID). Considero il database di appartenenza come il record "principale" e la tabella Oracle in modo da trovarvi fondamentalmente per l'integrità referenziale delle tabelle di supporto. Non è davvero fatto in una transazione ufficiale, ma io uso try/catch per tenerli sincronizzati abbastanza bene.

Il fornitore di ruoli è davvero limitato e se si desidera qualsiasi tipo di ruoli gerarchici o dinamici, si viene tostati. Ma è un sistema separato completamente isolato dall'appartenenza e non devi usarlo.

I controlli non sono male. Molti di loro supportano i modelli, in modo da poter aggiungere i propri controlli e avere un sacco di eventi da agganciarvi. Non abbiate paura di eseguire i controlli personalizzati, ma date prima una possibilità ai controlli predefiniti. La facilità d'uso dell'API Membership facilita davvero la creazione di quei controlli.