МСУ,

МСУНе торопи коней - идём дальше. Теперь нам нужно показывать все продукты менеджеру (Index), но доступные для редактирования (продукты с категориями 1, 2, 3, с датой отгрузки = вчера или сегодня) подсвечивать. Более того, в карточке продукта (Index/{id}) нам нужно запрещать просмотр, если категория не 1-3 и дата отгрузки <> вчера / сегодня.

Если речь идёт о доступе на уровне данных, а не только действий, бизнес-логика знает о ролях и элементах доступа.
Элементы доступа для кейса: "products/index", "products/edit". Входят в роль "manager".

IProductManagerService.GetList() возвращает для каждой записи также элементы доступа к ним для роли пользователя . Контроллер во вью передаёт модель с маркером индикации, в зависимости от элемента доступа, вью подсвечивает записи с соответствующим маркером и дает ссылку на страницу редактирования товара.

IProductManagetService.GetItem() возвращает тоже самое только в одном экземпляре по Id. действие Index/{id} контроллера вызывает вью, информирующую пользователя о том, что доступ запрещен, если нет нужного элемента доступа .

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

сократить расходы на кодинг можно, создав свой фильтр AccessAction(AccessItem = "product/edit"), действующий на событие Executed и перехватывающий вывод Result, если модель не обладает нужным AccessItem. тогда действие контроллера вообще лишается необходимости каких-либо проверок. получает данные и вызывает вью, как будто все все можно.

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

МСУ,

в бизнес-логике решать. это не задача контроллера. какие-то действия еще можно разрешать в зависимости от роли. но не в случае с данными. все что должен реализовывать контроллер, это получать данные от M, передавать их на V, получать данные от V и передавать их M. в трансфере решаются проблемы биндинга и валидации, давать доступ к данным или не давать решает М, информируя об этом контроллер, он уже рендерит нужную вью.

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

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

мой вопрос относится только к тому, когда это действительно нужно. прокидывать ссылки на сервисы — можно, но не нужно.

Где-то в степи,

я заторчал от этого коммента :)

Конечно речь не идет там расположить весь механизм какой нибудь пиздятины типа вставки удаления модификации данных и отслеживания разрешений. Но быстрый доступ к объекту который отвечает за это матерное слово - почему нет?

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

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

вы лучше поделитесь своей травой ))

МСУОн уже сам запутался в показаниях.

говори только за себя, плз. не уймешь своё чсв, да? ))

МСУДесятый раз повторяю, где хранится логика:

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

? В фильтре? А как же вью, если для конкретного условия во вью мне нужно добавить / скрыть элемент, подсветить и т.д.?

в бизнес-логике. читать умеешь? или то комменты по диагонале читаешь, увидел слово, вырвал из контекста и достебался с умным видом. очки на нос не лезут? поправь быстрей и прочитай вот это:

логика доступа к данным хранится в бизнес-логике.
логика доступа к данным хранится в бизнес-логике.
логика доступа к данным хранится в бизнес-логике.
логика доступа к данным хранится в бизнес-логике.
логика доступа к данным хранится в бизнес-логике.
логика доступа к данным хранится в бизнес-логике.
логика доступа к данным хранится в бизнес-логике.
логика доступа к данным хранится в бизнес-логике.
логика доступа к данным хранится в бизнес-логике.
логика доступа к данным хранится в бизнес-логике.
логика доступа к данным хранится в бизнес-логике.
логика доступа к данным хранится в бизнес-логике.
логика доступа к данным хранится в бизнес-логике.
логика доступа к данным хранится в бизнес-логике.
логика доступа к данным хранится в бизнес-логике.
логика доступа к данным хранится в бизнес-логике.
логика доступа к данным хранится в бизнес-логике.
логика доступа к данным хранится в бизнес-логике.
логика доступа к данным хранится в бизнес-логике.


может лучше картинку?

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


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