資源權限： 菜單導航欄 & 頁面 & 按鈕 資源可見權限
數據權限： 對於頁面上的數據操作 同一個人同一個頁面 不同的數據 可能存在不同的數據操作權限
權限緯度
角色緯度 用戶 => 角色 => 權限
用戶緯度 用戶 => 權限
表現形式
基礎表現形式還是樹結構的展現形式 因爲對應的 菜單 - 頁面 - 按鈕 是一個數的從主幹到節點的數據流向
XX
出於實際工作的需要，很多項目(尤其類似後臺管理系統)需要引入權限控制.倘若權限架構設計的不好 或者沒有涉及 會導致項目中各種權限代碼混入業務代碼 造成結構混亂,其次想給新模塊引入權限控制或者功能擴展都會十分棘手.
雖然前段在權限層面能做一些事情,但是很遺憾真正對權限進行把關的是後端.例如一個軟件系統,前端在不寫一行代碼的情況下,當用戶進入到某個他無權訪問的頁面時,後端是可以判斷他越權訪問並拒絕返回數據的,由此可見 即使前端不做什麼 整個系統也是可以正常運行的 但是這樣應用的體驗很不好.另外一個很重要的就是前端做的權限校驗都是可以被本地數據造假越權通過的
前端如果能判斷某用戶越權訪問頁面時 就不要讓他進入那張頁面後在彈出無權訪問的信息提示 因爲這樣體驗會很差 最優方案是直接關閉那些頁面的入口 只讓他看他能夠訪問的內容 這樣即使他通過輸入路徑惡意訪問 導航最後也只會將它帶到默認頁面 || 404 page
前端做的權限控制大抵是先接受後臺發送的權限數據 然後將數據注入到整個應用中 整個應用於是開始對頁面的展現內容以及導航邏輯進行控制 從而達到權限控制的目的 前端做的權限控制雖然能提供一層防護 但根據目的還是爲了優化體驗
頁面權限控制
頁面權限控制要探討的問題是 如何給不同角色賦予不同的頁面訪問權限
一旦軟件系統引入了角色的概念 那麼每個賬戶在註冊之後就會被賦予相應的角色 從而擁有相應的權限 這裏要注意 前端依據的客體是角色 不是某個賬戶 因爲賬戶是依託於角色的 真正落地到前端項目中是不需要去處理角色邏輯的，那部分功能主要由後端完成
當用戶登陸成功之後 通過接口返回值得知用戶數和所屬角色 拿到角色值後就去配置文件取出該角色所能訪問的頁面列表數組 （可在後端做對應配置） 隨後將這部分數據加載到應用中從而達到權限控制的目的