關於前後端分離開發中的許可權處理問題，鬆哥之前寫過一篇文章和大家聊這個問題：

• Spring Boot + Vue 前後端分離開發，許可權管理的一點思路

但是最近有小夥伴在學習微人事專案時，對動態選單這一塊還是有疑問（即不同使用者登入成功後會看到不同的選單項），因此鬆哥打算再來寫一篇文章和大家聊一聊前後端分離開發中的動態選單問題。

1. 一個原則

做許可權管理，一個核心思想就是後端做許可權控制，前端做的所有工作都只是為了提高使用者體驗，我們不能依靠前端展示或者隱藏一個按鈕來實現許可權控制，這樣肯定是不安全的。

就像使用者註冊時需要輸入郵箱地址，前端校驗之後，後端還是要校驗，兩個校驗目的不同，前端校驗是為了提高響應速度，優化使用者體驗，後端校驗則是為了確保資料完整性。許可權管理也是如此，前端按鈕的展示/隱藏

都只是為了提高使用者體驗，真正的許可權管理需要後端來實現。

這是非常重要的一點，做前後端分離開發中的許可權管理，我們首先要建立上面這樣的思考框架，然後在這樣的框架下，去考慮其他問題。

因此，下文我會和大家分享兩種方式實現動態選單，這兩種方式僅僅只是探討如何更好的給使用者展示選單，而不是探討許可權管理，因為許可權管理是在後端完成的，也必須在後端完成。

2. 具體實現

一旦建立起這樣的思考框架，你會發現動態選單的實現辦法太多了。

動態選單就是使用者登入之後看到的選單，不用角色的使用者登入成功之後，會看到不用的選單項，這個動態選單要怎麼實現呢？整體來說，有兩種不同的方案，鬆哥曾經做過的專案中，兩種方案也都有用過，這裡分別來和大家分享一下。

2.1 後端動態返回

後端動態返回，這是我在微人事中採用的方案。微人事中，許可權管理相關的表一共有五張表，如下：

其中 hr 表就是使用者表，使用者登入成功之後，可以查詢到使用者的角色，再根據使用者角色去查詢出來使用者可以操作的選單（資源），然後把這些可以操作的資源，組織成一個 JSON 資料，返回給前端，前端再根據這個 JSON 渲染出相應的選單。以微人事為例，我們返回的 JSON 資料格式如下：

[
    {
        "id":2,
        "path":"/home",
        "component":"Home",
        "name":"員工資料",
        "iconCls":"fa fa-user-circle-o",
        "children":[
            {
                "id":null,
                "path":"/emp/basic",
                "component":"EmpBasic",
                "name":"基本資料",
                "iconCls":null,
                "children":[

                ],
                "meta":{
                    "keepAlive":false,
                    "requireAuth":true
                }
            }
        ],
        "meta":{
            "keepAlive":false,
            "requireAuth":true
        }
    }
]
 

這樣的 JSON 在前端中再進行二次處理之後，就可以使用了，前端的二次處理主要是把 component 屬性的字串值轉為物件。這一塊具體操作大家可以參考微人事專案（具體在：https://github.com/lenve/vhr/blob/master/vuehr/src/utils/utils.js），我就不再贅述了。

這種方式的一個好處是前端的判斷邏輯少一些，後端也不算複雜，就是一個 SQL 操作，前端拿到後端的返回的選單資料，稍微處理一下就可以直接使用了。另外這種方式還有一個優勢就是可以動態配置資源-角色以及使用者-角色之間的關係，進而調整使用者可以操作的資源(選單)。

2.2 前端動態渲染

另一種方式就是前端動態渲染，這種方式後端的工作要輕鬆一些，前端處理起來麻煩一些，鬆哥去年年末幫一個律所做的一個管理系統，因為許可權上比較容易，我就採用了這種方案。

這種方式就是我直接在前端把所有頁面都在路由表裡邊定義好，然後在 meta 屬性中定義每一個頁面需要哪些角色才能訪問，例如下面這樣：

[
    {
        "id":2,
        "path":"/home",
        "component":Home,
        "name":"員工資料",
        "iconCls":"fa fa-user-circle-o",
        "children":[
            {
                "id":null,
                "path":"/emp/basic",
                "component":EmpBasic,
                "name":"基本資料",
                "iconCls":null,
                "children":[

                ],
                "meta":{
                    "keepAlive":false,
                    "requireAuth":true,
                    "roles":['admin','user']
                }
            }
        ],
        "meta":{
            "keepAlive":false,
            "requireAuth":true
        }
    }
]

這樣定義表示當前登入使用者需要具備 admin 或者 user 角色，才可以訪問 EmpBasic 元件，當然這裡不是說我這樣定義了就行，這個定義只是一個標記，在專案首頁中，我會遍歷這個陣列做選單動態渲染，然後根據當前登入使用者的角色，再結合當前元件需要的角色，來決定是否把當前元件所對應的選單項渲染出來。

這樣的話，後端只需要在登入成功後返回當前使用者的角色就可以了，剩下的事情則交給前端來做。不過這種方式有一個弊端就是選單和角色的關係在前端程式碼中寫死了，以後如果想要動態調整會有一些不方便，可能需要改程式碼。特別是大專案，許可權比較複雜的時候，調整就更麻煩了，所以這種方式我一般建議在一些簡單的專案中使用。

3. 結語

雖然我在微人事中使用了第一種方式，不過如果小夥伴是一個新專案，並且許可權問題不是很複雜的話，我還是建議嘗試一下第二種方式，感覺要方便一些。

不過在公司中，動態選單到底在前端做還是後端做，可能會有一個前後端團隊溝（si）通（bi）的過程，贏了的一方就可以少寫幾行程式碼了。

關注公眾號【江南一點雨】，專注於 Spring Boot+微服務以及前後端分離等全棧技術，定期視訊教程分享，關注後回覆 Java ，領取鬆哥為你精心準備的 Java 乾貨！

相關推薦