Членство провайдера использовать или не использовать?

Question

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

При добавлении нового пользователя я также хочу сохранить данные пользователя, связанные с Facebook ... например, UID и токен доступа.

Редактировать

Это простоидея, возможно ли было бы принудительно передать мои значения в аргументах и ​​затем обработать их в моем коде?

Обновление

Я обнаружил, что существует object providerUserKeyаргумент в методе Создать пользователя.В документации MSDN я обнаружил, что он используется для передачи уникального ключа, такого как GUID, для каждой новой строки.Но в моем БД у меня уже есть условия для UID новой строки.Поэтому я должен использовать этот параметр extra , чтобы передать мои пользовательские данные как объект через этот аргумент и обработать их там в моем пользовательском коде провайдера.

Answer 1

Если вы выберете переход между собственной аутентификацией / входом в систему или переходом с членства в группу и кодированием слоя отображения, тогда я определенно остановлюсь на последнем, вы всегда можете опираться на то, что предлагает вам членство, если не через API, то с помощьюТаблицы БД напрямую.

Неизбежно, что вы получите неверную аутентификацию и заплатите цену позже, если выполнили свою собственную.

В качестве альтернативы вы можете захотеть взглянуть на OpenID-аутентификацию , то есть увидеть этоSO поток: Проверка подлинности OpenID в ASP.NET?

РЕДАКТИРОВАНИЕ:

Я не думаю, что вам нужен пользовательский поставщик членства.В проекте, который я делал в прошлом, у нас было собственное управление пользователями, прежде чем мы интегрировались в ASP.NET Membership.Помимо добавления таблиц членства SQL в нашу БД все, что нам нужно было сделать, - это обеспечить сопоставление между нашими пользователями (у которых в то время был обычный bigint в качестве ключа) и GUID пользователя Членства.При таком типе сопоставления вы также можете сохранить все свои данные, связанные с Facebook (только отношения FK с пользователем Членства)

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