『壹』 後台管理系統 許可權分配前端怎麼分配
1、最簡單的就是登陸控制了。
2、然後是簡單的許可權控制到功能（頁面），這時候你需要知道數據表怎麼設計，
SQL怎麼查詢，代碼如何判斷。
3、再往上就開始考慮角色的設計。
4、考慮功能細節的控制（新增、更新、刪除、...）
5、考慮Scalability、Performance、User-Friendly....
『貳』 Vue前端用戶許可權控制大全
用戶許可權是對特定資源的訪問許可，所謂許可權控制，也就是確保用戶只能訪問到被分配的資源
介面許可權目前一般採用通用的形式來驗證(用戶是否登錄系統)，沒有的話一般返回401，跳轉到登錄頁面重新進行登錄 ,
登錄成功後拿到token，將token存起來，通過axios請求攔截器進行攔截，每次請求的時候頭部攜帶token
通過自定義指令進行按鈕許可權的判斷
自定義許可權指令
在使用的按鈕中只需要引用v-has指令
全局路由守衛里做判斷
每次路由跳轉的時候都要判斷許可權，這里的判斷也很簡單，因為菜單的name與路由的name是一一對應的，而後端返回的菜單就已經是經過許可權過濾的
如果根據路由name找不到對應的菜單，就表示用戶有沒許可權訪問
如果路由很多，可以在應用初始化的時候，只掛載不需要許可權控制的路由。取得後端返回的菜單後，根據菜單與路由的對應關系，篩選出可訪問的路由，通過addRoutes動態掛載
這種方式的缺點：
菜單需要與路由做一一對應，前端添加了新功能，需要通過菜單管理功能添加新的菜單，如果菜單配置的不對會導致應用不能正常使用
全局路由守衛里，每次路由跳轉都要做判斷
『叄』 前端如何控制用戶許可權
1. UI處理(根據用戶擁有的許可權,判斷頁面上的一些內容是否顯示)
2. 路由處理(當用戶訪問一個它沒有許可權訪問的url時,跳轉到一個錯誤提示的頁面)
3. HTTP請求處理(當我們發送一個數據請求,如果返回的status是401或者401,則通常重定向到一個錯誤提示的頁面)
如何實現?
首先需要在Angular啟動之前就獲取到當前用戶的所有的permissions,然後比較優雅的方式是通過一個service存放這個映射關系.對於UI處理一個頁面上的內容是否根據許可權進行顯示,我們應該通過一個directive來實現.當處理完這些,我們還需要在添加一個路由時額外為其添加一個"permission"屬性,並為其賦值表明擁有哪些許可權的角色可以跳轉這個URL,然後通過Angular監聽routeChangeStart事件來進行當前用戶是否擁有此URL訪問許可權的校驗.最後還需要一個HTTP攔截器監控當一個請求返回的status是401或者403時,跳轉頁面到一個錯誤提示頁面.
大致上的工作就是這些,看起來有些多,其實一個個來還是挺好處理的.
在Angular運行之前獲取到permission的映射關系
Angular項目通過ng-app啟動,但是一些情況下我們是希望Angular項目的啟動在我們的控制之中.比如現在這種情況下,我就希望能獲取到當前登錄用戶的所有permission映射關系後,再啟動Angular的App.幸運的是Angular本身提供了這種方式,也就是angular.bootstrap().看的仔細的人可能會注意到,這里使用的是$.get(),沒有錯用的是jQuery而不是Angular的$resource或者$http,因為在這個時候Angular還沒有啟動,它的function我們還無法使用.
進一步使用上面的代碼可以將獲取到的映射關系放入一個service作為全局變數來使用.
在取得當前用戶的許可權集合後,我們將這個集合存檔到對應的一個service中,然後又做了2件事:
(1) 將permissions存放到factory變數中,使之一直處於內存中,實現全局變數的作用,但卻沒有污染命名空間.
(2) 通過$broadcast廣播事件,當許可權發生變更的時候.
如何確定UI組件的依據許可權進行顯隱
這里我們需要自己編寫一個directive,它會依據許可權關系來進行顯示或者隱藏元素.
這里看到了比較理想的情況是通關一個has-permission屬性校驗permission的name,如果當前用戶有則顯示,沒有則隱藏.
擴展一下之前的factory:
路由上的依許可權訪問
這一部分的實現的思路是這樣: 當我們定義一個路由的時候增加一個permission的屬性,屬性的值就是有哪些許可權才能訪問當前url.然後通過routeChangeStart事件一直監聽url變化.每次變化url的時候,去校驗當前要跳轉的url是否符合條件,然後決定是跳轉成功還是跳轉到錯誤的提示頁面.
router.js:
mainController.js 或者 indexController.js (總之是父層Controller)
這里依然用到了之前寫的hasPermission,這些東西都是高度可復用的.這樣就搞定了,在每次view的route跳轉前,在父容器的Controller中判斷一些它到底有沒有跳轉的許可權即可.
HTTP請求處理
這個應該相對來說好處理一點,思想的思路也很簡單.因為Angular應用推薦的是RESTful風格的介面,所以對於HTTP協議的使用很清晰.對於請求返回的status code如果是401或者403則表示沒有許可權,就跳轉到對應的錯誤提示頁面即可.
當然我們不可能每個請求都去手動校驗轉發一次,所以肯定需要一個總的filter.代碼如下:
寫到這里我們就基本實現了在這種前後端分離模式下,前端部分的許可權管理和控制。
『肆』 系統許可權設計思路方法總結
幾乎所有的管理後台都會涉及到許可權的設計，許可權控制是管理後台的重要功能，可以有效的提高系統的安全性，減少誤操作、數據泄漏等風險的發生。但是，很多產品經理會對許可權功能有一點害怕的心理，一方面是由於能參考的實例較少，許可權管理算是一個「系統級」的基礎功能，一般系統中只有管理員可以操作，不像其他功能可以通過去其他系統中試用體驗，另一方面，對於許可權功能普通用戶無法操作使用，所以存在感較低，做好了也不會出彩，可沒做好就會導致整個流程不通、產品崩潰。
一 RBAC模型
目前，接受度較高的功能許可權模型是RBAC（Role-Based Access Control）模型。在RBAC中，許可權與角色相關聯，用戶通過成為適當角色的成員而得到這些角色的許可權。這就極大地簡化了許可權的管理。在一個組織中，角色是為了完成各種工作而創造，用戶則依據它的責任和資格來被指派相應的角色，用戶可以很容易地從一個角色被指派到另一個角色。角色可依新的需求和系統的合並而賦予新的許可權，而許可權也可根據需要而從某角色中回收。
1.角色的作用
如果沒有角色的概念，直接用戶對應許可權，雖然會更加靈活，但是後台的數據表設計會變得復雜，操作成本也會很高，同時容錯能力也會變得很差。
而引入「角色」概念後，用戶與角色可為多對一或多對多的關系，當一個用戶的角色為多對多時，當前用戶的許可權是多個角色的並集。此時只需要為角色賦予許可權，能夠大大減輕管理負擔，同時將用戶與許可權解耦，提供更大的靈活性，同時整個設計的容錯能力也提高了很多。
2.引入用戶組
一些大型的平台上，如果用戶數量較大，新增角色時，需要為大量用戶分配新的角色，工作量巨大，此時可以引入用戶組的概念，將這些用戶拉到同一個用戶組中，然後對整個用戶組進行角色的指定，這就大大減少了角色分配的工作量。
同理如果許可權較多時也會存在一樣的問題，對角色進行許可權設置時也需要大量的操作，此時可以考慮引入許可權組的概念，將關聯性較強的許可權大包成組賦予角色，從而減少賦值時的工作量，現實中許可權組的使用相對較少，因為系統中的許可權一般來講是有限的。需要注意的是即使有用戶組或許可權組的存在，也可以允許用戶或許可權與角色直接關聯，這個可以視具體業務情況而定。
下圖所示為mac系統中運行添加用戶組，並以用戶組為單位配置許可權。
3. 角色繼承的RBAC模型
在一個業務場景中，如果角色需區分：設計主管、設計組長、設計成員，並且管理方式為向下兼容時，則需使用角色繼承的RBAC模型。上層角色繼承下層角色的全部許可權，且可額外賦予許可權。
此時除了對角色進行定義，還需要管理角色間的關系，通過關系來體現角色的層級關系，從而達到繼承許可權的效果。角色的繼承關系主要有兩種：樹形圖和有向無環圖。
繼承關系常常來源於公司團隊的組織結構，此時常將角色與組織結構進行關聯達到繼承角色模型的效果。如下圖所示的趙同學，其角色是「三級團隊負責人」，與其並列的小組中有多個「三級團隊負責人」的角色，但依附於左側的組織結構樹，各級負責人僅有查看和操作自己下屬子節點的許可權。
4. 限制的RBAC模型
在一個產品或系統中，部分角色可能是需要隔離的、不允許被同時賦予一個人的。跟大家熟知的「不能既是『運動員』又是『裁判員』 」一個道理。
因此，對於眾多角色中的一組，只能是單選的關系，但多組角色之間可以共同存在。如下圖中，一個用戶可以既為設計師又為管理員，但在設計師角色組中僅能被賦予一個角色，在管理員角色組中也僅能被賦予一個角色。
此外，限制還有可能是數量上的，比如一個產品組中必須有且只有一個管理員，不允許刪除或再分配管理員角色，僅允許將負責人角色變更。
限制的模型不僅僅對分配過程產生影響，有時即使擁有了多種角色，因為不同的角色對同一個功能的使用方式或數據會產生沖突，所以使用時也需要進行限制。如下圖所示為同一時間僅允許以一個身份登錄。
根據不同的業務需求，限制的形式很多。需要注意的是不能僅依賴後端限制，而是要在前端展示清晰的規則和恰當的限制，避免用戶出錯和沮喪。
三、許可權的拆分與設計
通過RBAC模型已經能夠很好的搭建起用戶、角色與許可權之間的關系了。但具體是什麼樣的關系，以及「許可權」這個抽象的概念具體如何規劃？
這些都需要分析清楚才能進一步設計出完善的許可權系統。
首先需要知道，一般產品的許可權由頁面、操作和數據構成。頁面與操作相互關聯，必須擁有頁面許可權，才能分配該頁面下對應的操作許可權。數據可被增刪改查。
整體關系如下圖所示：
因此，在設計之初我們就需要考慮到未來可能區分角色的地方，盡量解耦、模塊化。對於技術來說，每一個頁面模塊、每一個操作都最好使用獨立的介面。對於設計來說，需要保障所有角色因為許可權而屏蔽掉部分操作和數據後，頁面和流程仍能體驗流暢。
保證初期設計支持後，配置許可權時，還需要注意以下幾點：
（1）確定是否支持前端配置
如果角色和許可權相對固定，則一般將角色與許可權的關系可以寫在後台，改動時需要後端變更且重新上線。這種情況適用於公司內部系統等只有一個使用主體的系統。
如果需要自定義角色或者每個角色在不同使用者的場景下有不同的許可權，則需要將角色的定義、角色與許可權之間的配置體現在「前端用戶配置頁面」。這種情況適用於有頻繁變動的自定義角色許可權，和有租戶體系的系統。
（2）以基本單元拆分，以業務邏輯配置
一般可將每個對象的「增、刪、改、查」各自作為一個基本的許可權單元。打個比方，在「人員管理」中，查看人員列表、添加人員、刪除人員、編輯人員信息最好拆分為4個許可權單元。在技術和設計上，我們希望能盡量做到解耦和模塊化。
但是在業務層面有些操作卻是一體的。這些不能拆開的許可權在「前端用戶配置頁面」中建議打包成一個整體提供配置。例如：如果我們確定在系統的現有和未來業務中，僅分為普通成員有「人員管理」的查看許可權，管理員有操作許可權，則可將「增、刪、改」三個基本許可權單位合並為「操作」許可權進行配置。
（3）頁面許可權優先於操作和數據許可權
必須配置了頁面模塊許可權後，才能配置當前頁面模塊下具體的操作許可權，以及頁面模塊的數據展示許可權。
（4）查看許可權優先於增刪改許可權
正常情況下，一定要先能查看某個模塊或操作，其它的增刪改操作才有意義。因此在設計時，應在獲取查看許可權前限制其它許可權的配置，或者配置其它許可權時默認賦予查看許可權。
（5）角色與許可權的多種關系
角色與許可權的關系不僅是單純「是/否關系」，還包括以某種限制進行操作，和以某種程度訪問數據。
例如在「人員管理」中：
數據范圍：用戶擁有查看人員列表的許可權，但僅能查看自己所在的團隊；數據邊界限制（上限等）：添加人員時不能超過20個等。數據欄位：HR能查看人員列表中包括職級、薪資等欄位，其它角色僅能查看姓名郵箱等欄位；
（6）角色與許可權的設計表達
在傳達一個系統的許可權設計規則時，設計師常常習慣用主觀最直接的方式表達想法，如用「當……時，就……」的句式來表達。但一個平台中涉及的許可權規則是非常多的，當通篇以這樣的形式描述時，表達對象將很難理解。
正確的描述方式：更清晰的是基於開發的語言，和技術模型的結果進行表達。將各角色與許可權單元繪製成網格，每個交叉點網格中描述該角色與許可權的數據關系和限制。
如下圖所示：
四、需要注意的Tips
1. 隱形的admin
在可自定義角色和許可權的系統中，一般需要預留一個admin角色來進行系統的初始配置，用於添加首批的業務人員和配置基本的角色。
有的系統中允許存在上帝視角的admin角色，則其可以作為「超級管理員」顯示在角色配置的列表中。有的系統中不允許這種角色存在，則可將這種角色設置為隱形的狀態，僅賦予維護系統的工作人員。
2. 初始許可權的賦予
對於允許用戶自行加入的系統，需要設定一至多個默認的角色，有時可以是僅有最基礎許可權的「遊客」角色。
初始許可權還可以與用戶既有的某些數據欄位進行關聯，如添加用戶時獲取到用戶的崗位為「設計師」，則直接賦予「設計師」角色的許可權。
3. 人員管理中對自己的處理
在人員管理中，管理員角色處理自己時需要額外注意。因為如果修改或刪除了自己角色後，可能導致系統沒有管理角色，從而無法添加其他成員和正常運行。設計時可添加判斷，當自己為唯一管理角色時，禁止編輯和刪除。
4. 無頁面許可權的提示
雖然可以通過頁面許可權限制直接隱藏當前用戶沒有許可權的頁面，但不能排除用戶獲取到許可權外的url地址。當用戶意外訪問到沒有許可權的頁面時務必提供「無許可權」的提示，避免用戶認為系統bug。
總結一下，整個許可權系統設計就是定義各個節點和節點間關系的過程。
節點包括：
用戶；用戶組；角色；角色組；許可權（頁面、操作、數據）；許可權組（頁面、操作、數據）；
『伍』 前端許可權控制
前端許可權控制分為四個方面的控制
第一點界面控制：用戶還未登入就能通過url訪問到系統頁面，該問題比較好解決通過路由守衛即可判斷。
如果用戶登入以後用url訪問不是屬於自己的菜單頁，如我沒有系統管理這個界面，我去地址欄輸入系統管理這個頁面的url，前端因該阻止它訪問頁面。輸入url能訪問到頁面的原因是你的路由配置了這個地址，所以控制界面的方式就是從路由入手，前期我們配置大家都有的路由，其他的路由根據登入系統時後台返回的許可權列表數據，動態添加路由。
在登入時我們把許可權數據存入vuex中並本地化，通過路由對象可以獲取到路由的配置，把那個用戶的路由單獨添加到路由列表中，使用addroutes添加更改後到路由配置，添加動態路由的方法調用在app.vue的created中，因為每次載入頁面都會調用該方法。
第二菜單控制:
根據用戶的不同菜單欄也不同，該問題跟動態路由類似登入時拿到數據存入vuex中並本地化，之後在菜單組件列表循環遍歷出對應的菜單欄，過於簡單就不截圖了。
第三按鈕控制：
這個控制可以採用自定義組件的方式，例如這個用戶沒有添加人員的按鈕，他只有查看這個人員菜單的許可權。在頁面上按鈕都添加上，但是是否能顯示則根據後端傳過來的許可權數據，該數據在動態路由作為meta數據添加在路由上了，也就是用路由的meta的數據去判斷這個按鈕是否顯示或者禁用或是可用，在頁面我們添加按鈕我們就加一個action屬於為add，我們或者add去比較如果沒有add這個許可權如果處理。上圖
第四請求攔截
請求攔截並不簡單的做一個token，而是每個用戶對應可以操作的請求放行，不是他可以操作的攔截，如他沒有添加的請求則要攔截，前面不是做了按鈕的控制嗎，為啥還要做這個攔截，按鈕控制並不安全，其實他可以通過瀏覽器直接修改按鈕的屬性，有人又說有token了不是可以攔截了嗎，對，可以攔截不過那時後台攔截，你請求還是發過去了，請求影響系統性能，所以做這個還是有必要的。
請求攔截，根據名字就知道他是在請求攔截器里設置的，在攔截器中可以獲取請求方式，根據請求方式與路由中的mate許可權對比有就發送請求，如果沒有則不發請求
『陸』 談前端許可權
自從有了前後端分離，前端的工作內容就變得越發多起來，其中有一項就是許可權控制，下面就談一談前端許可權。
首先我們要理清前端許可權是什麼，我理解的前端許可權就是 控制前端元素是否可見 。因為之前後台模板時代，我們的頁面都是通過後台來渲染的，能不能訪問到頁面直接由後台邏輯判斷就好。但是現在我們到了前後端分離時代，所有頁面的元素都由頁面本身來控制，所以頁面路由這塊需要由前端本身來控制了。所以我認為前端許可權有這幾個關鍵點：
下面我們說一說為什麼說 前端只能做視覺上的控制 和 許可權控制不能放在前端，後台還是需要對每一個介面做驗權 。我覺得其實WEB本身就是圍繞數據來的，所以我們前端安全，主要是保護我們的 數據 ，那和數據最緊密接觸的其實還是後台，前端本身做得是 數據的展示和收集 ，但是數據的存儲和處理並不是由前端來做。所以即使前端能控制住路由/按鈕等不被別人看到，發送請求的方式還是有很多，完全可以繞過前端來請求數據。所以從某種意義上來說，就算前端的許可權控製做得再嚴密，可能作用也是有限的。這也引申了後面一句，後台還是要對每一個介面做驗權。
但是前端做許可權控制還是非常有意義的，我覺得在安全性方面來說，前端就顯示人體的皮膚，我們會是WEB安全的第一道防線。前端要做的工作，我認為有三種：
博客地址 北落師門
『柒』 Vue實現動態路由
通常我們在vue項目中都是前端配置好路由的，但在一些項目中我們可能會遇到許可權控制，這樣我們就涉及到 動態路由 的設置了。
動態路由設置一般有兩種 ：
(1)、簡單的角色路由設置：比如只涉及到管理員和普通用戶的許可權。通常直接在前端進行簡單的角色許可權設置
(2)、復雜的路由許可權設置：比如OA系統、多種角色的許可權配置。通常需要後端返迴路由列表，前端渲染使用
到這里，整個動態路由就可以走通了，但是頁面跳轉、路由守衛處理是非同步的，會存在動態路由添加後跳轉的是空白頁面，這是因為路由在執行next()時，router裡面的數據還不存在，此時，你可以通過window.location.reload()來刷新路由
後端返回的路由格式：
注意： vue是單頁面應用程序，所以頁面一刷新數據部分數據也會跟著丟失，所以我們需要將store中的數據存儲到本地，才能保證路由不丟失。關於vue頁面刷新保存頁面狀態，可以查看 vue如何在頁面刷新時保留狀態信息
『捌』 前端的許可權控制
1.菜單的控制
在登陸請求中，回到的許可權數據，這個許可權的數據是後端返回的數據，前端根據許可權數據，展示對應的菜單，點擊菜單，才能看到相關的界面。
2.界面的控制
如果用戶沒有登錄，手動在地址欄中輸入管理界面的地址，則頁面會跳轉到登錄界面，
如果用戶已經登錄，但是手動輸入非許可權內的地址，則會跳轉到404界面中去。
3.按鈕的控制
在某個菜單的界面中，還需要根據許可權數據，展示出該許可權范圍內可以操作的按鈕，比如增刪改查
4請求和相應的控制
如果用戶通過非常規的操作，比如通過瀏覽器的調試工具將某些禁用的按鈕變成了啟用的狀態，這個時候發的請求，也應該由前端所攔截。
『玖』 產品經理要做的操作許可權/數據許可權設計
產品經理在工作中還需要知道一個：用戶許可權設計能力。許可權設計理念貫穿於後台產品、以及用戶前端產品。
許可權能力包括兩類：數據許可權、系統操作許可權
有的人會好奇，為什麼前端產品會有有許可權管理的要求？接下來我將以角色、許可權、以及RABC許可權設計方法來概述許可權設計、數據許可權設計2個操作。
了解許可權系統前，首先要定義角色，角色的分類如下
最高許可權角色
超級管理員，這個角色一般為平台創建者。可以擁有最高許可權，可分配所有的系統許可權到其他用戶，一般是把最高許可權設計還會映射一個超級管理員作為副管理，方便刪除、編輯人員
副管理員角色
副超級管理員，僅次於最高許可權，可以分配自己許可權下的以外許可權。顯然在他之上就是超級管理員許可權
部分許可權所有者角色
是指的是在副管理員下，有子許可權的用戶。比如在副管理員分層下的許可權
特約用戶角色
只是定向許可權開通，同事這樣的用戶有大量的。比如PMTalk產品經理社區的簽約作者
付費用戶角色
付費用戶許可權在針對產品生命周期早期是與免費直接區分，隨著付費用戶精細化運營打造用戶分層，比如QQ會員的超級會員、普通會員等
角色之間的關系如下，可以看見在超級管理員角色下以樹狀結構分布到子角色。
▲ 角色之間關系
基於角色許可權控制的RABC許可權思想
依次為理論的角色設計模型關系圖
▲ RABC角色許可權
上圖是基於用戶的會話集合歸位角色再分配許可權。角色有操作和控制對象的權利，在基礎上將用戶許可權系統氛圍：用戶管理、角色管理、許可權管理。
實際上用戶管理在系統早期是可以滿足許可權使用，但隨著系統用戶、公司擴張逐漸增多，可能用戶會有因為部門的職責區別，造成了部門下的同用戶許可權是一樣的。
因此產品經理務必要在用戶管理上增加部門管理對角色區分。
▲ 部門管理
將部門架構的編輯、添加、管理都以系統化的方式管理。
看到部門之間的流轉關系，還可以知道部門下有什麼基礎許可權。比如運營部門肯定會涉及到公眾號管理、客服號管理，所以在以下部門的員工都要求設置。
同個部門中存在多個角色，比 如上有運營總監、副總監、組長、用戶，因此許可權要給到每個部門負責人進行編輯、刪除、添加。
讓許可權管理者降低了日常運營許可權工作量，將許可權分配能力分配給了其他成員。
▲ 網上來自部門角色許可權管理的配置圖
用戶管理，給與用戶授權角色
最普遍的做法是設計用戶名單列表，針對用戶信息進行編輯。
用戶管理列表如上，可以操作用戶屬於封禁狀態與否、查看用戶先有狀態。
每個角色下的許可權設置，可以編輯許可權、和刪除許可權。以及批量同意許可權
設置好角色後，還可以在角色下查看已經開通的用戶名單，對用戶名單進行管理。
用戶名單進行刪除、添加。同時當前頁面需要下可以展示多少用戶、是否需要分頁也要注意明確。
2.添加/創建用戶
為系統添加新的管理人員，增加許可權。增加手機號、郵箱、用戶名稱，如果企業使用了OA系統，可以和OA系統進行關聯。
比如現在的企業微信、釘釘都是支持開放介面，快速同步員工信息。
3.創建添加賬戶管理流程
系統建設好後，接下來就是規范運營了。以賬戶開通來說要建立賬戶開通許可權流程規范，比如下圖是某個公司開通運營系統管理員許可權的流程
▲ 系統許可權創建流程
上圖「選擇欄位」可以理解為許可權下的子許可權。若系統不復雜可以不用在早起許可權設計上增加子許可權顆粒度。
我們需要先設置角色，給新賬號關聯對應的角色，如果賬號有特殊許可權或者相關欄位的許可權，再單獨設置相關欄位。
最後基於RABC角色許可權系統設置，產品經理可以借鑒的一個思考腦圖案例
完成許可權設計後，要搭建許可權表單。快速羅列各個角色下的許可權通道
▲
數據許可權的設計
操作許可權是比較容易做的，但數據許可權則比較難了。甚至許多互聯網公司都沒有考慮數據許可權，只要達到不同人員使用的功能不同即可。
數據許可權可以控制組織、可以控制數據域（比如，10個門店，有的人能看到1個門店的數據，有的人能看到10個門店的數據）
做個比喻，功能許可權就像是容器，覺得了你有什麼功能，數據許可權就像水，決定了你容器內放的是什麼。功能許可權和數據許可權是相互獨立的。
數據許可權是指對系統用戶進行數據資源的可見性、以及控制性。直白說：「復合條件的用戶才能查看和操作對應數據的許可權」
比如公司老闆需要看到公司的營收、利潤、用戶增長數據
公司運營總監需要看到互聯網產品業務營收
公司公司銷售要看實物銷售產品的以後
在數據許可權設計下，要定義清楚規則元
名詞定義：規則元。在本文是指單個獨立的數據規則定義，不同用戶對規則元可設置具體的規則過濾值，該值用作數據查詢時的篩選條件。
規則元配置：規則元名稱的配置。一個表中哪些欄位可以進行規則設置，以及規則元名稱如何與表欄位關聯。
『拾』 前端許可權控制時要考慮的5個問題
1.登錄控制 哪些頁面不需要登錄就可以進入
實現思路： 在路由配置metal里配置是否需要登錄 默認需要登錄，在路由之前的鉤子里進行判斷
2.路由控制 不同角色訪問不同的頁面
實現思路：路由配置分成靜態路由和動態路由，動態路由部分按許可權返回的結果進行動態載入
3.頁面上的操作按鈕控制 不同的角色在同一個頁面 可以點擊的按鈕不同
寫一個命令進行操作控制
4.列表上增加刪除修改 控制 在獲取列表數據是返回顯示哪些按鈕
5.菜單顯示控制 根據不同的角色顯示不同的菜單
6.賬號切換時 重新載入對應路由