Quali sono gli svantaggi dell'uso / scrittura di un provider di abbonamento personalizzato .Net?

Quindi non sono sicuro che "terribile" sia la parola migliore qui. Tuttavia, presenta dei limiti e non appena le tue esigenze non si adattano al modo in cui è stato progettato il provider di appartenenze, si finisce con un sacco di codice della colla. Se è possibile utilizzare il provider di appartenenza fuori dalla scatola, direi di andare a farlo. Non appena inizi a scrivere un messaggio personalizzato, faccio una domanda usando comunque la roba di iscrizione.

Nella mia esperienza il fornitore di abbonamento ti compra ...

• Iscriviti già integrato per l'app MVC
• Modifica dell'account
• La password dimenticata è facile da collegare
• Convalida il metodo utente

Sono sicuro che ci sia qualcos'altro che mi manca ma penso che quelli siano i più grandi. Ora quando hai bisogno di una gestione personalizzata delle password, l'autenticazione a due fattori, per lavorare con un modello di dati esistente o un'intera serie di altre cose che inizi a perdere. Il codice che è già stato scritto per te con il modulo di iscrizione dovrebbe prendere l'ordine di alcuni giorni per duplicare se sai cosa stai facendo.

Non fa quello che vuoi. A prima vista potresti trovare che si prende cura di tutti i tuoi bisogni e alcuni, ma emerge un nuovo requisito. Ora devi "davvero" imparare come funziona questa cosa. Il vantaggio di avere tutto questo prefabbricato diminuisce perché eri in quel falso senso di sicurezza.

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

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

Non sono flessibili come molti pensano in una lettura veloce dei documenti, ma hanno il loro posto.

Se non hai bisogno di controllo sui token utente e hai solo bisogno di creare dati utente personalizzati o estesi o set di appartenenze o hai bisogno di estrarre quei dati da un'origine esistente / diversa hanno il loro posto.

Se vuoi modificare di più, spesso stai sostituendo il httpmodule che esegue uno dei provider di autenticazione, quindi ottieni tutto il controllo. La maggior parte delle persone con le quali ho avuto problemi di rottura con i provider ha fatto la scelta sbagliata per la loro situazione a questo livello.

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

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

Il fornitore di abbonamento "semplice" di Microsoft ha finalmente ottenuto il risultato giusto a mio modesto parere. Se si sta scrivendo qualcosa di nuovo o addirittura si collega a un database precedente con una nuova applicazione. Utilizza il semplice provider di appartenenze. MODO PIÙ SEMPLICE E PULITORE da implementare. Installa un paio di tabelle e punta il fornitore al tuo elenco di utenti e in pratica sei sostanzialmente.

Questo link ti inizierà o google: link