Руководство SimpleMembership в ASP.NET MVC 4

Хорошая, статья, спасибо.
Но я бы не стал так категорично привязываться к MVC4 — в MVC5 beta 2 которого с чуть больше, чем неделю назад, обновилась до rc1, авторизация в которой меняется на Owin, более того, из местных плюшек там можно сразу заметить полезность вынесения изменения модели User прямо в классе модели,, который в MVC4 был, кхм, запрятан. Соответственно упрощается модификация модели пользователя и и таблиц, связанных с моделью пользовательского профиля, в прошлой версии для добавления свойств к пользовательскому профилю надо было повозиться, а в MVC5 все просто:

public class User: IUser
{
public User()
: this(String.Empty)
{
}

public User(string userName)
{
UserName = userName;

Id = Guid.NewGuid().ToString();
UserGroupId = Id; // кастомной поле, добавленное мной
UserRegisteredDate = DateTime.UtcNow; // кастомное поле, добавленное мной
}
[Key, HiddenInput(DisplayValue = false)] // помоему я спрятал
public string Id { get; set; }

[Required, Display(Name = «Имя входа в систему»)] // тоже моя вставка
public string UserName { get; set; }
}

Из умолчательного кода инициализатора заметно, что вместо int в идентификаторах пользователя теперь используются более удобные (U|G)UID'ы, приведённые в строку. Роли теперь имеют не Id, RoleName, а id = RoleName, т.е состоят из одного поля string.
Так же, изменена работа с провайдерами авторизации, код выкладывать лениво, но модели авторизации поменялись, как по мне, в хорошую сторону.
«фильтрующий» класс убран, есть только модель и контроллер.

Из минусов замечу, что работа с «профилем» текущего пользователя в rc1 либо отсутствует по причине rc, либо вынесена на откуп программисту.
Например, в mvc4 в пользовательском «профиле» были замечательные поля — дата последнего входа, количество попыток ввести пароль, и с десяток других удобных по умолчанию, сейчас у меня это частично реализовано руками — feedback я уже по этому поводу отправил, жду ответа от команды разработки.

Это касаемо авторизации

Вы так категорично пишете, что у меня стойкое ощущение, что я отстал от жизни. Давайте для начала разберем о чем речь. То, что вы называете «Система ASP.NET Membership System» — я так полагаю, имеется ввиду набор поставщиков Sql Server, в которые входят

— Членство (класс SqlMembershipProvider).
— Управлением ролями (класс SqlRoleProvider).
— Профиль (класс SqlProfileProvider).
— Персонализация веб-частей (класс SqlPersonalizationProvider).
— Веб-события (класс SqlWebEventProvider).

Хочется также отметить, что абсолютно необязательно использовать все эти поставщики одновременно, — можно использовать, к примеру, только членство, а управление ролями переделать под другое хранилище. Также нет необходимости весь этот огород инициализировать в базе — есть же средство регистрации, у него куча параметров. По поводу «стандартной логики работы MembershipProvider и RoleProvider» — по моему это были абстрактные классы, а то, что Вы имеете ввиду — уже SqlMembershipProvider и SqlRoleProvider.

Теперь по поводу минусов.

Требуется полный SQL Server по умолчанию

У меня на Sql Server Web 2008 абсолютно спокойно ставятся все провейдеры и работают. В 2012 версии, я думаю, проблем тоже быть не должно. Наверное, Вы имели ввиду, что это не будет рабоать, например, с Sql CE?

все необходимые данны представлены в виде набора атрибутов (UserName, Password, IsApproved, CreationDate...) и другая информация будет предоставлена используя Profile Provider

Насколько я помню, за это отвечает Membership (MembershipUser)

провайдеры по умолчанию не будут работать на SQL Azure

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

Для работы с базой данных отличной от SQL Server необходимо переопределить набор методов провайдера

Во-первых, есть уже много готовых, например Oracle, db2, но можно спокойно писать и кастомный, о чем есть инфа в документации.

Ориентация на модель Пользователь > Роль

— даже не понял, о чем речь, ес честно. Ну, не нравится стандартная, используйте свою. Не вижу проблем никаких. Можно даже свой ролепровайдер написать.

Проблема с ASP.NET Membership в том, что она хранит дополнительную информацию об аккаунте сама. Это значит, что нельзя напрямую получить доступ к данным профиля

Ибо мембершип и профиль разделены и не связаны друг с другом. И что значит, получить доступ напрямую? И зачем?

Как он реализован я опущу, можно посмотреть в оригинальной записи SimpleMembership. Важно знать, что SimpleMembership унаследован от ExtendedMembershipProvider

ExtendedMembershipProvider унаследован от того же MembershipProvider, от которого унаследован SqlMembershipProvider. Принципы работы у них одинаковые. Они просто хранят данные по разному.

И напоследок.

SimpleMembership разработан для замены предыдущей версии ASP.NET Membership Provider (ASP.NET Role)

Я думаю, что они просто добавили новую реализацию мембершипа, которая решает самые простые задачи, от того и simple. И почему Вы пишете, что этот Simple может быть заменой стандартному — тоже не ясно, ведь это просто альтернативная реализация.

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

Эм, то, что Вы можете добавить юзеру любое количество полей, сгенерить таблицу для него через Code First и получить, используя SimpleMembership — это называете отличиями от заранее заданной конфигурации? Или о чем речь? Это всё можно сделать и со стандартной только танцев больше — получить ИД юзера и добавить дополнительную таблицу «ИД-Нужные мне поля».

Claim based auth system

Не понял, причем тут SimpleRoleProvider — ибо это такая же реализация SqlRoleProvider. Даже не удивлюсь, если вдруг можно будет подружить SimpleRoleProvider с SqlMembershipProvider и наоборот (симпл мембершип с sql role). О каких конкретно шагах речь то идет?

Существует большое количество задач, где основным объектом является профиль пользователя, соответственно выполнять операции с ним хочется напрямую с необходимыми полями в базе а не со всем объектом и напрямую через провайдер данных (Data Layer) а не через Auth Layer.

Согласен. А ещё я могу использовать доменную авторизацию и подтягивать профиль через LDAP — но мы же это минусом не называем для SimpleMembership. У каждого своя задача и от этого выбирают инструменты. Если надо напрямую оперировать профилем прямо в запросах к базе(разные джойны, например), ну, используйте для этого подходящие решения.

Написан для замены — чтобы заменить, потому что он проще в использовании, функциональнее и расширяем

Ну, вообще он не покрывает все провайдеры, о которых ведем речь. Как, например, он работать будет, если захочется использовать веб части? Если веб эвенты захочется писать встроенным механизмом в базу? Вы просто намешали всё в одну кучу. Ну, допустим, пользуемся SimpleMembershipProvider и SimpleRoleProvider — что мешает паралельно использовать провайдер для профиля, веб эвентов и персонализации веб частей?

А как вы относитесь к ручной системе авторизации (http://oxozle.com/2013/08/10/avtorizaciya-asp-net-mvc)?

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

П.С. Это ответ автору в тред выше. Напутал я с кнопками