權限設計 · 家校平臺

## 權限設計權限其實蠻復雜的，這里不同用戶，不同類型的使用者都有各自的權限，特別是還涉及到企業微信成員對應用的權限控制。根據使用對象，我們需要分為幾個層面來分別設計權限控制。 >[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