我编写了一些复杂的 MVC 应用程序，它们都是基于角色并使用 .NET 成员资格。在我的第一个项目中，我使用的角色结构与此类似：
我很快发现它的可扩展性不太好，例如客户会说“我希望特定用户 x 拥有所有经理权限，但不删除”。然后我必须在该用户的控制器中进行黑客攻击。
因此，我的第二个实现导致了这种角色结构：
- CanCreate
- CanDelete
- CanEditAll
- CanEditOwn
然后，这种方法根据他们是否可以全局编辑特定项目或仅编辑自己的项目等，导致实际上数十个角色。它还导致更多的控制器操作和更多的代码 - 尽管这可能只是复杂应用程序中的情况！
我的问题是，我是否以正确的方式处理这个问题，是否有任何好的在线资源可以以“正确”的方式处理具有大量角色的复杂应用程序。我这样做正确吗？
I've written a few complex MVC applications which are all role based and use .NET Membership. On my first project I used roles with structure similar to this:
I quickly discovered that wasn't very scalable, for example a customer would say "I want specific user x to have all manager privileges but not delete". I would then have to put a hack in the controller for that user.
Therefore, my second implementation led to this role structure:
- CanCreate
- CanDelete
- CanEditAll
- CanEditOwn
This approach then led to literally dozens of roles based on whether they could edit particular items globally or just their own etc. It also leads to a lot more controller actions and considerably more code - though maybe thats just the case in a complex application!
My question is, am I approaching this in the correct way, and are there any good online resources on the "correct" way to approach complex applications with loads of roles. Am I doing this correctly?
发布评论
评论（2）
事实上，这是一个非常有趣的话题，我发现自己也遇到了和你一样的问题。
我读过 Derick Bailey 的有趣博客，内容是“不要进行基于角色的授权检查；进行基于活动的检查”：http://lostechies.com/derickbailey/2011/05/24/dont-do-role-based-authorization-checks-do-activity-based-checks/
但没有时间我自己去试验一下。
Indeed it's very interesting topic and I found myself struggling with the same problems as you do.
I read Derick Baileys interesting blog about that "Don’t Do Role-Based Authorization Checks; Do Activity-Based Checks" : http://lostechies.com/derickbailey/2011/05/24/dont-do-role-based-authorization-checks-do-activity-based-checks/
but had not time to experminet it myself.
从这个问题问起一年后，我在各个项目中以不同的方式处理事情。我现在坚持使用以下经典角色：
，但操作方法本身返回如下数据：
然后由存储库中的角色处理哪些内容可见、哪些内容不可见的逻辑。首先基本上不会向数据库查询受限项目。
基本的东西，但我觉得我应该自己跟进。
A year on from this question I handle things a different way across projects. I'm now sticking to the classic roles of:
BUT the action methods themselves return data like this:
The logic for what is viewable and what is not is then handled by roles in the repository. The database will essentially never be queried for the restricted items in the first place.
Basic stuff but felt I should follow up on myself.