在现实的企业Web应用中，我们总是需要通过用户的单位和角色来限制对数据的访问。
假设我们有一家企业公司，在一个国家/地区拥有许多购物商店。
因此，公司总部可以查看所有分支机构的所有发票和统计数据。全国各区域负责管理和规划本分支机构的区域销售策略。然后该地区的用户还可以看到其分支机构已创建的所有发票。每个分支机构都可以创建发票、客户，并且只能查看其数据。
我们可以看到我们有两个主要的访问控制定义：
1-角色（多年前就已经考虑和实现了！）：我们可以使用 RoleProvider 轻松实现并在 UI 级别（web.config 和 sitemap.config）控制访问控制)
2- 拒绝/授予用户更新/查看数据访问权限的单元及其与角色的关系。
我在 ASP.NET 中实现了一个自定义主体来获取用户的单位和角色，但我认为应该有一个经典的解决方案......
In real-world enterprise web applications for enterprise businesses, we always need to limit the access to the data by the user's unit and role.
Consider that we have an enterprise company with many shopping stores in a country.
So the company has headquarter which has view access to all invoices and statistics for all branches. Each region in the country manages and plans the regional sales strategies for its own branches. Then the region's user also can see the all invoices which have been created by its branches. Each branch can create invoice, customer, and view only its data.
We can see that we have two main access control definitions:
1- Roles (which has been thought and implemeneted many years ago!): we can easily implement using RoleProvider and controlling the access control in UI level (web.config and sitemap.config)
2- Units and its relation with roles to deny/grant the user access to update/view data.
I have implemented a custom principal in ASP.NET to get the user's unit and roles, but I think there should be a classic solution...
发布评论
评论（1）
查看这些：
http://netsqlazman.codeplex.com/discussions/352107
http://lostechies。 com/derickbailey/2011/05/24/dont-do-role-based-authorization-checks-do-activity-based-checks/
这是我的解释。
http://granadacoder.wordpress.com/2010/ 12/01/rant-hard-coded-security-roles/
............
MembershipProvider 基于 ROLES，.... 这适用于您孩子的足球俱乐部。 ..不是专业的 DotNet 应用程序。
有一个“中间立场”的解决方法。
http://www.lhotka.net/weblog /CommentView,guid,9efcafc7-68a2-4f8f-bc64-66174453adfd.aspx
基本上。使用 MembershipProvider……但将单词/短语“角色”视为“正确”。 （在你看来..你当然不能更改 MS 代码中的对象名称）
Rocky's NuTSHELL （来自上面的 url）
bool result = currentPrincipal.IsInRole(requiredPermission);
Check these out:
http://netsqlazman.codeplex.com/discussions/352107
http://lostechies.com/derickbailey/2011/05/24/dont-do-role-based-authorization-checks-do-activity-based-checks/
Here is MY explanation.
http://granadacoder.wordpress.com/2010/12/01/rant-hard-coded-security-roles/
............
The MembershipProvider is based on ROLES,....and that is for your kid's soccer club...NOT a professional DotNet application.
There is a "middle ground" workaround.
http://www.lhotka.net/weblog/CommentView,guid,9efcafc7-68a2-4f8f-bc64-66174453adfd.aspx
Basically. Use the MembershipProvider......but treat the word/phrase "Role" as "Right". (In your mind..you cannot change the names of objects in MS code of course)
Rocky's NUTSHELL ( from url above)
bool result = currentPrincipal.IsInRole(requiredPermission);