3.運維平臺之賬戶系統
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
3.運維平臺之賬戶系統