Нужен ли пользовательский поставщик членства для интеграции сторонней аутентификации в ASP.NET?

Question

У меня есть приложение ASP.NET MVC, в которое я только что интегрировал автономную систему идентификации . Интеграция работает нормально, но я испытываю трудности с тем, чтобы обернуть голову вокруг того, что с ней делать на уровне ASP.NET.

Я довольно новичок в ASP.NET (я изучаю его с помощью MVC), и я немного узнал о модели поставщика для членства и данных профиля и кажется невероятно сложным (но не менее мощным). Конкретная вещь, с которой я борюсь, - это постоянство пользователя в базе данных. Я до сих пор использовал стандартную реализацию SqlMembershipProvider, которая отлично работала. Тем не менее, теперь я хочу делать такие вещи, как хранение и проверка кода проверки в базе данных для проверки электронной почты (в случае, если адрес электронной почты пользователя указан как непроверенный результатом RPX) и сохранение возвращаемых данных. Некоторые из них необходимы для аутентификации, например, адрес электронной почты, в то время как некоторые из них - это просто информация о профиле (например, возраст пользователя, пол и т. Д.).

В базе данных ASP.NET у меня есть множество других таблиц приложений, с которыми я взаимодействую через NHibernate. Мое понимание элемента Membership/Profile в ASP.NET заключается в том, что он обрабатывает постоянство, и поэтому мне не нужно ничего делать с NHibernate, чтобы добиться этого.

Моя цель заключается в том, чтобы опыт входа в систему был похож на StackOverflow, но с несколькими дополнительными битами (например, проверка электронной почты). Нужно ли мне создавать полнофункциональный пользовательский провайдер, чтобы сделать это, или могу ли я согнуть по умолчанию SqlMembershipProvider по моей воле эффективным способом?

[Также см my other question, в отношении паролей в таком приложении.]

Answer 1

Я сделал аналогичную работу в прошлом только путем создания нового класса поставщика, который наследует от SqlMembershipProvider, то переопределения методы мне нужно ,

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

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

Вам по-прежнему необходимо исследовать класс SqlMembershipProvider с точки зрения того, что вам нужно переопределить, но я думаю, что этот подход будет работать на вас, основываясь на том, что вы описали.