Как лучше всего обрабатывать разрешения (не роли) в членстве asp.net, особенно в ASP.NET MVC

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

Я решил расширить поставщиков по умолчанию и реализовать свои собственные поставщики членства и роли. Теперь мой вопрос, конкретно о роли аутентификации.

Традиционно вы можете создавать роли, например, «Менеджер, Администратор, Сотрудник, Суперпользователь» или что-то еще. Но что бы вы сделали / должны сделать в отношении разрешений, которые я считаю более точным контролем? Позвольте мне уточнить ....

На моем сайте asp.net mvc у меня есть различные области, такие как администрирование, управление, обмен сообщениями, создание отчетов и т. Д. Я бы выделил роли для каждой из них, такие как «Администратор», «Менеджер», «Репортер» и т. Д. Без соответствующей роли вы можете получить доступ к этой области сайта. Так что я бы заблокировал все контроллеры с этим на уровне класса.

Но теперь возьмем одну область в качестве примера; обмен сообщениями, и сказать, что я хотел иметь более мелкие разрешения для CRUD; создавать сообщения, просматривать / читать сообщения, редактировать сообщения, удалять сообщения и т. д.

Наконец мой вопрос. Как лучше было бы реализовать это более тонкое зерно контроля? Один из подходов, который я вижу (не уверен, что он хороший), - просто создать роли членства в asp.net для всего. Так что я мог бы иметь ....

Messenger (роль общего уровня), CreateMessage, ReadMessage, EditMessage, DeleteMessage.

С одной стороны, я хотел бы, чтобы некоторые пользователи могли читать / просматривать сообщения. Но не обязательно создавать или удалять их. Для отдельных действий контроллера могут применяться определенные роли.

Видите ли вы какие-либо проблемы с этим подходом? У тебя есть идея получше?

Решение пока что

Я решил создать свою собственную схему и внедрить настраиваемое членство и поставщиков ролей. Моя схема включает в себя;

пользовательПрофиль пользователяразрешениеPermissionAssignmentРольRoleAssignment

Собираюсь отсутствовать на следующий день или два, но буду обновлять с дополнительной информацией, когда я получу шанс.

Ответы на вопрос(1)

Ваш ответ на вопрос