如何最好地处理在asp.net中成员的权限（不是角色），特别是在ASP.NET MVC [英] How to best handle permissions (not roles) in asp.net membership, specifically in ASP.NET MVC

问题描述

有大量的问题（和信息）上设置asp.net成员，角色提供商等等。无论您是否应使用内置在微软提供的平台，或角色扩展基类和角色你自己的。

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....

在我的asp.net的MVC的网站我有像行政，管理，信息传递不同的领域，报告等。我会为这些像管理员，经理，记者等。如果没有合适的角色的角色箱，你不能访问该网站的该区域。所以我会在类级别锁定整个控制器与此有关。

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.

但现在采取一区为例;短信，说我想有CRUD晶粒细化的权限;创建一个消息，查看/阅读邮件，编辑邮件，删除邮件等。

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.

最后我的问题。它怎么会是最好地执行这种控制更精细？一种方法我看到（不知道这是一个很好的），是刚刚创建asp.net成员角色的一切。所以我可能......

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....

使者（广义级角色）的CreateMessage，ReadMessage，EditMessage，DeleteMessage可以。

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?

解决方案到目前为止

我决定创建自己的模式，并实现自定义的成员资格和角色提供。我的模式包括;

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

• 用户


• 用户配置


• 权限


• PermissionAssignment


• 角色


• RoleAssignment

将要离开或者未来一两天，但是当我有机会将与更多的信息更新。

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

推荐答案

我想你应该忘记的授权机制的作用，要求授权，而不是（在最后一个角色是权限的agrupation），所以如果你看看这样的说法，你的授权属性应该问一个实体和行动，而不是一个特定的角色。是这样的：

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.

编辑：：要处理这样一个由大卫·罗宾斯指出具体的规则，经理一个是不允许删除由管理者B创建的消息，假设它们都具有访问此控制器操作所需的权限，该授权不负责检查这种类型的规则，即使你尝试检查，在行动过滤级别这将是一个痛苦，所以你可以做什么是授权验证扩展到的ActionResult（注入动作参数持有验证结果），并让的ActionResult做出逻辑判定那里的地方所有的参数。

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.

<一个href=\"http://stackoverflow.com/questions/2872588/asp-net-mvc-authorization-permission-to-use-model-classes/2878159#2878159\">This是一个类似的问题，是不完全的情况下在这里指出，但其对扩大与操作参数的验证授权一个很好的起点。

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.

这篇关于如何最好地处理在asp.net中成员的权限（不是角色），特别是在ASP.NET MVC的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！