hVosttМСУ,

МСУДля тех, кто в танке - еще раз, с пережевыванием ситуации: нужно отстроить UI в разрезе полномочий HasUserProductsView, HasUserProductsEdit, HasUserProductsDelele. Причем тут Authorize?

какая хреновая архитектура, если у тебя есть такие методы. уже много лет это делается через роли. не HasUserProductEdit, а ProductEditor к примеру. и доступ к ролям юзера есть и в контроллере и во вьюхах. проверяй — нехочу. User.IsInRole() тебе в помощь юный падаван.
Невооруженным глазом видно, что у тебя просто нет опыта работы с подобными приложениями. Далеко не всё в роли упирается.
Например:

HasUserProductView = роль админ || (роль менежер $$ статус == 3) || ((роль вьювер && дата = сегодня) || роль вьювер && категория = 7).

Проблемы с архитектурой у тебя в голове, а не у меня в коде. Сначала дорасти до реальных задач, а потом говори за архитектуру других. С User.IsInRole можешь сходить в сад, где тебе и место.

hVosttМСУ,

МСУ1. А кто тебе сказал, что эту задачу решает контроллер? Эту задачу решает секьюрити класс - в нем вся логика в разрезе безопасности. В контроллере лишь прокинут доступ к этом механизму. Ты всегда понимаешь элементарные вопросы с 10 раза?
2. Что такое "надо фильтровать данные по юзеру"? Что за новый бред?

У тебя сложности с понимаем этого вопроса?

"как мне с помощью твоих фильтров отстроить UI в разрезе пользовательских прав?"

я вижу ты первый в мире кто открыл, что оказывается можно строить UI в разрезе пользовательских прав. для этого в ASP.NET все есть. еще раз, User.IsInRole() тебе в помощь. а что за этим стоит, твоя реализация или стандартная, уже by design.

Садись, двойка. С User.IsInRole ты можешь детей повеселить, бездарь

hVosttМСУ,

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

Сначала ты говорил, что нужен DI. Потом после того, как тебя хорошенько отшлепали, ты начал предлагать еще более безумные варианты - синглтон или экстеншен для контроллера. Потом ты с треском провалился по безопасности, абсолютно не разобравшись в предметной области построения секурити классов. И теперь на тебе - ты видишь в этом сахар.

Убей себя об стену, бестлочь

hVosttМСУHasUserProductView = роль админ || (роль менежер $$ статус == 3) || ((роль вьювер && дата = сегодня) || роль вьювер && категория = 7).

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

Это банальная безопасность, чайник :) Но для тех, кто всю жизнь клепает сайты визитки и не обрабатывает исключения - да, это плохой дизайн и глупые бизнес-требования.

hVosttЧСВ, смотрю, не даёт покоя. надо постоянно его подтверждать. например, черезвычайно усложненной архитекторой.
Ты просто еще не дорос до архитектуры, твое дело слушать дядей, которые определяют, где кнопку разместить в UI.

hVosttи еще, пиши в Майкрософ, пусть увольняют своих разрабов нахрен, за User.IsInRole() . ничего они в программировании не понимают. лучше пусть тебя пригласят главным архитектором.
Ты до сих пор так ничего и не понял, мальчик. User.IsInRole - это всего-лишь частный случай. Безопасность (CanView, CanEdit, CanDelete, Can..., Can..., ...) намного сложнее и замороченнее, чем User.IsInRole.

hVosttМСУ,

МСУСначала ты говорил, что нужен DI. Потом после того, как тебя хорошенько отшлепали, ты начал предлагать еще более безумные варианты - синглтон или экстеншен для контроллера. Потом ты с треском провалился по безопасности, абсолютно не разобравшись в предметной области построения секурити классов. И теперь на тебе - ты видишь в этом сахар.

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

Вопрос изначально состоит в том, что ты нихрена не понимаешь предметики - и лезешь своим носом в дела, с которыми не имел опыта работать.

Если интересно помыслишь над секурити абстракциями, наследования ролей, наследования правил (пермиссий), управлениями контейнерами групп, динамических ролевых условий (фейков) - посмотри мой старенький проект по кастомизации мембершипа: http://msadmin.codeplex.com

Хотя рано тебе такие вещи давать. Если такая безопасность

...HasUserProductView = роль админ || (роль менежер $$ статус == 3) || ((роль вьювер && дата = сегодня) || роль вьювер && категория = 7).

для тебя кажется ошибкой архитектуры, то пока могу посоветовать сходить в сад.

hVosttМСУ,

МСУ Безопасность (CanView, CanEdit, CanDelete, Can..., Can..., ...) намного сложнее и замороченнее, чем User.IsInRole.

не забудем добавить: «.. у МСУ», ибо этот товарищь обажает все усложнять, так он выглядит гораздо статней, умнее. и нужнее к слову говоря, ибо никто кроме него в коде не разберется. к любой программе, вышедшей из под рук МСУ требуется обязательное приложение: МСУ. видел я таких. и уволить нельзя, и оставить накладно. пусть болтается себе там в комроке, пишет свой говнокод.
Ты просто бестолочь, которой нечего сказать по теме. Которая не разбирается в предметики. Которая не отвечает на прямые вопросы.

hVosttконечно ошибка архитектуры! кто ж так пишет!? какого хрена у тебя роли на секьюрити прописаны жестко в коде?
Что такое "роли на секьюрити"? А где должны прописываться роли как не в коде?

hVosttв коде можно оперировать ролями. конкретные права на уровне данных, там же и привязка к ролям. ты же все смешал и называешь это стандартным подходом.
Я тебе 10 раз уже сказал, не только ролями. Можно оперировать всем - типами документов, текущей датой, погоде на луне. И на основе этих условий строить секурити конструкции. Этой логикой отруливает специальный класс.

hVosttа еще скидываешь неподдерживаемое старье типа http://msadmin.codeplex.com/ — знатнейшее говнокодище. видимо им ты и руководствуешься в разработке )) дергаешь, небось, куски кода?? ))
Что можно объяснить идиоту? То, что он идиот? Не поверит и запротестует.

hVostt, давай я задам тебе конкретный пример, а ты ответишь, как нужно решать его.

1. В приложении 2 роли, админ и менеджер
2. Справочник продуктов
3. Нужно дать доступ для справочника продуктов (Index) только для админа и менеджера
4. Админу разрешается всё
5. Менеджеру разрешается просматривать только продукты с категориями 1, 2, 3, с датой отгрузки = вчера или сегодня.

Это элементарнейшая безопасность, детский сад просто. Набрал попкорна.

skyANAМСУhVostt, давай я задам тебе конкретный пример, а ты ответишь, как нужно решать его.Можно я за него:hVosttкто мыслит исключительно конкретными задачами, пусть сразу пишет себе полностью собственный фреймворк под свою конкретную задачу и не задает глупых вопросов

hVostt, разумеется, хотелось бы увидеть реализацию на IActionFilter :)

P.S. Только не говори нам, что опять бизнес требование у меня идиотское и архитектура задачи - говно