Пользовательское членство / поставщики ролей / профилей БЕЗ наследования MembershipProvider, RoleProvider и т. Д.?

Question

Есть ли что-то, что мешает мне просто настраивать все членство, роли и профили без наследования от абстрактных классов, таких как MembershipProvider и т. Д .?

MSDN четко заявляет: «При реализации пользовательского поставщика ролей вы должны наследовать абстрактный класс RoleProvider». (http://msdn.microsoft.com/en-us/library/system.web.security.roleprovider.aspx)

Однако, пока я иду сюда, я обнаруживаю, что действительно настраиваю все это в соответствии с нашими конкретными потребностями, и во многих случаях я даже не реализую то, что унаследовано, а вместо этого иду своим собственным путь. Одним из примеров того, что я делаю, является метод «GetAllRoles». .NET хочет, чтобы я реализовал метод, который возвращает массив строк. Я считаю, что это не отвечает моим потребностям, так как «Роль» в нашем случае содержит гораздо больше информации, чем просто имя - у нас есть описания ролей на нескольких языках, например. Поэтому я пошел и создал свой собственный класс с именем ProjectRole, и мой метод GetAllRoles вернул List<ProjectRole>. И затем на уровне представления я могу извлечь все данные из каждой ProjectRole с помощью простого цикла foreach.

Точно так же я не хочу возвращать MembershipUser для пользователей, а скорее ProjectUser, где я могу предоставить свои собственные поля.

Пока все работает нормально. Но я еще не закончил. Что я хочу знать, так это то, что я как-то облажался и просто еще не осознал этого? Для входа я делаю

if (ProjectMembershipProvider.ValidateUser(UsernameTextBox.Text, PasswordTextBox.Text == true)
{
   FormsAuthentication.SetAuthCookie(UsernameTextBox.Text, true);
}

Если я не ошибаюсь, я даже не использую провайдеров ASP.NET на данном этапе, кроме как для наследования множества вещей, которые я заканчиваю тем, что добавляю теги [Obsolete], потому что я раскручиваю свои собственные методы. Однако меня беспокоит то, что, в конце концов, я все еще хочу иметь возможность использовать некоторые вещи, такие как User.Identity.IsAuthenticated и User.Identity.Name, и такие, чтобы отображать имя пользователя внутри, например "Welcome " + User.Identity.Name. Будет ли это возможно, если я пойду по этому маршруту?

tl; dr --- Я как-то облажался, неправильно используя провайдеров, от которых я наследую, и просто еще не осознал этого?

Answer 1

Хотя Тим не прав относительно специфики реализаций, его аргументы верны. Если вы хотите использовать API членства, вы ДОЛЖНЫ наследовать от абстрактных классов, потому что API зависит от этих абстрактных классов. У API нет другого способа узнать, какой интерфейс использовать.

Это не значит, что вам нужно использовать API членства. Но, как упоминает Тим, вы теряете одно из значительных преимуществ членства, а именно то, что вы можете подключить универсального провайдера, и это полностью не зависит от вашего приложения.

Причина, по которой RoleProvider имеет специальный интерфейс, который возвращает строки, заключается в том, что эти строки можно сравнивать со стандартными объявлениями для ролей (т. Е. User.IsInRole() и т. , И если вы не реализуете стандартные версии, будут возникать исключения, если вы попытаетесь использовать встроенную функциональность.

Есть решения. Членство, роли и т. Д. - это просто реализации других систем, в частности IPrincipal и IIdentity. Вы можете полностью обойти роли, членство и т. Д., Если реализуете свои версии этих интерфейсов. Затем использование User.IsInRole() вызовет вашу реализацию IPrincipal, а User.Identity.Name вернет данные из вашей пользовательской реализации IIdentity. После этого вы перестали поддерживать официальное членство и ролевые интерфейсы API (интерфейс профиля более низкого уровня отсутствует, профиль является лишь частью API членства)

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

Answer 2

Вам не нужно наследовать от MembershipProvider, RoleProvider и ProfileProvider.

Однако, если вы этого не сделаете, вы потеряете множество преимуществ для вещей, которые знают, как разговаривать с классами, которые делают.Внезапно вам придется задействовать свои собственные механизмы для:
- входа в систему пользователей (вы не можете использовать элементы управления входом / выходом из OOTB)
- всего, что использует классы ролей или членства, напримерas Roles.IsInRole ("Admin")
- Хранение аутентифицированных данных пользователя в файлах cookie.
- Регистрация пользователя (ну, хорошо, реализация OOTB довольно ограничена)
- Настройка, какие страницы / каталоги требуютаутентификация и что делать, если пользователь пытается поразить их и не аутентифицируется (с помощью MembershipProvider / RoleProviders это выполняется элементами OOTB web.config)
- все, что использует атрибут Authorize

Все это можно преодолеть без особых усилий.Тем не менее, основным недостатком собственной разработки является то, что вы тесно связываете свои механизмы аутентификации / авторизации с вашим сайтом, тогда как с помощью реализаций MembershipProvider / RoleProvider вы можете создать сайт, который может заменить вашу систему членства, просто добавив новую DLL вПапка bin и изменение настроек web.config.

Конечно, у вас могут быть свои собственные абстрактные классы BetterMembershipProvider / BetterRoleProvider, от которых вы наследуете, чтобы они по-прежнему имели слабую связь.Но тогда вы больше не можете оставлять свой класс членства в системе, которая знает, как обращаться с MembershipProviders, такой как многие существующие веб-сайты .Net, sharepoint, Dot Net Nuke и т. Д.