gpt4 book ai didi

php - 基于分层角色/权限的访问

转载 作者:可可西里 更新时间:2023-11-01 06:33:00 25 4
gpt4 key购买 nike

我想构建一个分层角色库访问控制。
这是我当前的架构:
enter image description here

目前我有两种选择来构建这个系统:

  • 将所有必需的权限附加到角色(非分层)
    enter image description here
  • 仅附加特殊的“级别”权限并继承具有较低级别的权限
    enter image description here

  • 是否有更好的方法或仅取决于我的项目需求?

    我倾向于选择 Hierarchical 只是因为简单。如果我这样做,是否有更好的方法来选择权限级别,也许使用二进制数?

    选项 2 将有一些角色级别,我将有一些权限级别编号。因此,当我创建一个 Full Administrator该角色将继承所有其他权限,因为这将是 4 级,而其他权限的数字将小于 4 级(或 4000)。

    这是矫枉过正吗?

    最佳答案

    我建议采用“方法#1”的变体 - 非分层角色。
    我使用过类似的系统并取得了巨大的成功。虽然起初这种方法可能看起来“结构性较差”,但它相对简单且非常灵活;当允许每个用户多个角色并定义聚合权限的规则时。
    反对层次结构(对于角色)
    像“OO 层次结构”一样,使用角色层次结构会导致严格的替换关系。这使得根据不断变化的需求定义角色变得更加困难。
    例如, future 可能需要一个无法创建自己帖子的“管理员”帐户。层次结构(及其具有的替代关系)在不更改树结构本身的情况下防止了这种情况,因为“完全管理员”是“付费用户”。
    SQL 中针对真实层次结构的查询更为复杂;特别是在不支持递归查询的实现中,比如 MySQL。使用嵌套集或物化方法切换到层次结构会强制使用额外的结构而不是父子关系。
    你只是不需要它;软件越复杂,编写和维护就越困难。虽然层次结构在某些情况下非常好 - 例如 Material list 或系谱或目录结构 - 在大多数角色/组权限模型中根本没有“需要”。
    对于(多)角色
    没有“父类型”依赖性的角色,其功能更像是“OO 接口(interface)”——好吧,也许 Trait composition如果类比被拉长会更合适。每个角色的实现(阅读:授予的权限)可以独立于任何其他角色而改变,使其非常灵活。和接口(interface)一样,可以将多个角色分配给给定的用户/实体。
    平盘查询 User <M-M> Role <M-M> Permission SQL 中的模型要简单得多(有或没有递归支持或附加结构),因为根本没有要遍历的角色层次结构。
    Windows ACL Groups (让我们忽略嵌套组)与角色很相似;一个用户属于一个或多个授予(或拒绝,但这是一种不同的情况)权限的组。
    有你的蛋糕,也吃它
    我建议并在上面暗示的变体是允许跨角色聚合权限。一个简单的聚合模型是这样的:

  • 用户具有来自他们分配的所有角色的权限的联合。
    (有效权限一般会在授权时建立,但没有层次结构,在SQL中查询也相对简单。)

  • 因此,每个角色的权限绑定(bind)很少或没有重叠,如“方法#2”所示,区别在于:没有层次结构。
    例如,要允许可以搜索帖子(并删除“坏”帖子)的特殊管理员,只需分配“基本用户” “有限管理员”角色1。
    使用非层次结构的多角色系统可以实现这一点,摆脱层次结构的负担,同时仍然提供灵活/可组合/可配置的角色原型(prototype)。

    1 这不是一个特别好的例子。实际上,角色应该有不同的名称(例如“帐户支持”或“内容管理员”)并涵盖不同的权限集;这些可能会根据反复试验和每月的业务规则而随着时间的推移而改变。
    虽然我反对这样的层次结构,但在更复杂的系统中,可能需要允许角色之间的关系,主要是为了对此类进行分组。这种关系通常应独立于为其他管理目的而应用的有效许可。

    关于php - 基于分层角色/权限的访问,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/32233393/

    25 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com