Наконец-то превращается в нечто юзабельное.

http://blogs.msdn.com/b/webdev/archive/2014/03/20/test-announcing-rtm-of-asp-net-identity-2-0-0.aspx

Из главного:

+ Поддержка двух-факторной аутентификации
+ Подтверждение регистрации
+ Сброс пароля
+ Блокировка аккаунта
+ Выход "отовсюду" (сделать куки на всех браузерах неактуальными)

Из болезненного:

+ теперь можно сделать ключ любого типа (ранее был String), без плясок
+ IQueryable для пользователей и ролей без ковыряния DbContext
+ удаление пользователя
+ уникальный индекс на имя пользователя
+ продвинутый валидатор пароля

Понятное дело, обновление до 2.0 порушит работу приложения к чертям. Самое меньшее, что придётся сделать, это сотворить миграцию для контекста базы данных. Если вы добавляли такие поля для пользователя Email, IsConfirmed, придётся их грохнуть, так теперь они идут "изкаропки".

Подробней о том, как заапгрейдиться, здесь: http://blogs.msdn.com/b/webdev/archive/2013/12/20/updating-asp-net-applications-from-asp-net-identity-1-0-to-2-0-0-alpha1.aspx

Немного не в тему. В очередной раз вендорные товарищи подтверждают, что IQueryable отлично катит в качестве интерфейса для репозитория, а кто до сих пор самоотверженно колбасит прослойку с выдачей IEnumerable/IList пусть жуют бублики

Andrey1306Получилось так что роль считывается на момент аутенфикации пользователя, и до следующего входа, роли не меняются .

Да, это так. Но ASP.NET Identity тут вообще не при чём. Любой другой механизм, который сторит шифрованный тикет в куках будет та же самая история. Чтобы избежать "кеширования" ролей, надо написать кастомный фильтр, который будет перепроверять состояние логина и сохранять его, допустим, в сессии.

Andrey1306как можно фильтр использовать в chtml

чтобы после изменения набора ролей у пользователя, эти роли работали пользователю надо выйти и зайти снова.

чтобы этого не приходилось делать, есть решение, описано оно здесь:

http://stackoverflow.com/questions/19487322/what-is-asp-net-identitys-iusersecuritystampstoretuser-interface/19505060#19505060

МСУНе фантазируй )) UserManagerExtensions.IsInRole<TUser, TKey>
Роли подхватываются на лету из базы, всё прозрачно.

да что ты говоришь?!

осталось передать инстанс юзер менеджера во все слои, где он даром не сдался.

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

[Authorize(Roles = "role1, role2")]

сразу на помойку

МСУhVosttчтобы после изменения набора ролей у пользователя, эти роли работали пользователю надо выйти и зайти снова.
Вот за это можно сразу расстреливать разработчика. Бесцеремонно и жестко.

это технически. смена SecurityStamp заставляет программу пользователя перелогинить, незаметно для самого пользователя. и это более секьюрно и правильно.

МСУhVosttчтобы после изменения набора ролей у пользователя, эти роли работали пользователю надо выйти и зайти снова.
Вот за это можно сразу расстреливать разработчика. Бесцеремонно и жестко.

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

ну-ка, какое расширение для юзер менеджера посоветуешь? что делать?

МСУЖжешь. Если я сменю ему пароль, он больше не войдет на сайт Кука - это клиентские перманентные данные, они никоим образом не коррелирует с серверной безопасностью.

Предлагаю тебе проверить это утверждение на практике.

МСУУ меня, кстати, во многих проектах используется и использовался свой провайдер ролей, особенно для windows аутентификации. Написал провайдер, подключил и всё штатно работает без проблем. Отличный способ.

В ASP.NET Identity уже есть провайдер ролей, зачем я буду переписывать его, если он отлично справляется со своей задачей? Или хочешь сказать разработчики что-то не учли? Да и раньше роли кешировались в тикете.

МСУНе тупи, зачем изобретать костыли. Если хочешь, чтобы работали штатные роли, напиши свой провайдер ролей, вот тут есть рецепт http://codearticles.ru/articles/2485

Ты предлагаешь бред, извини.

Чем те нативный фильтр не угодил? И на кой ляд лазить в БД за ролью, когда она уже есть в тикете? Меняешь роль у пользователя, сбрасывай ему SecurityStamp, и не придётся вставлять такие жуткие костыли, как ты привёл в рецепте.

МСУТы шутишь? )) Это подтверждено многолетней практикой, инфа 147%. Даже не думай спорить.

ASP.NET Identity от роду и года-то нет, взгляни пожалуйста на заголовок темы, мы о нём говорим =)

МСУASP.NET Identity нету провайдера ролей, он один и глобален для всего ASP.NET - это секция roleManager в web.config. В ASP.NET Identity есть неплохая обвязка над ролями - где надо, пользуйся. Я не про кеширование говорю, оно было и есть (читай про ключ cacheRolesInCookie ). Я говорю про то, что каждый реквест должен ходить в базу и проверять актуальность ролей и доступность пользователя - это основа основ. Никаких костылей, всё просто и внятно.

От тут ты ошибаешься, ещё как есть, Simple Role Provider, работающий поверх OWIN модуля. И зачем каждый реквест должен ходить в базу и проверять актуальность ролей, если достоверно известно, что в куках актуальная инфа, и по-другому быть не может (при правильной работе с SecurityStamp)? Костыли у тебя в том, что ты делаешь ненужную работу. Я пользуюсь User.IsInRole, а ты похоронил этот способ в угоду бредовой идее. Зачем?

Алексей КНакой лепить костыли вроде SecurityStamp, если производительность позволяет каждый раз лазить в базу. Накой сделано кэширование по дефолту информации о пользователе - непонятно. Microsoft скоро рухнет под тяжестью своего идиотизма.

А в чём проблема-то не пойму? Кеширование это всегда хорошо. Тем более на клиенте.