Каковы недостатки использования / написания .Net Custom Membership Provider?

Недавно я разместил следующий вопрос на SO: /programming/7197337/using-asp-net-membership-provider-with-an-existing-user-database

Как вы можете заметить, я в конечном итоге ответил на свой собственный вопрос, заявив, что было похоже, что написать / внедрить «Провайдера нестандартного членства» - это путь.

Буквально через несколько минут я наткнулся на этот вопрос: /programming/7222306/simple-login-attempt-counter-using-mvc-3-and-ajax/7222407#7222407

Я пытаюсь ответить и получить комментарий, что поставщик членства .Net "ужасен на многих уровнях". Я признаю, это первый раз, когда я использую членство провайдера, но это выглядело гладко для меня.

Я не видел ничего, что подкрепляло бы «ужасное» утверждение, поэтому, прежде чем реализовать что-то «ужасное», я надеялся получить отзывы сообщества.

Так что я не уверен, что слово «ужасный» здесь самое лучшее. Тем не менее, у него есть ограничения, и как только ваши потребности не соответствуют тому, как был разработан поставщик членства, вы получите много склеивающего кода. Если вы можете использовать поставщика членства из коробки, я бы сказал, пойти на это. Как только вы начинаете писать свой собственный вопрос, я все равно задаю вопрос об использовании членства.

По моему опыту провайдер членства покупает вас ...

• Регистрация уже встроена в приложение MVC
• Редактирование аккаунта
• Забыли пароль легко подключить
• Подтвердить метод пользователя

Я уверен, что что-то еще мне не хватает, но я думаю, что это большие. Теперь, когда вам нужно настраиваемое управление паролями, двухфакторная аутентификация для работы с существующей моделью данных или целый ряд других вещей, вы начинаете терять. Код, который уже написан для вас вместе с предоставлением членства, должен дублироваться в течение нескольких дней, если вы знаете, что делаете.

Это не делает то, что вы хотите. На первый взгляд вы можете обнаружить, что он отвечает всем вашим потребностям и некоторым, но возникает новое требование. Теперь вы «действительно» должны узнать, как это работает. Выгода от того, что все это готово, уменьшается, потому что вы были в этом ложном чувстве безопасности.

@ Travis упомянул использование существующей модели данных, но выбор базы данных также может быть ограничением: Oracle?

Я не знаю, работает ли он со сторонними системами проверки, такими как Facebook или Google.

Они не так гибки, как думают многие, быстро читая документы, но у них есть свое место.

Если вам не нужен контроль над пользовательскими токенами, и вам нужно только создать пользовательские / расширенные пользовательские данные или набор участников, или вам нужно извлечь эти данные из существующего / другого источника, у них есть свое место.

Если вы хотите изменить что-то большее, вам лучше заменить модуль http, который запускает один из провайдеров аутентификации, тогда вы получите полный контроль. Большинство людей, с которыми я сталкивался, ломая отношения с поставщиками, сделали неправильный выбор для своей ситуации на этом уровне.

В любом случае вы получаете правильно заполненный context.user, который позволяет вам продолжать использовать большинство пользовательских функций asp.net.

Этот вопрос старый, но я получаю значки за его популярность, поэтому думаю, что стоит дать обновленный ответ.

«Простой» поставщик членства в Microsoft, наконец, понял это правильно, по моему скромному мнению. Если вы пишете что-то новое или даже присоединяетесь к устаревшей базе данных с новым приложением. Используйте простого поставщика членства. ПУТЬ ЛЕГКО и ЧИСТЕЕ для реализации. Установите пару таблиц и укажите провайдер на ваш список пользователей, и вы в основном сделали.

Эта ссылка поможет вам начать работу или просто перейдите на Google: http://www.mattjcowan.com/funcoding/2012/11/10/simplemembershipprovider-in-mvc4-for-mysql-oracle-and-more-with-llblgen/