网站权限的思考

## 网站权限的思考 网站需要一个root用户，root用户其实根本不存在，表中没有的，UID为0的，什么超级管理员啊之类的，其实还是受权限控制的，root是不受权限控制的。 由于root没有UID，所以涉及一些操作有添加用户的这样的操作，那么就有问题了，所以必须为root配置一个关联的用户ID，这样root操作时是以这个用户的身份的，不过不受权限系统和登录系统的控制。 > 计算机安全中，有个常规的原则是：用户只能访问他们当前需要的东西。 > > **权限管理的思想就是要遵从最小访问原则。** * * * * * ### 账号？账户？身份？角色 > 说到账号，一般想到的是人注册的带密码的账号，就像QQ账号。账户，比如一个人到银行开一个银行账户，也可以理解为账号的意思，但是有时又不是账号，比如一张银行卡也可以叫一个银行账户，这个词有多种意思。身份，身份是比角色更上一层的对象，比如商家和会员是两种不同身份，而商家的接单员、客服则是一种角色。一般不同身份从属不同账号体系，同一身份下的不同角色从属同一账号体系，当然这是一般情况。有时可以同一平台账号，统一通行证，一个账号（通行证）可以拥有多个身份的账户。 * * * * * ### 身份与角色 身份和角色是一个东西吗？ 传统的RBAC、AUTH权限认证，基于的是角色，或者说是用户组，实现的功能就是不同的用户组有不同的权限（规定了哪些操作有权限访问，哪些操作没有权限访问），然后用户从属于用户组，这样用户也就被授予了不同的权限了，一个用户可以同时从属多个用户组，与用户组的关系是明显的多对多的关系。 这种权限系统在有些时候好像不太能满足需求，比如一个系统中有这样几种用户： - 管理员 - 用户 - 商家 - 骑手 - 代理 …… 这样的系统可以说每个模块独立，但是又是属于一整个系统的，那么这种情况下如果把这几种用户的划分看成是用户组也就是角色就不太好办了，并且这几种用户可能都有各自独立的用户表，像这种用户的种类，应该是身份，而不是角色，而每种身份下面又可以再分角色，比如管理员用户下面可以再分，编辑、客服等角色。 所以角色是身份的子集。 一般角色是根据运营策略可以随时手动增删编辑的，角色的权限也是可以随时手动调整的，并且所能编辑的权限其实是系统固定的，一般是基于url访问，有控制器才有对应的权限控制。所以这么来看的话，那么这种角色是系统应用层功能性的（可以手动设置，就像是应用里面的一个功能，和其它功能设置无异）。 而身份是系统架构层的，是一开始就确定了的，用户在不同的表里面，并且相互独立，基本没有关系。 还有一种权限控制，比如什么情况下哪种用户可以操作，那种角色可以做什么，身份或者角色的不同而显示不同的内容等等，这种更加灵活，细致的权限控制，并且是根据运营策略的，这样的情况很多时候都是直接在代码中**硬编码实现的**，这类权限其实要加个引号了“权限”。因为RABC的权限是指对url访问控制的权限，而显然这类权限过于宽泛了，显然不在ABAC这种权限控制之类，所以使用权限控制很难做到这种精细的控制。 总之这个界限没有很明确的划分，要根据实际情况做出最合理的解决方案，没有最好的，只有最合适的。 补充：虽然身份和角色有不同，但是注意有时候存在多重身份的情况。即一个用户拥有多种身份。 **总结：** 身份不等于角色，角色是身份的子集。 权限控制有正对于url访问权限的，也有更加灵活的控制，界限比较宽泛，有时很难做到明确的划分和标准，需要根据实际情况来选择最合适的解决方案。 * * * * * ### 角色与权限节点 角色与权限节点可以增加一个状态开关字段  * * * * * ### 什么是用户？ 需要登录的叫用户，用户管理其它资源，拥有其他资源，比如店铺表，店铺不是用户，比如微信公众号表，公众号不是用户，企业表，企业不是用户，应用表，应用不是用户，学校表，学校不是用户，……。 这些都不是用户，那什么是用户呢，管理员是用户，比如店铺管理员账号，一个店铺可能有多个管理员。而一个账号也可能管理多个企业（比如企业微信，钉钉）。 那些不是用户的东西都是资源，资源是要被用户管理的，他们的关系可能是多对多的关系。 用户在任何时候都是确定的，独立的个体。 并且不只是用户才是独立的个体，任何东西都可以是独立的个体，有时资源也是独立的个体，这取决于你是怎么管理和使用它的。 >[danger] 成员是一个个体，是一个独立的人，一个独立的账号，而家长不是啊，家长是一种抽象的身份，张三可以是两个孩子的爸爸，能龙这么做从根本上就错了。（来自家校平台的案例） * * * * * ### 账户设计 一个人就是一个独立的个体，独立的账户，其他的比如一个人可以有好几个店铺，一个人可以有好几辆车，一个人名下也可以有好几套房子，……。 而有的东西可以同时属于多个人的，比如房产证上可以有多个名字，可以几个人合伙开一个店，此时房子和店铺与人的关系就是多对多的关系了。银行卡不同，一个人可以有多张银行卡，但是一个银行卡不能同时从属多个人，此时是一对多的关系。而身份证与人是一对一的关系，一个人只能有一个身份证，一个身份证也只能代表一个人。 不管是多对多，还是一对多，或是一对一，我们发现，所有的东西都是从属、附属于人的。以人为本，以人为中心，这就是账户设计的原则和准心，任何账户，账号的问题都从这个角度去思考就清楚了。 * * * * * ### auth权限 auth是基于规则的权限，规则为字符串，可以是：`is_show_btn`，没有任何限制， 但是很少这样用，是否显示什么按钮，前端判断就可以了，根本不需要用到这种权限控制，权限控制只需要控制后台的具体操作就可以了，也就是 `m/c/a`了。 后台需要进行权限控制的地方，直接拦截验证当前 `m/c/a` 规则就可以了。 所以规则基本都是当节点用的，即：`m/c/a`。 * * * * * ### 权限设计的思考 菜单跟权限规则表应该分开，分开解耦，两者并没有必然联系，不应一起设计，增加复杂度。 角色是扁平的，没有上下级，一个系统里面不会有很多角色。权限规则为了方便管理，可以是分级的。 root是最高级管理员，不受权限系统控制。 而超级管理员，尽管拥有全部权限，但也只是all而已，根本上还是属于权限系统管理。root不能被删除，超级管理员可以被删除，但是不能自己删除自己，并且系统必须保证至少有一个超级管理员或者root，root不是属于权限管理系统中的角色，是在配置文件中定义的，所以不能删除管理。 超级管理员的角色也不能删除。系统所必须的角色。 增加个字段，系统角色，不能删除，和管理。 一般只有root才进行节点添加，因为这涉及到开发，不是系统使用者所能做的，比如开发人员可以直接进数据库改节点都可以，除了root以外的其它所有角色和用户都是系统的使用者，系统的使用者就会受系统管理。 * * * * * ### 敏感操作/重要操作 root管理员确认 非root管理员进行敏感操作或者重要操作时，需要得到root管理员的短信验证码才能继续，比如创建短信群发任务等等。 * * * * * ### 扩展 [前端真的能做到彻底权限控制吗？](https://www.toutiao.com/a6507461805135102478/?tt_from=weixin&utm_campaign=client_share×tamp=1515145091&app=news_article&utm_source=weixin&iid=22069500288&utm_medium=toutiao_android&wxshare_count=1) [基于 Token 的 WEB 后台认证机制](https://mp.weixin.qq.com/s/QDr4DaMrH-g78l5oXFfbeg) last update：2018-5-19 23:20:56