Использование базы данных поставщика членства ASP.NET с вашей собственной базой данных?

Question

Мы разрабатываем Приложение ASP.NET MVC , которое в настоящее время использует свою собственную базу данных ApplicationData для моделей домена и еще одну Membership для поставщика управления пользователями / членства.

Мы ограничиваем доступ, используя data-annotations в наших контроллерах.

[Authorize(Roles = "administrators, managers")]

Это отлично работает для простых случаев использования.

---

Поскольку мы масштабируем наше приложение, наш клиент хочет ограничить specific users доступом к определенным областям нашей ApplicationData базы данных.

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

Пользовательская история будет:

• Пользователи в роли NewYorkManager должны иметь возможность только редактировать / просматривать продукты, собранные в Нью-Йорке.

Мы создали таблицу-заполнитель UserRightsRegions, которая содержит UserId и RegionId.

Как мне связать с базами данных ApplicationData и Membership для правильной работы / с cross-database-key-references? (Возможно ли что-то подобное даже ?)

Вся помощь приветствуется!

Answer 1

По моему мнению, вы должны быть в состоянии надежно интегрировать свою базу данных со стандартным aspnet_db, но я бы посоветовал не дублировать или заменять таблицу aspnet_users.

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

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

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

Один из аспектов истории членства, который я обнаружил, требует наибольшего внимания - удаление пользователя, и простое изменение / дополнение к sproc удаления пользователя может справиться с этим.

Answer 2

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

Похоже, вы движетесь в правильном направлении с таблицами сопоставления. Я думаю, что одна часть, которую вам не хватает, это Распределенные запросы . Эта ссылка относится только к Sql Server 2008. Там есть ссылка на документацию по Sql Server 2005, если вы этим пользуетесь.

Answer 3

Если вы найдете нужные статьи, очень просто расширить членство в поставщике, чтобы обеспечить дополнительную функциональность. Я переместил свою таблицу пользователей в свою основную таблицу SQL-сервера и написал свой собственный менеджер ролей, который получает значения из отдельной таблицы. Похоже, что вам нужно сделать, это настроить таблицу в вашей пользовательской БД с указанием местоположения каждого пользователя, а затем создать метод для объекта пользователя, что-то вроде «GetLocation ()», который возвращает местоположение пользователя из БД. затем пользователь может отфильтровать ваши данные из вашей основной БД. Вот несколько статей, которые я просматривал в своих закладках. Посмотрите, помогают ли они, если вы заглядываете на основной сайт ASP.NET или в Google для расширенных статей провайдера членства, их много. http://msdn.microsoft.com/en-us/library/ms998347.aspx http://www.4guysfromrolla.com/articles/120705-1.aspx http://msdn.microsoft.com/en-us/library/aa479048.aspx

Answer 4

Вы можете попробовать свернуть свое членство или просто продлить, как предлагает Дэйв.

Создайте свою собственную [Users] таблицу, которая может быть заполнена на основе таблицы aspnet_Membership. Поэтому вы можете иметь больше контроля над ним.

Вы также можете просто внедрить более сложную систему профилей. Команда .NET улучшила способ хранения профилей, так что вместо того, чтобы «блобизировать» их, вы можете настроить их для сохранения в реальной таблице сейчас [слава богу].

Поставщик профиля таблицы

Answer 5

Похоже, вам может понадобиться создать своего собственного настроенного поставщика членства. Вы, вероятно, можете (не положительно здесь) расширить существующий, так что вам не придется полностью его заново изобретать. Здесь - это видео с ASP.net, в котором описывается, как это сделать. Google "поставщик членства asp.net" за тонны больше.