我如何建模（GitHub的）权限关系？ [英] How do I model (GitHub-like) permissions relationally?

查看：127
本文介绍了我如何建模（GitHub的）权限关系？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

tl; dr：我如何实现一个权限模型（例如github的）



@ philipxy的评论：



我计划实现类似于github的权限模式：


  1. 用户

  2. 用户可以分组

  3. 用户可以在组织中

  4. 组可以在组织中

  5. 用户将被允许对资产，组或组织的任何C，R，U和D操作 ：


    1. 允许个人用户（C，R，U，D中的任何一个）操作

    2. 已授予这些权限的组织成员

    3. 已授予这些权限的组织成员




      4. 的组织成员
    4. 由于资源/组/ org对匿名用户（公开）可见（可读），因此用户被授予读取

    5. 用户还应具有一组权限他们是否可以对权限执行任何C，R，U或D（用户可以为另一个用户，组或组织创建权限[C，R，U，D]）


      1. ，用户可以为其创建的任何资产，组或组织设置权限，也可以为其授予权限的任何资产，组或组织设置权限。 li>


    这些权限将控制谁可以执行创建，读取，更新和删除）对网站中资产，群组和组织的操作。



    我如何建模这个？



    显然我有这些模型：


    1. 资产

    2. 用户

    3. 组

    4. 组织

    下一步是什么？


    1. 权限？

    2. PermissionType（用于捕获C / R / U / D）？

    mysql从节点（通过sequelize），但我可以找出具体的语法一个我自己，我只是还没有想出如何做到这个概念上。



    strong>更多到@ philipxy的观点：



    你提出的事情我做的更多的事情是我想我要求帮助。也就是说，那些信息设计方法（NIAM，FCO-IM，ORM2，IDEF1X）是我正在寻找的。我知道关系数据库实现（学习规范化和正常形式的日子和其他），但确实，指定业务需求和将它们转换为可操作的规范的过程是一个挑战。




    • ORM2 很难找到，因为与nodejs模块发生名称冲突。 ：我已下载从 NIAM维基百科页面链接的图书
      • $ b
    • IDEF1X：看起来很有趣



    我想我要拿起一本数据库教科书。 >

    更多关于谓词的工作：


    1. U 标识用户

    2. A c>资产

    3. G 标识组

    4. a 用户 U 可以为0或更多群组 G

    5. 标识组织

    6. a 用户 / code>可以在0或更多组织 O

    7. 组组可以在0或更多 O

    8. 资产 A c> User U

    9. CRUD 资产：


      1. 实体 E 允许（通过权限 P ？）执行操作 Ac 资产

      2. 这些操作分别是：


        1. 创建

        2. >

        3. 更新

        4. 删除


      3. 实体可能是以下类型：


        1. 用户

        2. >

        3. 组织

        4. 匿名用户 /public


      4. 详细资料（仅显示 Read 但也与创建，更新和删除相关：


        1. a 用户 U0 另一个用户 U1 到读 >资产 A

        2. a code> U0 可以允许用户 U 谁是 code> A

        3. a 用户 U0 可以允许用户 U 谁是 <至 > A

        4. 用户 c $ c>在群组 G1 ，其中 G1 在组织 中的组允许读取 资产 A c $ c>阅读 资产 A

          5. < ol 引用资产 A 的c $ c>只能由某些用户创建：


          1. 默认情况下， User U code> Entity 可为 Entity ，
            2. 创建权限
          2. ，但他们只能引用资产，它们具有权限 创建 c
            3. c $ c> E 在许可
          3. Gr 标识 Grant


            1. a Grant 给予实体创建，读取，更新或删除权限的引用另一个 Entity

            2. 如权限， Grants 具有传递性质：


              1. 如果组织 code>已授予授予授权（例如）修改权限 E ，

              2. 不仅可以用户 O 修改权限引用 E


                1. 而且用户谁是组 G 其中 G 位于 O 有权修改权限引用 E


              3. h2_lin>解决方案

谓语和表格



命题这是真或假的业务情况。 谓词是一个列参数化语句，给定一行给出命题。表（基本或查询结果）保存从其谓词提出真正命题的行。例如：



用户（具有ID）U具有名称N

用户U有权更新资产A

grantor R授权人E允许设保人E在可疑货物上使用CRUD类型的运营商

受让人E的类型为用户，且受让人E有权更新资产



业务规则



业务规则是定义术语或描述策略或流程的始终真实的语句。 p>

