我正在一个网站上工作，该网站将有几个模块，这些模块要么对某些用户完全可用，要么对其他用户半可用，而对其他用户不可用。
例如：
此外，如果当前用户是管理员或经理，在某些页面上还会显示一些附加字段。 （例如删除/标记事物的链接）。这些不会向员工展示。
我想创建一个“权限”模型，该模型将处理以下逻辑：
我需要一些设计此类的建议/建议，特别是它应该具有哪些方法来完成第二个要求。
I'm working on a site, which will have several modules that either fully available to certain users, semi available to other users, and unavailable to the rest.
For example:
-
An 'employee' is able to respond to the customer support tickets assigned to him.
-
A 'Manager' is able to manage all employees and support tickets in his team, including viewing the tickets of a specific employee.
-
An 'Admin' is able to manage all managers, employees, and tickets in all teams, as well as some other core functionality.
In addition, on some pages there will be some additional fields shown if the current user is an admin or manager. (E.g links to delete/flag things). These won't be shown to employees.
I want to create one 'Permissions' model which will handle the logic for:
-
Determining if a user can access the current page or not.
-
Determining whether a particular part of a page should be displayed or not. (E.g special links for editing/deleting to be shown to admins and managers only).
I need some recommendations/advice for designing this class, particularly what methods it should have in order to accomplish the 2nd requirement.
发布评论
评论（3）
当这个问题出现时，我处理这个问题的方法是给出可以采取的每个操作或可以显示其自己的
权限的信息。每个用户都有一个权限集合。由此，您可以添加其他结构层来帮助管理将存在的大量权限，例如权限的层次结构或类别。一旦到位，您可以让各个部分询问
User他们是否拥有所需的权限，或者您可以让PermissionManager接受>用户和一组权限并确定给定用户是否具有所需的权限。无论哪种方式都可以正常工作，但是您选择哪一种会对系统的依赖关系和体系结构产生影响。PermissionManager方法的优点是您的应用程序片段不需要依赖于User，因此您可以使用始终使用不同的PermissionManager如果没有合适的权限，则返回False；如果所有权限都合适，则返回True。对于简单的情况，这种方法可能有点矫枉过正，而且一开始看起来似乎确实如此，但我已经走了使用基本分层或粗粒度角色的路线，并且喜欢几乎我工作过的每个系统都很快变得太对于大多数普通的、预构建的基于角色的权限系统来说很复杂。
The way I have approached this problem when it has come up is to give each action that can be taken or piece of information that can be shown it's own
Permission. EachUserthen has a collection ofPermissions. From this, you can add other layers of structure to help manage the huge number of permissions that will exist, such as hierarchies or categories of permissions.Once that is in place, you can either have the various parts ask the
Userif they have the needed permission(s), or you can have aPermissionManagertake aUserand a set ofPermissionsand determine if the given user has the neededPermissions. Either way will work fine, but which one you choose has an impact on dependencies and the architecture of your system.The
PermissionManagerapproach has the advantage that your application pieces don't need to depend on aUser, so you could use a differentPermissionManagerthat always returnsFalseif no permissions is appropriate, orTrueif all permissions is appropriate.For simple situations, this approach can be overkill, and it often seems like it is at first, but I've gone the route of using basic hierarchical or coarse-grained Roles and fond that virtually every system I've worked on quickly got too complicated for most vanilla, pre-built Roles-based permission systems.
从数据库的角度来看，我解决这个问题的方法是拥有一个保存用户列表的用户表，一个保存角色列表的角色表，例如：员工、经理、管理员；权限表存储系统中可用的每个操作/功能的所有值及其对特定角色的权限，例如：对于管理员来说，创建、编辑、删除、查看等操作/功能的值都是 true。这些关系如下所示，而 (N) ---- (N) 是多对多关系。
用户 (N) -------- (N) 角色 (N) -------- (N) 权限
My approach to this problem from database point of view would be to have a user table which holds the list of users, a role table for the list of roles, e.g.: employee, manager, admin; and permission table which stores all of the values of every action/feature available in the system and its permission for a specific role, e.g.: say for admin, the values for actions/features like create, edit, delete, view are all true. The relationships can be seen below whereas (N) ---- (N) is a many-to-many relationship.
Users (N) ------- (N) Roles (N) -------- (N) Permission
我的印象是，您需要使用员工、经理和管理员等角色。因此，包含这些内容的角色表就可以了。然后，对于特定的操作/权限，您必须使用分支逻辑，例如对于您将拥有的员工
if User.IsInRole("员工")
// 插入逻辑来处理客户支持票证
else if User.IsInRole("经理")
// 插入处理经理职责的逻辑
，最后插入处理管理员职责的逻辑
因此，您需要用户表和角色表来实现此目的。
希望有帮助
My impression is that you would require to make use of roles e.g. employee, Manager, and Admin. So a roles table with these would do. Then for the particular actions/permisions you would have to make use of branching logic i.e. for example for the employee you will have
if User.IsInRole("employee")
// insert logic to deal with customer support tickets
else if User.IsInRole("manager")
// insert logic to deal with manager responsibilities
and finally logic to deal with admin responsibilities
So you need both the users table and the roles table to achieve this.
Hope it helps