我這邊的作法是直接回傳menu的路由給前端使用。
所以權限是在登入的時候就一起生成傳回給前端儲存。
當然了，因為cookie的容量問題。我並不是儲存在cookie上。

畢竟我是採用vue的應用。基本上來說變數並不會消失。也沒有換頁方面的問題存在。
真的重整頁面了，就再請求一次就好。

至於請求安全性的問題。畢竟我是採用 Middleware 的做法。在token存在的同時，本身也會緩存對應的權限資料。並不會特別再去請求db處理。

如果突然有在後台重新調整權限之類的動作。早前的做法是會全部對應的人重置緩存。
但隨著後期的人數變多。
後來就採用將人員登出處理。(並不是全部，而是有對應的群組才做處理)
他們重新登入。其實前端重整也會拿到新的設定權限。
但丟出重整的命令總是不好。

現在正在研究新的做法，要搭配 winsock 來處理。還沒研究完全。

1. 使用者的Menu權限應該在登入後從DB取得後，同時寫一份到快取（可用MemoryCache or Redis），如果該使用者的權限被更動，再清除快取並重複前述的動作。 另外也可以考慮簡化儲存Menu權限的方式到Cookie，例如 101000 表示使用者擁有第一個主功能底下的第二個子功能的權限。 當然也要對JWT的的claim作檢查。
2. 如果同時登入的peak requests太高，可考慮在非尖峰時間用排程預先將整理好的權限資訊寫入快取。 小弟之前在撈個人的公司組織階層的時候，是搭配Hangfire+Redis(可參考此篇文章)，不然每個人登入時，光是從DB取得組織階層就要數秒。 不過快取的保留和更新時間和資料高度相關，以組織的例子來說，通常異動最快會到隔日才生效。