用户由其检查清除时分配的ID唯一标识。

可原因是资产，组或组织。

设保人是用户，组，组织。

用户可以在组织中。



您可以创建属于无参数谓词的真语句。这些可以使用由FOR ALL&对于某些（存在）。



用户是设保人。



- FOREIGN KEY用户（U）参考资格授予者（U）

适用于所有U值N，用户（U，N）IMPLIES授予者（U）



不要将规则与谓词混淆。它们有不同的形式。规则是一个真正的语句;谓词是一个参数化语句。 （规则和谓词只对应于也是数据库约束的规则。）看看我的答案如何分离它们。基表和查询结果表有谓词。但是一个规则可能建议你需要一个基本谓词/表来记录一些东西。当我们从规则中看到我们必须记录关于当前情况的一些语句时，我们写基本谓词。注意一些规则没有启发基本谓词。



您可能希望 类型和权限：



用户是用户类型的授权人。

命名为C的权限是受让人创建可评估的权限。



已授予者（名称为E）的类型为「使用者」

权限（含有ID）P的类型为「CRUD」

授予者R给可疑C上的类型CRUD的许可P



设计是找到必要的&足够的规则基本谓词



  1. ol>

U标识用户



  1. 使用者可以分组




用户U在组G



  1. 用户可以在组织中


用户U在组织O



  1. 群组可以在组织中


O表示组织

组G在组织O



< blockquote>


  1. 用户将被允许对资产，组或组织进行CRUD操作


A识别出一种可资料类型'asset'

允许用户U对可疑C执行CRUD操作


5.1作为单个用户，或作为组的成员，或作为组织的成员（或作为组的成员属于具有权限的组织），


P表示组织O允许

对可疑C


进行CRUD操作，或者因为资产/组/ org对匿名用户/ p>

crudable C is public



  1. 用户还应具有一组权限，以说明他们是否可以设置上述权限


grantor R有权设置可疑C的CRUD权限？



什么是上述权限？也许你的意思是用户CRUD权限和组织CRUD权限？也许你的意思是有操作C，R，U& D？您需要更清楚。



一组权限中的权限是什么？也许你的意思是授予用户CRUD权限和授予组织CRUD权限？也许你的意思是有操作C，R，U& D，所以集中的权限是允许某些受委托者（用户或组织）的某些CRUD操作的权限？通过许可在这里你真的是指特定的受权人的特别许可？你需要更清楚。



更清楚的方法是给予规则&谓词尽可能简单，但也不那么简单，因此不提及相关实体/值。你可能随后想推广多个规则&谓词变成单一的。例如，而不是处理用户，组，组织和资产，有设保人和遗嘱：授予人可以授予权限& 授予人R向授权人E授予许可P。如果某些此类权限也与特定受赠者相关联，您可能还需要授予者R赋予授权者P授权者授权许可Q和授予者F。


6.1。用户可以为其创建的任何资产，组或组织设置权限


用户U创建的可靠C


或任何资源，群组或机构，他们已获得权限设定权限。


用户U有权限设置可疑C的权限P？



您将要记录类似用户U具有名称N和...的内容。



了解数据库设计



搜索数据库/ SQL子类型/继承/多态性习语。我已经使用一个为可怜的;用户，组和组织是权限拥有者的类型。你可能想要一个类型的权限givers：替换组织O有权限P& 用户U具有许可P，被许可者E的类型为'被许可者'和许可者E具有许可P。 （组织&用户是受助者。）也许你想要某种类型的权限目标类型是可靠的U受助者。也许你想要的权限类型。也许一些权限的权限有关联的被授予者。也许C，R，U& D是权限，CRUD是一种权限类型。



稍后我们可以通过连接替换表，如果连接在共享的PK / UNIQUE上，并且具有相同的两者中的值集合。当我们可以加入一个PK / UNIQUE-FK时，我们可以用一个像他们的连接一样替换表，但是FK是空的。但首先要识别基本谓词。



了解关系数据库设计。遵循一些信息设计方法。最好的是NIAM / FCO-IM / ORM2系列的成员。看看IDEF1X。不要依赖产品。



了解约束。他们遵循谓词和业务规则。它们是关于谓词可能的商业情况的真理。等同地，它们是关于表的可能的数据库状态的真值。还了解SQL中的约束，包括声明性（PK，UNIQUE，FK）已触发。


tl;dr: how do i implement a permissions model like (e.g.) github's

Updated to try to address some of @philipxy's comments:

