Как избежать использования членства провайдера?

Question

В настоящее время мы создаем архитектуру для тонкого клиента.Он должен соответствовать двум основным требованиям:

1. Приложение должно иметь модульную конструкцию.Каждый модуль может иметь (и на самом деле имеет) собственную систему ролей.
2. Позже приложение должно быть адаптировано для работы с использованием разных баз данных на разных машинах.

Мы считаем, что Asp.NET MVC3 является подходящей платформой для этой задачи.Для управления данными приложения мы выбрали последнюю версию Entity Framework - ее пакет поставщиков данных и функция Code First могут сэкономить нам много времени.

Часть, с которой мы столкнулись, - это система управления пользователями / ролями.У нас должен быть какой-то глобальный раздел администрирования для добавления пользователей и предоставления им доступа к модулям (только глобальные администраторы могут добавлять пользователей в систему, регистрация «парень с улицы» не поддерживается), и каждый модуль имеет свой собственный раздел администрирования со своими собственными администраторами.и роли.У нас уже есть модель данных для правильного хранения всего, что нам нужно, но мы не знаем, как правильно обращаться к этим данным из приложения.

В настоящее время мы видим два возможных способа решения этой проблемы:

1. Для написания пользовательских провайдеров членства и ролей на основе нашего DAL.Никто из нашей команды не делал этого раньше, поэтому мы не уверены, стоит ли этот путь проблем.Провайдер членства не может предложить столько гибкости, сколько требуется приложению, поэтому потребуются некоторые сложности.
2. Чтобы просмотреть некоторые устаревшие книги, чтобы выяснить, как была организована система администрирования веб-сайтов перед провайдерами членства, где они были созданы.*

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

Answer 1

Я бы лично рекомендовал сначала использовать стандартный поставщик членства для создания и аутентификации пользователей, а затем, как только вы убедились, что пользователь не просто «парень с улицы», используйте свою собственную пользовательскую архитектуру. чтобы убедиться, что аутентифицированный пользователь имеет доступ к контроллеру и действиям, к которым он пытается получить доступ.

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

Но, похоже, ваша структура разрешений для каждого модуля может соответствовать или не соответствовать форме поставщиков ролей ASP.NET. Если они это сделают, это все хорошо, и было бы неплохо реализовать пользовательский поставщик ролей. Но если ваши потребности «нестандартны», вам, вероятно, будет лучше просто вручную проверить права в точке, которая наиболее подходит для вас (контроллер, действие, фильтр запросов и т. Д.).

Answer 2

1. Для написания пользовательских провайдеров членства и ролей на основе нашего DAL.Никто из нашей команды не делал этого раньше, поэтому мы не уверены, стоит ли этот путь проблем.Провайдер членства не может предложить столько гибкости, сколько требуется приложению, поэтому потребуются некоторые ограничения.

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

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

Answer 3

Я бы посоветовал вам использовать провайдера нестандартного членства. Зачем? Потому что это стандартный способ, и вы сэкономите тонны работ. Это не так сложно, как я мог бы видеть, и есть тонны ресурсов, таких как этот .

Answer 4

Ну, наконец-то мы решили написать все с нуля, и было проще, если бы это было

• Добавить собственную реализацию IPrincipal.Дополнительные поля и совершенно другая логика для метода IsInRole (), позволяющего избежать записи собственных атрибутов.
• Назначение нашего события IPrincipal в Global.ajax для пользователя.

Это было совсем не сложно,Теперь у нас есть все, что мы хотели.Поставщики не вовлечены.