RBAC架構 Role 與 Menu 的設計規劃 (下)

規劃資料表的串接，以及權限檢核方式

資料表的ER-Model簡單架構如下

綠色框就是組成選單樹的結構，而紅色框則是串接出角色(Role)有哪些API功能。

因此我們可從用戶擁有的角色，知道該角色綁定的page讓前端秀出對應選單，也可得知他有哪些API權限可以呼叫。

至於前面的需求5,7,8 

5. 權限要有時限
7. 控制頁面的讀與寫也需由權限控制
8. 要檔下沒權限直接打API的情況

需求 5 的部分可以看role_data的紅字，只需要給角色一個起訖日期即可，期限外該角色即失效即可。

需求 7 的部分也不算複雜，在存API資料時只要多紀錄該API是讀或寫，當處理角色綁定頁面時紀錄頁面是否read_only，檢核時就可根據read_only的資訊來判斷呼叫API的讀寫了。

而前端也可以在產生畫面時，判斷read_only欄位，若是唯讀則可動態調整畫面的按鈕，隱藏部分[新增][修改]等功能。

下圖為此專案平台的一個功能，當[唯讀]跟[可寫入]的差別

   可寫入

唯讀

需求 8 的部分其實前面已經講得差不多了，已經有角色和API的資訊了，看要使用AOP之類的概念來檢核都行；而我們的平台是使用微服務，因此有用到BFF(Backend For Frontend)來統一檢核。

BFF當中使用cache來掃入所有的role和api的mapping，每當用戶呼叫時就可以快速應對是否有權限來呼叫，再透過Spring Cloud Gateway來打到各個微服務。

大概是這樣，後續會再寫一篇描寫BFF中是如何使用Jwt進行Token加解密，以及Spring Cloud Gateway的用法。