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

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

1 голос
/ 15 июня 2009

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

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

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

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

[См. Также мой другой вопрос , касающийся паролей в таком приложении.]

1 Ответ

2 голосов
/ 15 июня 2009

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

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

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

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

...