## 網站權限的思考
網站需要一個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
- 開始
- 開發工作流
- 優秀的設計資源
- 網站權限的思考
- 好習慣
- TODO
- 你就是想得太多,做得太少
- 思考
- 產品設計
- 為什么需要設計
- 使用體驗
- 插畫設計
- 產品價值
- 時間機器
- 有跡可尋
- 設計怎么做的高大上?
- 交互狀態
- 過度效果
- 把用戶體驗做到極致是種什么體驗?
- 用戶都是沒有耐心的
- 用戶是小白
- 默認頭像
- 用戶價值的沉淀
- 專注-極致
- 簡潔
- 界面的思考
- 聆聽用戶反饋
- 常見問題
- 匿名私密性
- 產品與心理學
- 用戶心理
- 人性
- 商業
- 容錯性
- 回歸本真
- 權限-隱私
- 簡單就是最好的
- 個性化
- 無負擔使用體驗
- 用戶消息通知系統
- 用戶私信會話系統
- 友好的提示設計
- 從細節之處讓用戶愛上你
- 擬人情感化
- 任務機制
- 網賺模式
- 好看的顏色
- 免費激勵
- 操作記錄
- 用戶動態
- 回收站
- 二級密碼
- 產品與人的思考
- 產品運營
- 解決方案
- 項目立項
- 雞賊設計
- 空頭支票營銷法
- 陰暗設計
- 信息與大腦
- 驅動性
- 安全
- 解決方案與產品的區別以及關系
- 自動修正用戶錯誤
- 產品研發的三個階段
- 什么是好的產品
- 運營
- 警惕設計上的漏洞
- 心得體會
- 無極生太極
- 回歸本質
- 設計可以不用那么糾結
- 業務與技術
- 開發感想
- 人生苦短,來不及找尋所有答案?
- 人活著的意義
- 談開源
- 代碼與詩
- 心理
- 困擾
- 關于糾結
- 其它思考
- 獸爺|疫苗之王
- 記錄
- 哲學
- 宇宙
- 沒有絕對完美的系統
- 先賢
- 生命的意義
- 心即宇宙