hVosttМСУТы шутишь? )) Это подтверждено многолетней практикой, инфа 147%. Даже не думай спорить.
ASP.NET Identity от роду и года-то нет, взгляни пожалуйста на заголовок темы, мы о нём говорим =)
ASP.NET Identity это лишь замена усопшим Membership и Simple Membership с более вкусными печеньками, не более того. Провайдер ролей - это железобетонный фундамент, заложенный во времена создания самой платформы ASP.NET 2.0. Не путай теплое с мягким.

1. Хочешь нативности - бери провайдер ролей и реализуй парочку свойств.
2. Хочешь новизны - бери UserManagerExtensions.IsInRole<TUser, TKey> и пихай его везде.

Но то, что предлагаешь ты - эпическое беспощадное зло

hVosttОт тут ты ошибаешься, ещё как есть, Simple Role Provider, работающий поверх OWIN модуля.
Присаживайся, двойка

http://msdn.microsoft.com/ru-ru/library/webmatrix.webdata.simpleroleprovider(v=vs.111).aspx


Класс SimpleRoleProvider изначально не предоставляет полный спектр функций, возможных в поставщике ролей ASP.NET, в той мере, как они определены в классе RoleProvider , используемом всеми поставщиками ролей ASP.NET . Если ваш веб-сайт требует полнофункционального управления ролями, можно пропустить инициализацию системы ролей веб-страниц (не вызывать WebSecurity.InitializeDatabaseConnection()) и вместо этого включить стандартные поставщики членства и ролей . В таком случае вызовы SimpleRoleProvider проходят через стандартный поставщик (который называется предыдущим поставщиком в документации по классам SimpleRoleProvider).


Хвост такой хвост... Когда ты перестанешь спорить уже, а.

hVosttИ зачем каждый реквест должен ходить в базу и проверять актуальность ролей, если достоверно известно, что в куках актуальная инфа
Ну ты сам не понимаешь, что это абсурд? Как может быть в куках актуальная информация, если пользователя лишили роли? Актуальная информация только в БД. Кстати, и Membership и Simple так же ходили на каждый реквест в базу по дефолту.

hVosttКостыли у тебя в том, что ты делаешь ненужную работу. Я пользуюсь User.IsInRole, а ты похоронил этот способ в угоду бредовой идее. Зачем?
Ну я свою мысль выразил, говорить больше не о чем. Я 10 раз сказал, то, что ты предлагаешь - кретинизм. Ты говоришь обратное. Ну ладно.

Алексей ККэширование применяется только с целью оптимизации, от безысходности.
+1К

Представим себе эпический кейс. Сисадмин в компании тупанул (ну вот хоть убей его, суть не изменится) и добавил пользователя в группы Domain Admins. Пользователь залогинился. Сисадмин опомнился и исключил пользователя из группы Domain Admins.

А теперь самое вкусное!

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

gandjustasАлексей К
А что такое хорошо? Быстро работающее приложение это плохо?
Не всё измеряется скоростью работы приложения. Есть еще такое требование, как актуальность данных. Порой это требование выше, чем требования к скорости работы. Понимание данного факта приходит с опытом, пока тебе об этом рано думать. Работай, оптимизируй.

hVosttМСУПрисаживайся, двойка
Я ещё раз говорю, ты ошибаешься.
Аргументами прям сыплешь.

hVosttМСУПровайдер ролей - это железобетонный фундамент, заложенный во времена создания самой платформы ASP.NET 2.0.
Это уже уходит в прошлое с наступление vNext.
Про vNext вообще ничего неизвестно, какой смысл тыкать этим словом в каждую дырку. Большая вероятность, что в vNext вообще практически всё уйдет в прошлое. Вот когда уйдет, вот тогда и будем обсуждать. А пока нет смысла гадать на кофейной гуще.

hVosttМСУНо то, что предлагаешь ты - эпическое беспощадное зло
Это не я предлагаю, это решение заложено в ASP.NET Identity. Просто воспользуйся, зачем же целенаправленно сношать мозг с устаревшими провайдерами, поддерживать которые нет никакого смысла? Учитывая что теперь всё строится на Claims Based.
В ASP.NET Identity заложено UserManagerExtensions.IsInRole, обращается к БД - то, что доктор прописал. Это лучше, чем твои костыли с куками.

hVosttМСУКак может быть в куках актуальная информация, если пользователя лишили роли?
Что бы там не сделали с пользователем, его кука должна после этого перестать быть актуальной.
Да мало ли, что она и кому должна. Это клиентский функционал, более того, на клиенте вообще могут быть куки выключены. С какого перепуга я свою инфраструктуру безопасности должен завязывать на какую-то клиентскую куку? Совсем ударился головой?

hVosttИ я не хочу иметь +100500 классов
Ну не хочешь, пиши дальше небезопасный гавнокод. Я ж не против.

hVosttИ это правильно.
Это абсолютно неправильно.

hVosttПредставим эпический кейс. Права и аутентификацию выдаёт одна подсистема, а ПО работает уже с авторизованным пользователем. И ему пофиг кто его пустил и кто прав надавал. Это Claims. Я делаю приложение, допустим, для фейсбука, авторизует пользователя он с пачкой прав, которые рулятся там же. У меня нет никаких ролей в базе. Какого ляда я должен лепить эти убогие мерзкие костыли, что ты предлагаешь? Давай уже, топай в современный век, харе отсижываться в средневековье!
Уважаемый, ты бы не поленился почитать, что такое SSO для начала. Вот тут даже рецептик есть http://codearticles.ru/articles/487
Фейсбук - это распределенная система, валидация полномочий и ролей происходит на сервере. Полномочия и роли хранятся именно в БД, а не в куках Если админ тебя забанит на write, ты сразу же потеряешь доступ к написанию буковок.
Вот тут есть матрица полномочий и ролей: https://www.facebook.com/help/323502271070625/
Это классическая матрица безопасности, реализуется исключительно в БД. Никакого кеширования тут не нужно. Так что про средневековье ты пойди кому другому расскажи ))

hVosttЛюбое секьюрное изменение пользователя должно сопровождаться перелогином.
Что за бред? С чего это вдруг я должен перелогиниваться, если меня включили в какую-то группу или дали роль?

hVosttЛибо отменять логин и заставлять его логинится заново, либо делать это самостоятельно. Не важно. Это всё одна точка за это отвечает. Всем остальным слоям должно быть по барабану. Они не должны заботиться об этом, вытаскивая актуальные роли из базы данных. Роли в базе данных -- это всего лишь частный случай. Они могут быть где угодно, и выдаваться кем угодно, значения это не должно иметь никакого.
Завязывай с наркотиками.

hVosttМСУВ ASP.NET Identity заложено UserManagerExtensions.IsInRole, обращается к БД - то, что доктор прописал. Это лучше, чем твои костыли с куками.
В задачи этого расширения входит управление пользователем, так как работает с инстансом менеджера. В задачи IPrincipal не входит лазить там куда-то. Как только чел вошёл, мы работаем с тем, что есть. Не размазывай разные несвязанные части приложения.
Что такое "задачи IPrincipal"? Нужно получить роли, берешь через менеджер и получаешь. Ты о чем? Какие задачи?

hVosttМСУС какого перепуга я свою инфраструктуру безопасности должен завязывать на какую-то клиентскую куку?
Это частный случай.
Ты тогда определись, что есть не частный случай.

Алексей К"Это частный случай" (ц) Псаки.
Ладно, пора завязывать. Слишком много времени уходит на этого оголтелого паренька :)

P.S. Но было весело ))