I am planning to implement a permissions model similar to github's:

  1. users
  2. users can be in groups
  3. users can be in organizations
  4. groups can be in organizations
  5. a user will be permitted any of C, R, U, and D operations on an asset, group, or organization as:

    1. an individual user who has been permitted those (any of C, R, U, D) operations
    2. a member of a group which has been granted those permissions
    3. a member of an organization that has been granted those permissions

      1. or as a member of a group where that group belongs to an org that has permissions

  6. a user is granted Read because the asset/group/org is viewable (readable) to anonymous users ("public")
  7. a user should also have a set of permissions to say whether they can do any of C, R, U, or D on the permissions (a user can create a permission[C,R,U,D] for another user, a group, or an org)

    1. a user can set the permissions for any asset, group, or org they create, or any asset, group, or org for which they have been given permission to set permissions.

These permissions will control who can perform Create, Read, Update, and Delete (CRUD) actions on assets, groups, and organizations in the site.

Approximately how do I model this?

Obviously i have these models:

  1. Asset
  2. User
  3. Group
  4. Organization

What next?

  1. Permission?
  2. PermissionType (to capture C/R/U/D)?

I am using mysql from node (via sequelize), but I can figure out specific syntax an all that myself, I just haven't yet figured out how to do this conceptually.

More to @philipxy's point:

The very thing you are proposing I do more of is indeed the thing I think I'm asking for help with. That is, those info design methods (NIAM, FCO-IM, ORM2, IDEF1X) are what i'm looking for. I know a decent amount about relational db implementation (days of learning normalizing and normal forms and whatnot), but indeed the process of specifying business requirements and converting them into actionable specs is the challenge.

  • ORM2 is difficult to find because of name collisions with the nodejs module. : I have downloaded the book linked from the NIAM wikipedia page
  • NIAM seems to be less common in usage nowadays?
  • FCO-IM: I have downloaded the book from their website
  • IDEF1X: also looks interesting

I guess I'm going to pick up a database text book.

More work toward predicates:

  1. U identifies a User
  2. A identifies an Asset
  3. G identifies a Group
  4. a User U can be in 0 or more Groups G
  5. O identifies an Organization
  6. a User U can be in 0 or more Organizations O
  7. a Group G can be in 0 or more Organizations O
  8. an asset A can be created by a User U
  9. CRUD on Assets:

    1. an Entity E can be permitted (through Permission P ?) to perform actions Ac on Assets
    2. those Actions are:

      1. Create
      2. Read
      3. Update
      4. Delete

    3. the Entity may be of types:

      1. User
      2. Group
      3. Organization
      4. Anonymous User/"the public"

    4. details (shown only for Read, but also relevant for Create, Update, and Delete):

      1. a User U0 can permit another User U1 to Read an Asset A
      2. a User U0 can permit Users U who are members of Group G to Read an Asset A
      3. a User U0 can permit Users U who are members of Organization O to Read an Asset A
      4. Users U in Group G1, where G1 is a Group that is in an Organization O that has been permitted to Read Asset A, are therefore permitted Read Asset A

  10. a Permission P that references an Asset A may only be created by certain users:

    1. By default, the User U who is the creator of an Entity can create Permissions for that Entity,
    2. but they may only reference Assets to which they have Permission (in the base case: those Assets create by U)
    3. a User who as been Grant(?)ed the privilege can also reference Entity E in a Permission
    4. Gr identifies a Grant

      1. a Grant gives an Entity the privilege to create, read, update, or delete Permissions that reference another Entity
      2. like Permissions, Grants have a transitive nature in that:

        1. if Organization O has been Granted the privilege to (e.g.) modify Permissions for Entity E, then
        2. not only may Users who are members of O modify Permissions referencing E,

          1. but also Users who are members of any Group G where G is in O have the privilege to modify Permissions referencing E

解决方案

Predicates and tables

A proposition is a statement that is true or false of a business situation. A predicate is a column-parameterized statement that given a row gives a proposition. A table (base or query result) holds the rows that make a true proposition from its predicate. Eg:

user (with id) U has name N
user U has permission to update asset A
grantor R gave permission to grantor E to use an operator of type 'CRUD' on crudables
grantee E is of type 'user' AND grantee E has permission to update assets

Business rules

A business rule is an always-true statement that defines a term or describes a policy or process.

A user is uniquely identified by an id assigned when their cheque clears.
A crudable is an asset, group or organization.
A grantor is a user, group, organization.
Users can be in organizations.

