Quali sono gli svantaggi dell'utilizzo / scrittura di un provider di appartenenze personalizzato .Net?

Di recente, ho pubblicato la seguente domanda su SO: /programming/7197337/using-asp-net-membership-provider-with-an-existing-user-database

Come puoi notare, ho finito per rispondere alla mia domanda affermando che sembrava che scrivere e implementare un "Provider di abbonamenti personalizzati" fosse la strada da percorrere.

Letteralmente, qualche minuto dopo, mi imbatto in questa domanda: /programming/7222306/simple-login-attempt-counter-using-mvc-3-and-ajax/7222407#7222407

Cerco di rispondere e di ottenere un commento sul fatto che il provider di appartenenze .Net è "terribile su molti livelli". Lo ammetto, questa è la prima volta che utilizzo il provider di appartenenze, ma mi è sembrato perfetto.

Non ho visto nulla che sostenga l'affermazione "terribile", quindi prima di implementare qualcosa di "terribile", speravo di ottenere un feedback dalla comunità.

Quindi non sono sicuro che "terribile" sia la parola migliore qui. Tuttavia, ha dei limiti e non appena le tue esigenze non si adattano al modo in cui il provider di appartenenza è stato progettato, finisci con un sacco di codice colla. Se è possibile utilizzare il provider di appartenenza per impostazione predefinita, direi di provarlo. Non appena inizi a scriverne uno personalizzato, metto in dubbio l'utilizzo delle cose relative all'iscrizione.

Nella mia esperienza il provider di appartenenza ti compra ...

• Iscriviti già integrato per l'app MVC
• Modifica dell'account
• Hai dimenticato la password è facile da collegare
• Convalida del metodo utente

Sono sicuro che manchi qualcos'altro, ma penso che quelli siano quelli grandi. Ora, quando hai bisogno di una gestione personalizzata delle password, di un'autenticazione a due fattori, per lavorare con un modello di dati esistente o per tutta una serie di altre cose, inizi a perdere. Il codice che è già stato scritto per te con l'appartenenza all'iscrizione dovrebbe richiedere alcuni giorni nell'ordine di duplicarsi se sai cosa stai facendo.

Non fa quello che vuoi. A prima vista potresti scoprire che si prende cura di tutte le tue esigenze e di alcune, ma emerge un nuovo requisito. Ora devi "davvero" imparare come funziona questa cosa. Il vantaggio di avere tutto questo precostruito diminuisce perché eri in quel falso senso di sicurezza.

@Travis ha menzionato l'utilizzo di un modello di dati esistente, ma anche la scelta del database può essere una limitazione: Oracle?

Non so se funziona con sistemi di verifica di terze parti come Facebook o Google.

Non sono così flessibili come molte persone pensano a una rapida lettura dei documenti, ma hanno il loro posto.

Se non hai bisogno del controllo sui token utente e devi solo creare un set di dati utente o appartenenza personalizzato / esteso o devi estrarre quei dati da una fonte esistente / diversa, hanno il loro posto.

Se si desidera modificare più di quello, spesso è meglio sostituire il modulo http che esegue uno dei provider di autenticazione, quindi si ottiene tutto il controllo. La maggior parte delle persone con cui ho riscontrato problemi con i fornitori ha fatto la scelta sbagliata per la loro situazione a questo livello.

In entrambi i casi si ottiene un context.user correttamente popolato che consente di continuare a utilizzare la maggior parte delle funzioni utente basate su asp.net.

Questa domanda è vecchia ma ricevo badge per la sua popolarità, quindi immagino che valga la pena fornire una risposta aggiornata.

Il fornitore di abbonamenti "Simple" di Microsoft ha finalmente capito bene a mio modesto parere. Se stai scrivendo qualcosa di nuovo o addirittura ti stai collegando a un database legacy con una nuova applicazione. Usa il semplice provider di appartenenze. MODO PIÙ FACILE e PULITORE da implementare. Installa un paio di tabelle e punta il provider al tuo elenco di utenti e il gioco è fatto.

Questo link ti consentirà di iniziare o semplicemente cercarlo su Google: http://www.mattjcowan.com/funcoding/2012/11/10/simplemembershipprovider-in-mvc4-for-mysql-oracle-and-more-with-llblgen/