在 .NET MVC 应用程序中“深入”角色有多远？答案

【问题标题】：How far to 'drill down' roles in a .NET MVC application?在 .NET MVC 应用程序中“深入”角色有多远？
【发布时间】：2011-09-25 01:23:47
【问题描述】：

我编写了一些复杂的 MVC 应用程序，它们都是基于角色并使用 .NET Membership。在我的第一个项目中，我使用了类似于以下结构的角色：

我很快发现这不是很可扩展，例如，客户会说“我希望特定用户 x 拥有所有管理员权限，但不删除”。然后，我必须在控制器中为该用户添加一个 hack。

因此，我的第二个实现导致了这个角色结构：

然后，这种方法会根据他们是否可以全局编辑特定项目或仅编辑自己的项目等来产生字面上 数十个 的角色。它还导致更多的控制器操作和相当多的代码 - 尽管可能在复杂的应用程序中就是这样！

我的问题是，我是否以正确的方式处理此问题，是否有任何好的在线资源以“正确”方式处理具有大量角色的复杂应用程序。我这样做对吗？

【问题讨论】：

【解决方案1】：

确实这是一个非常有趣的话题，我发现自己也遇到了和你一样的问题。

我阅读了 Derick Bailey 的有趣博客，关于“不要进行基于角色的授权检查；要进行基于活动的检查”：http://lostechies.com/derickbailey/2011/05/24/dont-do-role-based-authorization-checks-do-activity-based-checks/

但没时间亲自体验。

【讨论】：

【解决方案2】：

从这个问题开始一年后，我在不同项目中处理事情的方式不同。我现在坚持以下经典角色：

但是操作方法本身会返回如下数据：

var order = or.MyVisibleOrders().FirstOrDefault(x => x.Id == Id);

然后由存储库中的角色处理可见和不可见的逻辑。数据库基本上不会被首先查询受限项目。

基本的东西，但我觉得我应该跟进自己。

【讨论】：