You can make true statements that are parameterless predicates. These can use parameter names that are bound by FOR ALL & FOR SOME (THERE EXISTS). Business rules phrased in terms of such propositional predicates and/or table names are database constraints.

A user is a grantor.

-- FOREIGN KEY User (U) REFERENCES Grantor (U)
FOR ALL U, FOR SOME value for N, User(U, N) IMPLIES Grantor(U)

Don't confuse rules with predicates. They have different forms. A rule is a true statement; a predicate is a parameterized statement. (Rules & predicates only correspond for rules that are also database constraints.) Look at how my answer separates them. Base tables and query result tables have predicates. But a rule may suggest that you need a base predicate/table to record something. We write base predicates when we see from a rule that we have to record some statements about the current situation. Note some rules inspire no base predicates.

You probably want to reify types and permissions:

A user is a grantor of type 'user'.
Permission named 'C' is permission for a grantee to create a crudable.

grantee (with name) E is of type 'user'
permission (with id) P is of type 'CRUD'
grantor R gave permission P of type 'CRUD' on crudable C to grantee E

Design is finding necessary & sufficient rules & base predicates

  1. users

"U identifies a user"

  1. users can be in groups

"G identifies a group"
"user U is in group G"

  1. users can be in organizations

"user U is in organization O"

  1. groups can be in organizations

"O identifies an organization"
"group G is in organization O"

  1. a user will be permitted CRUD operations on an asset, group, or organization

"A identifies a crudable of type 'asset'"
"user U is permitted CRUD operations on crudable C"

5.1 as an individual user, or as a member of a group, or as a member of an organization (or as a member of a group where that group belongs to an org that has permissions),

"P identifies a permission"
"organization O is permitted CRUD operations on crudable C"

or because the asset/group/org is viewable (readable) to anonymous users ("public")

"crudable C is public"

  1. a user should also have a set of permissions to say whether they can set the above permissions

"grantor R has permission to set CRUD permission for crudable C"?

What are "the above permissions"? Maybe you mean user CRUD permission and organization CRUD permission? Maybe you mean there are individual permissions for actions C, R, U & D? You need to be clearer.

What are the permissions in "a set of permissions"? Maybe you mean permission to give user CRUD permissions & permission to give organization CRUD permissions? Maybe you mean there are individual permissions for actions C, R, U & D, so the permissions in the set are the permissions permitting some CRUD action to some grantee (user or organization)? By "permission" here do you instead really mean "particular permission to a particular grantee"? You need to be clearer.

The way to be clearer is to give rules & predicates that are as simple as possible but also not so simple that they don't mention relevant entities/values. You may afterwards want to generalize multiple rules & predicates into single ones. Eg instead of dealing with users, groups, organizations and assets, have grantors and crudables: "Grantors can grant permissions" & "grantor R gives permission P to grantee E". If some such permissions are also associated with specific grantees you might also need "grantor R gives permission P to grantee E re permission Q and grantee F".

6.1. a user can set the permissions for any asset, group, or org they create,

"user U created crudable C"

or any asset, group, or org for which they have been given permission to set permissions.

"user U has permission to set permission P for crudable C"?

You will want to record things like that "user U has name N and ...".

Learn about database design

Search re database/SQL subtyping/inheritance/polymorphism idioms. I have already used one for crudables; user, group and organization are types of permission possessors. You probably want a type for permission givers: replace "organization O has permission P" & "user U has permission P" by "grantee E is of type 'grantee'" and "grantee E has permission P". (Organizations & users are grantees.) Maybe you want some kind of permission target type that is crudable U grantee. Maybe you want types of permissions. Maybe some permission permissions have associated grantees. Maybe C, R, U & D are permissions, and CRUD is a type of permission. You probably want to record what grantor gave what permission to a grantee.

Later we can replace tables by their join if the join is on a shared PK/UNIQUE with the same set of values in both. When we can join on a PK/UNIQUE-FK we can replace tables by one like their join but with the FK nullable. But first identify basic predicates.

Learn about relational database design. Follow some information design method. Best are members of the the NIAM/FCO-IM/ORM2 family. Peek at IDEF1X. Don't rely on products.

Learn about constraints. They follow from predicates and business rules. They are truths about possible business situations in terms of the predicates. Equivalently, they are truths about possible database states in terms of the tables. Also learn about constraints in SQL, both declarative (PK, UNIQUE, FK) & triggered.

这篇关于我如何建模（GitHub的）权限关系？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
其他数据库最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