历程:
0. 账户系统(accounts)分为用户认证和权限分配两部分.
1. 刚开始运维平台业务比较单一,只提供给运维组人员使用即可,根本没有用户账号的概念.
2. django系统本身有用户、用户组、权限,需要进行一些扩展开发,以满足需求.
在16年独立出用户认证注册模块,形成accounts项目,简单API认证.
3. 在17年时,前端设计获得很大突破,基于Django实现RBAC权限管理.
需求:
1.需要用户认证和角色权限管理,实现资源控制访问.
2.基于用户-角色-权限数据链,在多模块应用下,维护使用必须便捷实用.
3.权限的粒度控制,不仅仅到达URL,关联资源且基于角色的权限控制.
所有开发通过接口/url/进行发布, 开发A只允许处理项目资源A, 开发B只允许处理项目资源B.
4.由于权限控制不严谨,对系统资源的重启、删除风险操作,影响业务展开.
accounts模块关系图
大概内容
0.用户认证:
0.1 用户账号信息
0.2 使用部门
0.3 用户组
1.权限设置:
1.1 权限定义和粒度控制
1.2 用户-角色-权限数据链关联
2.权限使用:
2.1 用户权限提取
2.2 用户权限实际使用.
显示内容
0.1 用户账号信息
提供基本用户信息,方便本人和其它同事查找,被运维平台其它应用调用.
每个用户提供一个独立token数据串,用于个人API接口数据推送.
0.2 使用部门
公司组织, 资源归类定位, 有些公司居然没有单位通讯录,找起来好麻烦呀.
0.3 用户组
之前工单和监控报警推送到使用部门,后期独立成用户组.
1.1 权限定义和粒度控制
每条权限条目 = URL标识(必需) + 请求方法(可选) + 参数字段(可选) + 参数字典(可选)
粒度控制怎么做,我也不懂.
#工单任务区, 并不使用url路径,而是使用url name,因为路径可变.
#所以我们使用资源封装权限标识, 而不是资源封装URL.
#数据来源 http://developer.51cto.com/art/201704/537240.htm
url(r'^task/add/(?P<id>\d+)/$', 'taskAdd', name='taskadd'),
url(r'^task/delete/(?P<id>\d+)/$', 'taskDelete', name='taskdelete'),
url(r'^task/edit/(?P<id>\d+)/$', 'taskEdit', name='taskedit'),
url(r'^task/list/(?P<key>\w*/)$', 'taskList', name='tasklist'),
1.2 用户-角色-权限数据链关联
用户通讯录只处理用户认证功能即可,并不一一权限关联;
角色处理权限管理功能, 承上多对多用户对象, 启下多对多关联权限资源,
只需要赋予相应权限用户对应角色即可.
权限资源控制粒度,独立出配置接口.
2.1 用户权限提取
可以通过传递权限标识,再去查询此用户是否有权限通过. 产生数据库操作.
也可以在用户登录时全量获取对应应用权限,全量写入用户session, 传递标识直接在session查询即可.
数据链接: http://blog.csdn.net/Ayhan_huang/article/details/78094570?locationNum=9&fps=1
2.2 用户权限实际使用
在装饰器标示在视图处理方法上时传入权限标识参数(如:@auth("user:add")),在装饰器中也是从Session中获取用户,
迭代用户的所有角色绑定的资源中的权限标识，如果与传入装饰器中的权限标识相同则放行，否则跳转到无权限的页面.
数据链接: https://my.oschina.net/harmel/blog/755544
数据链接:
<基于Django实现RBAC权限管理>http://blog.csdn.net/Ayhan_huang/article/details/78094570?locationNum=9&fps=1
<我对Django权限控制的理解>https://my.oschina.net/harmel/blog/755544
<Django之路 如何开发通用且万能的的权限框架组件>http://developer.51cto.com/art/201704/537240.htm
原文地址：http://blog.51cto.com/teemomo/2058880