简介
我正在设计基于应用程序角色权限的访问系统。 在我的系统中，我有以下角色：
例如，让我们查看用户与“任务”实体的关系。
Worker 和 Customer 是非常特殊的角色，他们几乎只能访问自己的任务。 Workers 只会看到'task'对象的少数属性。 根据系统业务规则，在某些情况下，他们将能够更新一个或两个属性。
Root 用户可以做任何事情，它可以创建，更新，读取，删除“任务”。 Office管理员可以列出，更新和创建“任务”。 审核员只能列出任务。
Root ，审核员和 Office管理员可以访问相同（完整）的“任务”实体属性集。 这三种用户类型将通过相同的管理界面（Web应用程序模块）访问系统。
客户将通过单独的面向角色的模块（客户模块）访问系统，功能太具体。 工人 - 也是（工人模块）。
因此，使用上述示例，我们可以说我们可以为Root，Auditor和Office manager创建以下权限：
这适用于他们，但不适用于客户和工作人员。 对于 Worker ，我们可以这样做：
......等等。
但对于我来说，这个意义很小。 没有其他人，但工人将使用此权限。 此外，无法使用权限来描述Worker能够编辑“任务”实体的某些属性的条件。
摘要
所以，我得出结论，我需要一个混合访问控制系统。 客户和工作人员将成为没有任何权限的角色。 Root，Auditor和Office manager将成为具有绑定到每个角色的权限集的角色。
最后，我们可以将此类机制称为基于权限和角色的混合访问系统。
问题
有这样的设计是正常的吗？ 我错误的想法吗？ 或者最好使用非常详细的权限列表来描述 Customer 和 Worker logic （尽可能多）？
答案 0 :(得分：1)
我可能不会做这样的事情只是因为它似乎无法长期维持。
在组织内，为各种工作职能创建角色。 执行某些操作的权限被分配给特定的 角色。分配成员或员工（或其他系统用户） 特定角色，并通过这些角色分配获得 计算机权限以执行特定的计算机系统功能。 由于用户未直接分配权限，而只是获取权限 他们通过他们的角色（或角色），管理个人用户 权利成为简单地为其分配适当角色的问题 用户的帐户;这简化了常见操作，例如添加 用户，或更改用户的部门。
参考：https://en.wikipedia.org/wiki/Role-based_access_control
您还可以实施ACL（访问控制列表）
关于计算机文件系统的访问控制列表（ACL）， 是附加到对象的权限列表。 ACL指定哪个 用户或系统进程被授予访问对象的权限，以及 给定对象允许的操作。[1] a中的每个条目 典型ACL指定主题和操作。例如，如果是 file对象有一个包含的ACL（Alice：read，write; Bob：read）， 这将使Alice有权读取和写入文件以及Bob 只读它。
我通常更喜欢ACL实现，因为它们可以提供更精细的控制。
参考：https://en.wikipedia.org/wiki/Access_control_list
看了你的想法，看起来你想要实际实现ACL。通过模板加载每个用户权限。当然，你可以随时实现这两种方法，但这通常只是过分杀戮，之后你或多或少会拥有Windows操作系统的安全模型。