如何最好地处理 ASP.NET 成员资格中的权限（而不是角色），特别是在 ASP.NET MVC 中

发布于 2024-09-10 22:23:09 字数 920 浏览 9 评论 0原文

关于设置 asp.net 会员资格、角色提供者等有很多问题（和信息）。您是否应该使用微软提供的内置平台，或者角色扩展基类并扮演您自己的角色。

我决定扩展默认提供程序并实现我自己的成员资格和角色提供程序。现在我的问题是专门围绕角色身份验证的。

传统上，您可能会创建“经理、管理员、员工、超级用户”等角色或任何您拥有的角色。但是，对于我认为是更精细控制的权限，您会/应该做什么？让我详细说明一下......

在我的 asp.net mvc 站点中，我有不同的区域，如管理、管理、消息传递、报告等。我会为每个区域创建角色，如“管理员”、“经理”、“报告者”等。如果没有适当的角色，您将无法访问网站的该区域。所以我会在类级别锁定整个控制器。

但现在以一个地区为例；消息传递，并说我想要对 CRUD 拥有更细粒度的权限；创建消息、查看/阅读消息、编辑消息、删除消息等。

最后是我的问题。如何最好地实施这种更精细的控制？我看到的一种方法（不确定这是否是一种好的方法）是为所有内容创建 asp.net 成员角色。所以我可能有......

Messenger（广泛的角色），CreateMessage，ReadMessage，EditMessage，DeleteMessage。

一方面，我希望一些用户能够阅读/查看消息。但不一定要创建或删除它们。各个控制器操作可以应用特定的角色。

您认为这种方法有什么问题吗？你有更好的主意吗？

到目前为止的解决方案

我决定创建自己的架构并实现自定义成员资格和角色提供程序。我的架构包括；

用户
UserProfile
权限
PermissionAssignment
角色
RoleAssignment

将在接下来的一两天内离开，但当我有机会时会更新更多信息。

原文

There are plenty of questions (and information) on setting up asp.net membership, role providers and the like. Whether or not you should use the built in platform provided by microsoft, or role extend the base classes and role your own.

I have decided to extend the default providers and implement my own membership and role providers. Now my question, is specifically around role authentication.

Traditionally, you would create roles maybe like 'Manager, Administrator, Employee, Super User' or whatever you have. But what would/should you do with respect to permissions which I consider to be a finer grain of control? Let me elaborate....

Within my asp.net mvc site I have different areas like administration, management, messaging, reporting etc. I would crate roles for each of these like 'Administrator', 'Manager', 'Reporter' etc. Without the appropriate role, you can't gain access to that area of the site. So I would lock down the entire controllers with this at the class level.

But now take one area as an example; messaging, and say I wanted to have finer grain permissions for CRUD; create a message, view/read messages, edit messages, delete messages etc.

Finally my question. How would it be best to implement this finer grain of control? One approach I see (not sure if it is a good one), is to just create asp.net membership roles for everything. So I might have....

Messenger (broad level role), CreateMessage, ReadMessage, EditMessage, DeleteMessage.

On one hand I would like some users to be able to read/view messages. But not necessarily create or delete them. Individual controller actions could have the specific roles applied.

Do you see any problems with this approach? Do you have a better idea?

Solution So Far

I have decided to create my own schema and implement custom membership and role providers. My schema includes;

User
UserProfile
Permission
PermissionAssignment
Role
RoleAssignment

Going to be away for the next day or two but will update with more information when I get a chance.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

羞稚 2024-09-17 22:23:09

我认为你应该忘记授权机制上的角色，而是请求权限（最后角色是权限的聚合），所以如果你这样看，你的 Authorize 属性应该请求一个实体和动作，而不是针对特定角色。类似于：

[Authorize(Entities.Message, Actions.Create)]
public ActionResult CreateMessage()

[Authorize(Entities.Message, Actions.Edit)]
public ActionResult EditMessage()

[Authorize(Entities.Message, Actions.View)]
public ActionResult ViewMessage()

这样您的角色就可以做他们最擅长的事情，抽象权限集合，而不是确定不灵活的访问级别方式。

编辑：为了处理像 David Robbins 指出的那样的特定规则，经理 A 不允许删除经理 B 创建的消息，假设他们都有访问此控制器操作所需的权限，则授权为不负责检查此类规则，即使您尝试在 Action Filter 级别检查也会很痛苦，因此您可以做的是将 Authorize 验证扩展到 ActionResult （注入保存验证结果的操作参数），并让 ActionResult 在所有参数就位的情况下做出逻辑决策。

这是一个类似的问题，并不完全是这里指出的情况，但它是使用操作参数扩展授权验证的一个很好的起点。

I think you should forget about roles on the authorization mechanism, ask for permissions instead (at the end a role is an agrupation of permissions), so if you look it that way, your Authorize Attribute should ask for an entity and action, not for a particular role. Something like:

[Authorize(Entities.Message, Actions.Create)]
public ActionResult CreateMessage()

[Authorize(Entities.Message, Actions.Edit)]
public ActionResult EditMessage()

[Authorize(Entities.Message, Actions.View)]
public ActionResult ViewMessage()

That way your roles do what they do best, abstract permissions collection instead of determining a inflexible way of access level.

EDIT: To handle specific rules like the one pointed by David Robbins, Manager A is not allowed to delete messages created by Manager B, assuming they both have the required permission to access this Controller Action, the Authorize is not responsible to check this type of rules, and even if you try to check that at Action Filter level it will be a pain, so what you can do is extend the Authorize validation to the ActionResult (injecting an action parameter holding the validation result), and let the ActionResult make the logic decision there with all the arguments in place.

This is a similar question, is not exactly the case pointed out here, but its a good starting point on extending the Authorize validation with Action Parameters.

回复收藏 0 原文