Нужен ли пользовательский поставщик членства для интеграции сторонней аутентификации в ASP.NET?
У меня есть приложение ASP.NET MVC, в которое я только что интегрировал стороннюю систему федеративной идентификации RPX. Интеграция работает нормально, но у меня возникли некоторые трудности, связанные с тем, что с ней делать на уровне ASP.NET.
Я довольно новичок в ASP.NET (я изучаю его с MVC), и я обнаружил немного о модели провайдера для членства и данных профиля, и это кажется невероятно сложным (но не менее мощным). Конкретная вещь, с которой я борюсь - это постоянство пользователя в базе данных. Я до сих пор использую стандарт SqlMembershipProvider реализация, которая работала нормально. Однако теперь я хочу сделать такие вещи, как сохранение и проверка кода подтверждения в базе данных для проверки электронной почты (в случае, если адрес электронной почты пользователя указан как непроверенный результатом RPX), и сохранение возвращенных данных. Часть этого важна для аутентификации, например, адрес электронной почты, а часть - просто информация профиля (например, возраст пользователя, пол и т. Д.).
В базе данных ASP.NET у меня есть куча других специфичных для приложения таблиц, с которыми я взаимодействую через NHibernate. Я понимаю, что членство / профиль в ASP.NET состоит в том, что он обрабатывает постоянство, и поэтому мне не нужно ничего делать с NHibernate, чтобы все это заработало.
Моя цель - чтобы вход в систему был похож на Stackru, но с несколькими дополнительными моментами (например, проверка электронной почты). Нужно ли создавать полноценный пользовательский провайдер, чтобы делать это, или я могу согнуть по умолчанию SqlMembershipProvider моей воле эффективно?
[Пожалуйста, также посмотрите мой другой вопрос, касающийся паролей в таком приложении.]
1 ответ
В прошлом я проделывал аналогичную работу, просто создав новый класс провайдера, который наследуется от SqlMembershipProvider, а затем переопределил методы, которые мне нужны.
Вы по-прежнему можете вызывать реализацию базового метода, чтобы сначала выполнить большую часть работы, а затем выполнить любую дополнительную логику, необходимую вам в производном классе. Создание поставщика с нуля - это МНОГО работы, и оно должно быть вашим последним средством.
Вы можете добавить новую таблицу в базу данных с ключевой ссылкой на aspnet_Membership, а затем добавить свои собственные хранимые процедуры, которые вы вызываете из методов вашего производного провайдера, чтобы делать все, что вам нужно, с этой новой таблицей. Это лучше, чем добавление столбцов в схему членства, поскольку это позволяет отделить ваши пользовательские элементы.
Вам все еще нужно исследовать класс SqlMembershipProvider с точки зрения того, что вам нужно переопределить, но я думаю, что этот подход будет работать для вас, основываясь на том, что вы описали.