關于后臺權限,我的幾點思考
后臺權限,就像是一支軍隊,需要做到井井有條,令行禁止,這樣戰斗力才能夠發揮出來。權限,故名思議,權力的限制范圍。而后臺權限,即是對于這個后臺的權力的限制范圍。
一、為什么需要劃分后臺權限
一個公司有組織層級,每個人權利大小不一樣,相應的到后臺權限的管理上也要進行相應的劃分,做到后臺的管理如組織層級一樣清晰。一個后臺系統有著對應這個系統的業務的所以東西,可是每個部門所需要的不一樣,合理的進行劃分權限,有利于每個人做事更有效率,也減少了造成放錯的幾率。
一個軍隊,要是每個人都可以發號施令,那豈不是亂套了。一個后臺也是,關系到前端APP以及業務的很多關鍵點,要是每個人都有這些修改的權限,誰能夠保證沒有好奇心,誰能夠保證不亂動。而這其中一個小小的修改,說不定就引起了蝴蝶效應,造成了業務或者前端APP用戶的大量使用問題,那簡直就是親者痛仇者快了。所以需要權限來控制,做到人人做自己的事,各部門有自己的運轉。
還有像公司領導人肯定有著最大的權力,那么對于他們來說,需要不需要后臺的所有權限啦?在我看來,公司領導人主要負責戰略方向,關心的是產品和業務的發展,而不是每一個規則是怎樣實現的,所以需要的僅有幾個與業務有關的權限即可,也可以讓他們能夠最快的了解自己想要知道的,而不是說要找。
古時候,行軍打戰,有統帥負責,而最高領導人只需要知道自己軍隊有多少人,軍資儲備有多少即可,也不用自己去管軍隊的大大小小方面。
所以劃分后臺權限所要做的就是,給這些不同的人以不同的權力和不同的限制,方便各安其職。
二、權限的分配模式
弄清楚了要給誰分配權限了,那么接下來要做的就是采用什么方法來把權限賦予這些用戶了。
權限-用戶模式
把相應的權限直接賦予給用戶。
優點:更自由,可以直接給予某個用戶想要的權限,也更個性化。那就是直接統帥讓某某統領騎兵,統帥說了算。讓他管理步兵就管理步兵,可以隨意變更。能夠做到通過修改變更只影響單個用戶。
缺點:但是沒有相應的標志。任憑統帥說的算。這種模式就是系統管理員說了算,也只有系統管理員和用戶知道自己有什么權限,不利于追蹤和管理。隨著人員的增多,有可能一個部門的人,權限不一樣,造成用戶之間的使用不便。
適用:適合用戶數量僅十余人,且人員穩定的系統。因為人數不多,所以直接對用戶進行管理即可,通過直接賦予相應的用戶權限,可以做到更個性化。不過隨著用戶的發展,這種模式也會逐漸越來越難負擔,需要進行變化的。
權限-角色-用戶模式
把相應的權限賦予給角色,對于角色下的用戶都有此權限。
優點:相當于古時候的兵符,有象征,有標記,條理清楚。更有利于管理,如果人員發展迅猛,部門里新增的用戶只要使用部門的角色就可以了。也不會受權限管理人員的變更,而造成權限不清楚。
缺點:經常會因為某些用戶的特殊需求,需要新增臨時角色或者給某些用戶以復合角色。同時,角色的權限的修改變更會影響的用戶面更廣。
適用:適合于絕大多數的系統,是一種成熟的模式。通過角色的過度,建立起系統權限與用戶之間的穩定聯系。相當于河的兩岸,有了角色這座橋,不需要用戶泅水渡河來獲取權限。
三、權限怎么來劃分
合理把相應的權限劃分清楚,就相當于把一支軍隊的各個兵種劃分明確,什么是戰斗兵員,什么是后勤兵員,什么是騎兵團,什么是沖鋒兵團。劃分清楚了,到時候發號施令時,才能做到令行禁止。不然到時候各兵種間面面相覷,就難辦了。權限也是如此,分清楚了,對于用戶來說,對于管理人員來說,才更清楚,用戶要什么權限,管理員劃分什么權限,而不會造成管理員劃分了相應的權限,而這權限不是用戶需要的。
后臺我是這樣劃分:兩大類“頁面查看、頁面操作”和五具體“菜單-頁面-按鈕-子頁面-子按鈕”。
先說一下五具體:
菜單:菜單有一級菜單、二級菜單等等劃分,這是幾級不重要,重要的是其下有相應的頁面。菜單就像是衣服一樣,合理的把相應的頁面進行歸類,讓使用者更方便使用,讓整個后臺看起來看清楚整齊。
頁面:頁面是本質所在,包含有相應的信息,如用戶基本信息管理頁面,有著前端用戶的基本信息。同時頁面中包含有相應的操作按鈕,通過這些按鈕可以進行相應的操作,如對用戶賬號進行凍結等操作。
按鈕:每一個按鈕都是重中之重,可以說是精髓,能夠進行相應的操作,也就是說能夠對信息進行相應的修改。這個就要特別注意了,如果權限沒控好,不清楚相應按鈕功能的人,點擊了相應的按鈕,說不定就引起異常了,那就是事故了。按鈕并不一定在每個頁面都存在,有時候有些頁面就沒有這些操作,意味著這些頁面就只是頁面中的信息展示。
子頁面:相應的子頁面,一般也都是通過按鈕進行觸發的,便于管理。而子頁面的作用,一般是為了展示更詳細的信息,以及對相應的詳細信息進行修改。子頁面也不一定存在,有時候有些頁面,頁面上就把相應的信息展示了,用按鈕就可以進行信息修改,就沒必要多此一舉。
子按鈕:子頁面中的按鈕,用于詳細信息的修改,一個是關鍵的權限。子按鈕也不一定存在,就算有子頁面存在的情況下。因為如果子頁面僅僅用于詳細信息的展示的話,就沒有所謂的修改了,就不需要子按鈕。
而兩大類就是把上面的五具體進行劃分,即“頁面查看”可以包括:菜單、頁面、子頁面;“頁面操作”可以包括:按鈕、子按鈕。也就是說后臺的這些權限就是“看”和“做”兩部分,而“做”是其中的關鍵,也需要更高的權限才行。
有了清楚的劃分,之后進行管理就會顯示更簡單清晰,也更加容易。但并不是說只要劃分清楚即可,也需要合理的管理規則,才會相輔相成,才能更加相得益彰。
四、權限的管理
有了上面的鋪墊之后,接下來進行權限管理就簡單多了,總的來說就是兩方面:頁面查看、頁面操作。把所有的權限劃分出來,然后一一賦予每一個角色。下面會通過例子進行說明。
(P1)
假設菜單【用戶管理】其下有【用戶基本信息管理】和【用戶銀行卡管理】兩個頁面,通過上面的介紹,已經知道菜單相當于文件夾的功能,方便相應的頁面進行歸類,所以說單獨勾選菜單的話,相應的用戶到角色是沒有具體頁面的,是沒有用的。所以相應的角色要用到相應的菜單下的頁面時再勾選菜單,不然的話,用戶登錄了,就一個菜單名稱,下面什么都沒有,就顯得很奇怪。還有一種方法就是,勾選了頁面后,自動勾選上菜單就行了,只勾選菜單沒勾選頁面的話,不生效,就不會顯得那么奇怪了。
(P2)
(P3)
從上面的P1來看兩個頁面【用戶基本信息管理】和【用戶銀行卡管理】可以看到一個頁面在有個“查看”這個東東,而另一個頁面沒有,這其實并不是操作的不同,而是要講到的第一個注意點。
(1) 頁面基本信息的查看要不要單獨用權限控制?
頁面基本信息的查看可以劃分為和頁面的操作一樣進行權限控制,也可以歸到和頁面勾選了就擁有了頁面信息的查看這樣。我個人更傾向于勾選了頁面就有了頁面的基本信息查看這樣,這樣可以避免一些不必要的麻煩。如果是查看單獨做成了權限,進行角色管理時,僅僅勾選了“凍結”,那么對應的用戶,到底能不能看頁面啦,還是說光勾選“凍結”是沒有用的啦。所以通過勾選頁面就具有查看的話,可以更方便一些,然后再把頁面內的相應操作做成權限勾選。
從P1這張圖看,這時候突然有需求說是要對用戶的銀行卡進行刪除管理,僅頁面【用戶銀行卡管理】下要多一個權限“刪除”,這就相當于多了個新權限,這時候就碰到第二個注意點了。
(2) 頁面中新增的權限是默認勾選還是默認都不勾選?
一個用戶的所屬角色有銀行卡查看的權限,這時候因為相應的需求,要新增個操作,即銀行卡刪除,這個是個重要的操作,大家肯定一眼就知道,這個肯定需要有賦予的人才能夠給啊,即默認是不給所有的角色勾選這個權限。
但是從(1)中,我們知道現在“查看”權限是合并在頁面勾選當中,這時候要把“查看”權限單獨分出來了。顧名思義,“查看”這權限肯定是有這個頁面的角色都應該有的,即應該默認都勾選上。
這時候就和前面的“刪除”的默認不勾選產生了沖突,這開發起來時,到底讓新的權限默認勾選還是不勾選啦,總不能讓程序自己判斷重要性和適用性來選擇。
所以在我個人看來,對于新增的權限,采用默認不勾選的方式將會更好處理。之所以會有新增的權限,一般來說都是新的業務需求,這些都是特定人操作的,而這些特定人是少數的,采用不勾選的方式的話,以后這些人妖這權限,只需要給這些人的角色勾選上權限即可。
而針對上面說的某些奇葩需求,即把每個用戶都有的權限還要單獨做成新權限控制,則需要在權限配置給每個頁面時,進行特殊的設定了,可以在配置時,新增條件:是否給擁有該頁面的所有用戶勾選(否<默認>、是),默認值采用“否”,可以勉強大部分煩惱,只有少部分中二的權限,才會需要修改這默認值。
不過一般情況下,也不會有這么中二的權限新增需求,所以不需要新增這個默認條件也是可行的,真發生時,就麻煩角色管理人員一個個勾選過去了啊,這個不開發,可以省一些開發和測試的量。
五、給頁面配置權限
上面說了這么多權限,其實這時候就要說的是,這些權限從哪里來啦?總不是憑空出現在角色管理中吧?這時候需要用到的就是頁面維護的功能了。簡單說來這個頁面維護的功能就是給新增的頁面和新增的權限進行關聯,并進行分配好,可以便于角色管理。
這其中頁面按鈕這是把所有的按鈕做一起,為了方便管理,而不需要每一個頁面做成頁面按鈕不一樣,給技術增加難度。相應頁面有相應的按鈕關聯,沒有的關聯按鈕,就算勾選了也不會讓相應角色下的用戶,到達相應頁面憑空多一個操作的。
在這里說下上述四(2)中說到的,給按鈕配置個默認條件的,如下圖所示,這些即可,不過有點影響美觀就是,但是相對來說會比較實用一點,所以針對具體的系統和情況,需要好好衡量下。
六、總結
一支軍隊隊伍內部各單位的任務職責清楚明白,各項事務井井有條,才能夠在對戰時發揮出更大的殺傷力。后臺權限也是如此,劃分清晰、管理明白,才能夠事半功倍,讓相應的用戶使用起來更方便、更有效率,才能夠提高生產力。
每一個成功的APP背后,都有一個可靠支持的后臺,而這權限管理就是后臺的骨架,支撐著后臺成為一個更強大的后臺,所以做好后臺權限管理是很有必要的
以上就是個人關于后臺權限管理的一些看法,可能比較片面和偏見,有些條理也不太清晰,僅代表個人意見,歡迎交流。
本文由 @?夜月沉星 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自PEXELS,基于CC0協議
文章寫的很好,很受啟發,但是有一點還望解惑:作者說到的五具體“菜單-頁面-按鈕-子頁面-子按鈕”在權限配置頁面該如何展示呢?難道按照兩大分類的原則把頁面和子頁面平級展示么?這樣對管理員似乎很難確認權限對應的頁面/按鈕的具體展示位置了。
文件夾,頁面和按鈕前面加個不同的圖標就可以區分了,然后權限管理用復選框
哇 感謝作者大大的回復!還有一個問題:那按鈕和子頁面關聯情況的時候權限怎么展示呢?比如 有個頁面中有個編輯按鈕,點擊編輯按鈕打開編輯子頁面,編輯子頁面又有子按鈕。那在權限配置里直接編輯權限作為子頁面類型存在呢?還是又作為按鈕存在(權限決定按鈕展示不展示),又作為子頁面存在(子頁面是否有權訪問),那就一個編輯還分出兩個權限來了
細分吧,也可以在權限配置時,標注頁面級別,這樣就更清楚。所有能選擇的權限,分離都不是問題,重在區分清楚,一目了然
By the way , Do not touch my LAFESTA
user / role / menu / user -> role / role -> menu / user -> menu for some special person.
歡迎交流
后臺權限管理的關鍵點,涉及到四張表:1)頁面權限配置表:基礎表,維護頁面的權限;2)用戶表:維護用戶信息,將會關聯角色,可以查看該用戶對應的角色及角色權限(不可修改(若可以修改,角色的存在就沒有意義了));3)權限表:維護權限組,將會關聯角色,可以查看某個權限對應的角色有哪些;4)角色表:維護角色信息,可以查看角色下的用戶和角色對應的權限。
歡迎交流!
請問:五、給頁面配置權限 ,這里面講的新增頁面及按鈕時給頁面配置權限,這個操作是需要單獨一個頁面來進行的嗎?角色管理中的每一個頁面及按鈕都是通過這種方式加上去的嗎?
一般來說,為了讓控制更細的話,頁面中的按鈕都單獨分離出來??梢酝ㄟ^角色配置的方法,來關聯頁面及頁面中的按鈕,實現控制。
感謝分享,不過這段有些疑問,希望能得到您的解答,(2)中
“但是從(1)中,我們知道現在“查看”權限是合并在頁面勾選當中,這時候要把“查看”權限單獨分出來了。顧名思義,“查看”這權限肯定是有這個頁面的角色都應該有的,即應該默認都勾選上。
這時候就和前面的“刪除”的默認不勾選產生了沖突……”
這里為什么要把“查看”分出來?不是很懂;還有和刪除的沖突是什么?
靜候佳音
先贊再提問。請問作者,數據權限該怎么設計?
使用RBAC2模型可以實現數據權限的控制
思維比較清晰
功能權限是包括一個或多個頁面。比如一個會員模塊包括的頁面有(列表[檢索],編輯,查看,凍結,刪除),在設置凍結功能時會把(列表,查看,凍結)三個頁面合為一個功能權限。當勾選凍結功能的時候自動擁有列表和查看功能。
對頭
您好,看了您這篇文章覺得收獲挺大的,但是還是有點懵啊,我說一下我的理解啊,就是咱們的管理員先創建角色,創建角色之后呢,給角色分配每個頁面乃至每個按鈕可見權限(對于這里能不能以功能模塊為最小單位呢)。然后創建不同角色的用戶實現權限管理,可以對用戶配置特殊權限。對嗎
是的,按鈕你也可以理解為功能,但是這個功能模塊啦,需要是活動的,這樣才能夠控制。
很棒,干貨滿滿