Pull to refresh

Comments 11

Хорошая, статья, спасибо.
Но я бы не стал так категорично привязываться к 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 MVC). Там мой профиль да и авторизация очень простая получается, выдать токен авторизации и при желании удалить его. Есть у вас мысли по этому способу?
Это не новые плюшки — это авторизация в MVC5 по умолчанию, и придётся переделывать код проекта, и менять зависимости…
Я вкратце расписал её плюсы и минусы.
По поводу мыслей — кнопочки авторизоваться через fb/twi/google/ms account некоторым проще.
Главное предусмотреть возможность отвязки аккаунта сайта от аккаунта социалки, и эта возможность тут тоже есть? как и в mvc4, насколько я помню код.
Опять же, родная интеграция с Twitter Bootstrap (в rc уже 3 версия, кстати, можно обновиться), асинхронность некоторых методов, новый EF (в 2012 студии работа с SQL начала выдавать ошибку несовпадения версий библиотек доступа, да), какие-то еще мелочи, которые я навскидку не помню.
Авторизация на сайте это такое место, которое делается хорошо и редко меняется. Т.к. за безопасность пользовательских данных отвечают несколько строчек кода. И менять системы авторизации с каждым выходом фреймворка глупо. Другое дело если это можно сделать безболезненно и безопасно. В случае с SimpleMembership такой фокус не пройдет (если ранее использовался ASP.NET Membership).

MVC5 пока не пробовал.
«Несколько строчек кода», простите… в mvc4 DonNetOpenAuth библиотеки, на секундочку, вместе занимают 2,5 мегабайта в проекте…
Об этом и говорю, что за капотом большая работа происходит, а использовать это всего написав несколько строчек. Ведь если переписывать систему авторизации совсем вручную, начиная с токенов, шифрования и пр — то с первого раза не получится, на помощь и приходят уже готовые и оттестированные системы.
… оттестированные сообществом и более профессиональными программистами, разбирающимися в безопасности
Вы так категорично пишете, что у меня стойкое ощущение, что я отстал от жизни. Давайте для начала разберем о чем речь. То, что вы называете «Система 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 может быть заменой стандартному — тоже не ясно, ведь это просто альтернативная реализация.
Спасибо за столь подробный отзыв. По порядку:

Да, в основном рассматриваю все-же использование MS SQL + конечно же роли пользователя и сами профили пользователей, т.к. это наиболее распространенная задача (регистрация, авторизация).

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


Да, для SQL CE, также и для SQL Azure (хотя в новых версиях, где-то видел что гораздо проще запустить, но проблемы есть)

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


Верно, только получить эти данные напрямую из базы сложнее чем просто SQL запрос.

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


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

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


Это о том, что идея этой системы в том что существуют существуют пользователи и существуют роли у этих пользователей. А бывает еще Claim based auth system, когда есть некие права на чтение/запись и пр. SimpleMembership, как я понимаю, делает шаг в сторону упрощения для программиста написания системы авторизации, однако все-же остается такой пробел.

И что значит, получить доступ напрямую? И зачем?

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

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


Написан для замены — чтобы заменить, потому что он проще в использовании, функциональнее и расширяем. Ведь именно это подразумевает слово замена, чтобы прекратить использовать старый и использовать новый, где очень много чего добавлено (OAuth из коробки).

А как вы относитесь к ручной системе авторизации (http://oxozle.com/2013/08/10/avtorizaciya-asp-net-mvc)?
Я и не говорю, что их нет. Скорее о том, что реализация будет сложной если писать отличную от «заранее заданной конфигурации»
Эм, то, что Вы можете добавить юзеру любое количество полей, сгенерить таблицу для него через 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, и в каждом конкретном случае нужно выбирать подходящее решение. Я видел разные реализации, начиная от сложной системы ролей/пользователей и заканчивая списком юзеров в файлике на сервере.

П.С. Это ответ автору в тред выше. Напутал я с кнопками
В дополнение.
Верно, только получить эти данные напрямую из базы сложнее чем просто SQL запрос.

Если речь идет о MembershipUser

Sign up to leave a comment.

Articles