Используя базу данных поставщика членства ASP.NET с Вашей собственной базой данных?
Мы разрабатываем Приложение MVC ASP.NET, которое в настоящее время использует свою собственную базу данных ApplicationData для моделей предметной области и другого Membership для управления пользователями / поставщик членства.
Мы делаем использование ограничений доступа data-annotations в наших контроллерах.
[Authorize(Roles = "administrators, managers")]
Это работало отлично для простых вариантов использования.
Поскольку мы масштабируем наше приложение, наш клиент хочет ограничить specific users в определенные области доступа нашего ApplicationData база данных.
Каждый из наших продуктов содержит внешний ключ, относящийся к региону, в котором был собран продукт.
Пользовательская история была бы:
- Пользователи в роли, которую NewYorkManagers должен только смочь отредактировать / видят продукты, которые собраны в Нью-Йорке.
Мы составили таблицу заполнителя UserRightsRegions это содержит UserId и RegionId.
Как я могу связать обоих ApplicationData и Membership базы данных для работы правильно / наличие cross-database-key-references? (Что-то вроде этого даже возможно?)
Вся справка больше, чем ценится!
5 ответов
На мой взгляд, вы должны быть в состоянии надежно интегрировать вашу базу данных со стандартной aspnet_db, но я бы не советовал дублировать или заменять таблицу aspnet_users.
Это центральная точка всех провайдеров, использующих схему aspnet_db, включая пользовательские провайдеры, которые могут дополнять, но не реализовывать пользовательскую замену.
Чтобы максимизировать повторное использование сильного протестированного кода инфраструктуры в стеке провайдеров/API, лучше всего идти в этом потоке.
Вы должны быть очень внимательны к любым модифицированным функциям ядра членства и убедиться, что ваши новые ограничения ведут себя ожидаемым образом в каждом случае.
Аспект истории членства, который, как я обнаружил, требует наибольшего внимания - это удаление пользователя, и простая модификация/дополнение к функции delete user sproc может с этим справиться.
Похоже, вам может потребоваться создать собственного настраиваемого поставщика членства. Вы, вероятно, можете (здесь не очень хорошо) расширить существующий, чтобы вам не пришлось полностью изобретать его. Вот видео с ASP.net, в котором описывается, как это сделать. Google "поставщик членства в asp.net" и многое другое.
Вы можете попробовать создать собственное членство или просто продлить его, как предлагает Дэйв.
Создайте свою собственную таблицу [Пользователи] , которая может быть заполнена на основе таблицы aspnet_Membership. Таким образом, у вас может быть больше контроля над этим.
Вы также можете просто реализовать более сложную систему профилей. Команда .NET улучшила способ хранения профилей сейчас, так что вместо их «блобизации» вы можете настроить их для хранения в реальной таблице сейчас [слава богу].
Как отмечали другие, существует множество хороших ресурсов, которые могут помочь вам в создании вашего настраиваемого провайдера с использованием существующей базы данных.
Похоже, вы движетесь в правильном направлении с таблицами сопоставления. Я думаю, что вам не хватает одной части, это Распределенные запросы . Эта ссылка относится к Sql Server 2008. Там есть ссылка на документацию по Sql Server 2005, если это то, что вы используете.
Если вы найдете нужные статьи, то очень легко расширить провайдер членства для обеспечения дополнительной функциональности. Я перенес таблицу пользователей в основную таблицу SQL-сервера и написал свой собственный менеджер ролей, который получает значения из отдельной таблицы. Похоже, что вам нужно создать таблицу в БД users с местоположением каждого пользователя, затем создать метод для объекта user, что-то вроде "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