## 權限設計
權限其實蠻復雜的,這里不同用戶,不同類型的使用者都有各自的權限,特別是還涉及到企業微信成員對應用的權限控制。
根據使用對象,我們需要分為幾個層面來分別設計權限控制。
>[danger] 權限做得復雜可以很復雜,很完善,也可以做的很簡單,初期簡單、有效就可以了,不需要做的太復雜。不然就犯了“過早地把系統設計得太復雜”的問題,這和“過早的優化性能是萬惡之源”差不多。
* * * * *
### 思考
~~~
有一些東西是基礎設施,比如班級管理,有一些是應用,真是傻傻分不清。
還是一刀切算了,直接用應用做,必須班級管理就是應用。
煩,系統,應用,管理,權限,企業微信應用,還沒有很好的設計出他們的關系,煩!!!
再來看應用權限
應用前臺針對于成員,后臺針對于管理員。
同時還有常規的節點權限,應用權限(應用管理/可見權限和應用節點權限)
對于后臺管理來說,應用是學校管理員、老師的使用權限(可見權限和后臺節點權限)
對前臺使用來說,應用是成員的使用權限(可見權限和前臺節點權限)
~~~
### 擴展思考
權限分為兩類:
后臺權限,和前臺權限。
后臺權限是管理員權限,各項操作或者應用的功能權限。
前臺權限是成員使用應用的權限,包括應用可見權限(這個由企業微信成員通訊錄可見范圍控制),和應用功能的控制。
~~~
-- 權限要注意的是,不僅要控制可見,也要控制實際的應用權限,因為即使應用不可見,用戶還是能記住url使用應用,所以要做真實的權限控制
-- 目前接口不能設置應用的可見范圍,但是也沒事,畢竟應用的使用人群是固定的,比如事先就規定,“校長信箱”只能是家長使用的,那么業務員前期的準備工作就是做這些,將“校長信箱”的可見范圍設置為家長部門,我們要做的就是控制誰加入家長這個部門就行了,權限以這種思路來做,如果以后接口支持更強大就方便多了。
-- 【應用更細化的權限控制】(細化到操作)(不同角色可能有統一模塊的可見權限,但是具體的操作權限可能不同)
-- 【成員】
-- 前臺 應用可見權限(細化到部門和成員,上面已經實現)
-- 前臺 操作權限(細化到部門和成員)
-- 【學校管理員】
-- 后臺 應用可見(管理)權限(細化到角色和賬號)
-- 后臺 操作權限(細化到角色和賬號)
-- 【老師】
-- 后臺 應用可見權限(細化到角色和賬號)
-- 后臺 操作權限(細化到角色和賬號)
-- 應用權限規則(節點,注意這個分為前臺和后臺) 表
-- 部門/角色/成員/賬號 & 規則 關聯 表
~~~
* * * * *
### 成員 權限
成員(老師,家長),應用的可見權限,和應用的節點權限。
* * * * *
### 學校管理員 權限(不是老師)
管理員應用的可見權限,和應用節點的權限。
還有常規的節點權限。
* * * * *
### 學校老師 權限
老師應用的可見權限,和應用的節點權限。
同樣有常規的節點權限。
(老師和學校管理員類似,也可以管理學校,本可以設計為學校管理員表中的一個角色,但是由于老師和家長一樣,都是前臺的使用者,都是成員,所以比較特殊,為了方便管理,所以**老師用戶賬號**表就是成員表,和學校管理員分開設計了。)
**學校中的老師不是用戶,成員才是用戶,學校中的家長不是用戶(一個人可以為好幾個學生的家長,甚至可以為好幾個學校的學生的家長),對應的成員才是用戶,理解這個很重要,這是身份于賬號的關系,賬號是獨立的個體,而身份是依附于賬號的。**
* * * * *
### 最終的權限設計
- 應用權限
- 常規權限
**應用權限:**
<table>
<tr >
<th rowspan="2" style="color:red;">應用權限</th>
<th colspan="2" align="center" style="text-align:center;">前臺</th>
<th colspan="2" align="center" style="text-align:center;">后臺</th>
</tr>
<tr>
<th>可見權限</th>
<th>節點權限</th>
<th>可見權限</th>
<th>節點權限</th>
</tr>
<tr>
<th rowspan="2">權限</th>
<td>成員的可見權限</td>
<td>成員的節點權限</td>
<td>管理員的可見權限</td>
<td>管理員的節點權限</td>
</tr>
<tr>
<td></td>
<td></td>
<td>老師的可見權限</td>
<td>老師的節點權限</td>
</tr>
</table>
**常規權限:**
<table>
<tr >
<th rowspan="2" style="color:red;">常規權限</th>
<th align="center" style="text-align:center;">前臺</th>
<th align="center" style="text-align:center;">后臺</th>
</tr>
<tr>
<th>節點權限</th>
<th>節點權限</th>
</tr>
<tr>
<th rowspan="2">權限</th>
<td></td>
<td>管理員的節點權限</td>
</tr>
<tr>
<td></td>
<td>老師的節點權限</td>
</tr>
</table>
前臺都是應用,所以只有應用權限沒有常規權限。權限都是在后臺設置。(設置權限 的 程序節點 是 常規權限 的 節點權限)
**<span style="color:red;">這些節點需要自己創建(系統定義),而應用的節點需要開發者提供,如:</span>**
`XX操作:do=xxAction`
>[danger] 權限節點(應用如果要支持精細的權限節點,就可以進行配置)
* * * * *
### 關于內建應用 的權限
內建應用可能沒有應用后臺,而是通過系統后臺直接管理的。
所以內建應用的節點規則可能包含了應用前臺和系統后臺,或者應用后臺。
總之內建應用比較靈活,不像常規應用那么標準。
內建應用定義 **非常規的應用節點** 時怎么定義呢?
常規定義是:`XX操作:do=xxAction`
如果內建應用想定義 **非常規的應用節點** 是這樣定義的:
直接定義完整節點就可以:module/controller/action
* * * * *
### 權限控制所需要的表
#### 應用權限
**節點權限**
- 成員(前臺)-應用權限節點 關聯表:`學校ID,應用ID,節點名稱(XX操作),節點名(前臺xxAction),成員ID`
- 管理員(后臺)-應用權限節點 關聯表:`學校ID,應用ID,節點名稱(XX操作),節點名(后臺xxAction),管理員ID`
- 老師(后臺)-應用權限節點 關聯表:`學校ID,應用ID,節點名稱(XX操作),節點名(后臺xxAction),老師ID(其實是成員表ID)`
(應用節點一般比較少,所以這里沒有角色,用戶直接和節點關聯)
**可見權限**
- 成員(前臺)-應用可見權限表:`學校ID,應用ID,obj_id,type(部門或成員ID)`
- 管理員-應用可見權限表:`學校ID,應用ID,管理員ID`
- 老師-應用可見權限表:`學校ID,應用ID,老師ID(其實是成員表ID)`
應用權限需要6張表。
#### 常規權限
管理員節點權限(auth的四張表)
老師的權限節點表(auth的四張表)
* * * * *
last update:2017-9-21 14:06:25