後臺許可權， 就像是一支軍隊， 需要做到井井有條， 令行禁止， 這樣戰鬥力才能夠發揮出來。 許可權， 故名思議， 權力的限制範圍。 而後臺許可權， 即是對於這個後臺的權力的限制範圍。
一個公司有組織層級， 每個人權利大小不一樣， 相應的到後臺許可權的管理上也要進行相應的劃分， 做到後臺的管理如組織層級一樣清晰。 一個後臺系統有著對應這個系統的業務的所以東西， 可是每個部門所需要的不一樣， 合理的進行劃分許可權， 有利於每個人做事更有效率， 也減少了造成放錯的幾率。
一個軍隊， 要是每個人都可以發號施令， 那豈不是亂套了。 一個後臺也是， 關係到前端APP以及業務的很多關鍵點， 要是每個人都有這些修改的許可權， 誰能夠保證沒有好奇心， 誰能夠保證不亂動。 而這其中一個小小的修改， 說不定就引起了蝴蝶效應，
還有像公司領導人肯定有著最大的權力， 那麼對於他們來說， 需要不需要後臺的所有權限啦？在我看來， 公司領導人主要負責戰略方向， 關心的是產品和業務的發展， 而不是每一個規則是怎樣實現的， 所以需要的僅有幾個與業務有關的許可權即可， 也可以讓他們能夠最快的瞭解自己想要知道的， 而不是說要找。
古時候， 行軍打戰， 有統帥負責， 而最高領導人只需要知道自己軍隊有多少人， 軍資儲備有多少即可， 也不用自己去管軍隊的大大小小方面。
所以劃分後臺許可權所要做的就是， 給這些不同的人以不同的權力和不同的限制， 方便各安其職。
二、許可權的分配模式弄清楚了要給誰分配許可權了， 那麼接下來要做的就是採用什麼方法來把許可權賦予這些用戶了。
許可權-使用者模式把相應的許可權直接賦予給用戶。
優點：更自由， 可以直接給予某個用戶想要的許可權， 也更個性化。 那就是直接統帥讓某某統領騎兵， 統帥說了算。 讓他管理步兵就管理步兵， 可以隨意變更。 能夠做到通過修改變更只影響單個用戶。
缺點：但是沒有相應的標誌。 任憑統帥說的算。 這種模式就是系統管理員說了算， 也只有系統管理員和使用者知道自己有什麼許可權， 不利於追蹤和管理。 隨著人員的增多， 有可能一個部門的人， 許可權不一樣， 造成用戶之間的使用不便。
適用：適合用戶數量僅十餘人， 且人員穩定的系統。 因為人數不多， 所以直接對用戶進行管理即可， 通過直接賦予相應的用戶許可權， 可以做到更個性化。 不過隨著使用者的發展，
把相應的許可權賦予給角色， 對於角色下的用戶都有此許可權。
優點：相當於古時候的兵符， 有象徵， 有標記， 條理清楚。 更有利於管理， 如果人員發展迅猛， 部門裡新增的用戶只要使用部門的角色就可以了。 也不會受許可權管理人員的變更，而造成許可權不清楚。
缺點：經常會因為某些使用者的特殊需求，需要新增臨時角色或者給某些用戶以複合角色。同時，角色的許可權的修改變更會影響的用戶面更廣。
適用：適合於絕大多數的系統，是一種成熟的模式。通過角色的過度，建立起系統許可權與使用者之間的穩定聯繫。相當於河的兩岸，有了角色這座橋，不需要使用者泅水渡河來獲取許可權。
三、許可權怎麼來劃分合理把相應的許可權劃分清楚，就相當於把一支軍隊的各個兵種劃分明確，什麼是戰鬥兵員，什麼是後勤兵員，什麼是騎兵團，什麼是衝鋒兵團。劃分清楚了，到時候發號施令時，才能做到令行禁止。不然到時候各兵種間面面相覷，就難辦了。許可權也是如此，分清楚了，對於用戶來說，對於管理人員來說，才更清楚，用戶要什麼許可權，管理員劃分什麼許可權，而不會造成管理員劃分了相應的許可權，而這許可權不是使用者需要的。
後臺我是這樣劃分：兩大類“頁面查看、頁面操作”和五具體“功能表-頁面-按鈕-子頁面-子按鈕”。
先說一下五具體：
菜單：功能表有一級功能表、二級功能表等等劃分，這是幾級不重要，重要的是其下有相應的頁面。功能表就像是衣服一樣，合理的把相應的頁面進行歸類，讓使用者更方便使用，讓整個後臺看起來看清楚整齊。
頁面：頁面是本質所在，包含有相應的資訊，如使用者基本資訊管理頁面，有著前端使用者的基本資訊。同時頁面中包含有相應的操作按鈕，通過這些按鈕可以進行相應的操作，如對用戶帳號進行凍結等操作。
按鈕：每一個按鈕都是重中之重，可以說是精髓，能夠進行相應的操作，也就是說能夠對資訊進行相應的修改。這個就要特別注意了，如果許可權沒控好，不清楚相應按鈕功能的人，點擊了相應的按鈕，說不定就引起異常了，那就是事故了。按鈕並不一定在每個頁面都存在，有時候有些頁面就沒有這些操作，意味著這些頁面就只是頁面中的資訊展示。
子頁面：相應的子頁面，一般也都是通過按鈕進行觸發的，便於管理。而子頁面的作用，一般是為了展示更詳細的資訊，以及對相應的詳細信息進行修改。子頁面也不一定存在，有時候有些頁面，頁面上就把相應的資訊展示了，用按鈕就可以進行資訊修改，就沒必要多此一舉。
子按鈕：子頁面中的按鈕，用於詳細資訊的修改，一個是關鍵的許可權。子按鈕也不一定存在，就算有子頁面存在的情況下。因為如果子頁面僅僅用於詳細資訊的展示的話，就沒有所謂的修改了，就不需要子按鈕。
而兩大類就是把上面的五具體進行劃分，即“頁面查看”可以包括：功能表、頁面、子頁面；“頁面操作”可以包括：按鈕、子按鈕。也就是說後臺的這些許可權就是“看”和“做”兩部分，而“做”是其中的關鍵，也需要更高的許可權才行。
有了清楚的劃分，之後進行管理就會顯示更簡單清晰，也更加容易。但並不是說只要劃分清楚即可，也需要合理的管理規則，才會相輔相成，才能更加相得益彰。
四、許可權的管理有了上面的鋪墊之後，接下來進行許可權管理就簡單多了，總的來說就是兩方面：頁面查看、頁面操作。把所有的許可權劃分出來，然後一一賦予每一個角色。下面會通過例子進行說明。
（P1）
假設功能表【使用者管理】其下有【使用者基本資訊管理】和【使用者銀行卡管理】兩個頁面，通過上面的介紹，已經知道功能表相當於資料夾的功能，方便相應的頁面進行歸類，所以說單獨勾選功能表的話，相應的使用者到角色是沒有具體頁面的，是沒有用的。所以相應的角色要用到相應的功能表下的頁面時再勾選功能表，不然的話，使用者登錄了，就一個功能表名稱，下面什麼都沒有，就顯得很奇怪。還有一種方法就是，勾選了頁面後，自動勾選上功能表就行了，只勾選功能表沒勾選頁面的話，不生效，就不會顯得那麼奇怪了。
（P2）
（P3）
從上面的P1來看兩個頁面【使用者基本資訊管理】和【使用者銀行卡管理】可以看到一個頁面在有個“查看”這個東東，而另一個頁面沒有，這其實並不是操作的不同，而是要講到的第一個注意點。
（1） 頁面基本資訊的查看要不要單獨用許可權控制？頁面基本資訊的查看可以劃分為和頁面的操作一樣進行許可權控制，也可以歸到和頁面勾選了就擁有了頁面資訊的查看這樣。我個人更傾向于勾選了頁面就有了頁面的基本資訊查看這樣，這樣可以避免一些不必要的麻煩。如果是查看單獨做成了許可權，進行角色管理時，僅僅勾選了“凍結”，那麼對應的使用者，到底能不能看頁面啦，還是說光勾選“凍結”是沒有用的啦。所以通過勾選頁面就具有查看的話，可以更方便一些，然後再把頁面內的相應操作做成許可權勾選。
從P1這張圖看，這時候突然有需求說是要對用戶的銀行卡進行刪除管理，僅頁面【使用者銀行卡管理】下要多一個許可權“刪除”，這就相當於多了個新許可權，這時候就碰到第二個注意點了。
（2） 頁面中新增的許可權是默認勾選還是默認都不勾選？一個用戶的所屬角色有銀行卡查看的許可權，這時候因為相應的需求，要新增個操作，即銀行卡刪除，這個是個重要的操作，大家肯定一眼就知道，這個肯定需要有賦予的人才能夠給啊，即默認是不給所有的角色勾選這個許可權。
但是從（1）中，我們知道現在“查看”許可權是合併在頁面勾選當中，這時候要把“查看”許可權單獨分出來了。顧名思義，“查看”這許可權肯定是有這個頁面的角色都應該有的，即應該默認都勾選上。
這時候就和前面的“刪除”的默認不勾選產生了衝突，這開發起來時，到底讓新的許可權默認勾選還是不勾選啦，總不能讓程式自己判斷重要性和適用性來選擇。
所以在我個人看來，對於新增的許可權，採用預設不勾選的方式將會更好處理。之所以會有新增的許可權，一般來說都是新的業務需求，這些都是特定人操作的，而這些特定人是少數的，採用不勾選的方式的話，以後這些人妖這許可權，只需要給這些人的角色勾選上許可權即可。
而針對上面說的某些奇葩需求，即把每個用戶都有的許可權還要單獨做成新許可權控制，則需要在許可權配置給每個頁面時，進行特殊的設定了，可以在配置時，新增條件：是否給擁有該頁面的所有使用者勾選（否<默認>、是），預設值採用“否”，可以勉強大部分煩惱，只有少部分中二的許可權，才會需要修改這預設值。
不過一般情況下，也不會有這麼中二的許可權新增需求，所以不需要新增這個預設條件也是可行的，真發生時，就麻煩角色管理人員一個個勾選過去了啊，這個不開發，可以省一些開發和測試的量。
五、給頁面配置許可權上面說了這麼多許可權，其實這時候就要說的是，這些許可權從哪裡來啦？總不是憑空出現在角色管理中吧？這時候需要用到的就是頁面維護的功能了。簡單說來這個頁面維護的功能就是給新增的頁面和新增的許可權進行關聯，並進行分配好，可以便於角色管理。
這其中頁面按鈕這是把所有的按鈕做一起，為了方便管理，而不需要每一個頁面做成頁面按鈕不一樣，給技術增加難度。相應頁面有相應的按鈕關聯，沒有的關聯按鈕，就算勾選了也不會讓相應角色下的使用者，到達相應頁面憑空多一個操作的。
在這裡說下上述四（2）中說到的，給按鈕配置個預設條件的，如下圖所示，這些即可，不過有點影響美觀就是，但是相對來說會比較實用一點，所以針對具體的系統和情況，需要好好衡量下。
六、總結一支軍隊隊伍內部各單位的任務職責清楚明白，各項事務井井有條，才能夠在對戰時發揮出更大的殺傷力。後臺許可權也是如此，劃分清晰、管理明白，才能夠事半功倍，讓相應的用戶使用起來更方便、更有效率，才能夠提高生產力。
每一個成功的APP背後，都有一個可靠支持的後臺，而這許可權管理就是後臺的骨架，支撐著後臺成為一個更強大的後臺，所以做好後臺許可權管理是很有必要的
以上就是個人關於後臺許可權管理的一些看法，可能比較片面和偏見，有些條理也不太清晰，僅代表個人意見，歡迎交流。
本文由 @ 夜月沉星 原創發佈于人人都是產品經理。未經許可，禁止轉載。
題圖來自PEXELS，基於CC0協議
也不會受許可權管理人員的變更，而造成許可權不清楚。缺點：經常會因為某些使用者的特殊需求，需要新增臨時角色或者給某些用戶以複合角色。同時，角色的許可權的修改變更會影響的用戶面更廣。
適用：適合於絕大多數的系統，是一種成熟的模式。通過角色的過度，建立起系統許可權與使用者之間的穩定聯繫。相當於河的兩岸，有了角色這座橋，不需要使用者泅水渡河來獲取許可權。
三、許可權怎麼來劃分合理把相應的許可權劃分清楚，就相當於把一支軍隊的各個兵種劃分明確，什麼是戰鬥兵員，什麼是後勤兵員，什麼是騎兵團，什麼是衝鋒兵團。劃分清楚了，到時候發號施令時，才能做到令行禁止。不然到時候各兵種間面面相覷，就難辦了。許可權也是如此，分清楚了，對於用戶來說，對於管理人員來說，才更清楚，用戶要什麼許可權，管理員劃分什麼許可權，而不會造成管理員劃分了相應的許可權，而這許可權不是使用者需要的。
後臺我是這樣劃分：兩大類“頁面查看、頁面操作”和五具體“功能表-頁面-按鈕-子頁面-子按鈕”。
先說一下五具體：
菜單：功能表有一級功能表、二級功能表等等劃分，這是幾級不重要，重要的是其下有相應的頁面。功能表就像是衣服一樣，合理的把相應的頁面進行歸類，讓使用者更方便使用，讓整個後臺看起來看清楚整齊。
頁面：頁面是本質所在，包含有相應的資訊，如使用者基本資訊管理頁面，有著前端使用者的基本資訊。同時頁面中包含有相應的操作按鈕，通過這些按鈕可以進行相應的操作，如對用戶帳號進行凍結等操作。
按鈕：每一個按鈕都是重中之重，可以說是精髓，能夠進行相應的操作，也就是說能夠對資訊進行相應的修改。這個就要特別注意了，如果許可權沒控好，不清楚相應按鈕功能的人，點擊了相應的按鈕，說不定就引起異常了，那就是事故了。按鈕並不一定在每個頁面都存在，有時候有些頁面就沒有這些操作，意味著這些頁面就只是頁面中的資訊展示。
子頁面：相應的子頁面，一般也都是通過按鈕進行觸發的，便於管理。而子頁面的作用，一般是為了展示更詳細的資訊，以及對相應的詳細信息進行修改。子頁面也不一定存在，有時候有些頁面，頁面上就把相應的資訊展示了，用按鈕就可以進行資訊修改，就沒必要多此一舉。
子按鈕：子頁面中的按鈕，用於詳細資訊的修改，一個是關鍵的許可權。子按鈕也不一定存在，就算有子頁面存在的情況下。因為如果子頁面僅僅用於詳細資訊的展示的話，就沒有所謂的修改了，就不需要子按鈕。
而兩大類就是把上面的五具體進行劃分，即“頁面查看”可以包括：功能表、頁面、子頁面；“頁面操作”可以包括：按鈕、子按鈕。也就是說後臺的這些許可權就是“看”和“做”兩部分，而“做”是其中的關鍵，也需要更高的許可權才行。
有了清楚的劃分，之後進行管理就會顯示更簡單清晰，也更加容易。但並不是說只要劃分清楚即可，也需要合理的管理規則，才會相輔相成，才能更加相得益彰。
四、許可權的管理有了上面的鋪墊之後，接下來進行許可權管理就簡單多了，總的來說就是兩方面：頁面查看、頁面操作。把所有的許可權劃分出來，然後一一賦予每一個角色。下面會通過例子進行說明。
（P1）
假設功能表【使用者管理】其下有【使用者基本資訊管理】和【使用者銀行卡管理】兩個頁面，通過上面的介紹，已經知道功能表相當於資料夾的功能，方便相應的頁面進行歸類，所以說單獨勾選功能表的話，相應的使用者到角色是沒有具體頁面的，是沒有用的。所以相應的角色要用到相應的功能表下的頁面時再勾選功能表，不然的話，使用者登錄了，就一個功能表名稱，下面什麼都沒有，就顯得很奇怪。還有一種方法就是，勾選了頁面後，自動勾選上功能表就行了，只勾選功能表沒勾選頁面的話，不生效，就不會顯得那麼奇怪了。
（P2）
（P3）
從上面的P1來看兩個頁面【使用者基本資訊管理】和【使用者銀行卡管理】可以看到一個頁面在有個“查看”這個東東，而另一個頁面沒有，這其實並不是操作的不同，而是要講到的第一個注意點。
（1） 頁面基本資訊的查看要不要單獨用許可權控制？頁面基本資訊的查看可以劃分為和頁面的操作一樣進行許可權控制，也可以歸到和頁面勾選了就擁有了頁面資訊的查看這樣。我個人更傾向于勾選了頁面就有了頁面的基本資訊查看這樣，這樣可以避免一些不必要的麻煩。如果是查看單獨做成了許可權，進行角色管理時，僅僅勾選了“凍結”，那麼對應的使用者，到底能不能看頁面啦，還是說光勾選“凍結”是沒有用的啦。所以通過勾選頁面就具有查看的話，可以更方便一些，然後再把頁面內的相應操作做成許可權勾選。
從P1這張圖看，這時候突然有需求說是要對用戶的銀行卡進行刪除管理，僅頁面【使用者銀行卡管理】下要多一個許可權“刪除”，這就相當於多了個新許可權，這時候就碰到第二個注意點了。
（2） 頁面中新增的許可權是默認勾選還是默認都不勾選？一個用戶的所屬角色有銀行卡查看的許可權，這時候因為相應的需求，要新增個操作，即銀行卡刪除，這個是個重要的操作，大家肯定一眼就知道，這個肯定需要有賦予的人才能夠給啊，即默認是不給所有的角色勾選這個許可權。
但是從（1）中，我們知道現在“查看”許可權是合併在頁面勾選當中，這時候要把“查看”許可權單獨分出來了。顧名思義，“查看”這許可權肯定是有這個頁面的角色都應該有的，即應該默認都勾選上。
這時候就和前面的“刪除”的默認不勾選產生了衝突，這開發起來時，到底讓新的許可權默認勾選還是不勾選啦，總不能讓程式自己判斷重要性和適用性來選擇。
所以在我個人看來，對於新增的許可權，採用預設不勾選的方式將會更好處理。之所以會有新增的許可權，一般來說都是新的業務需求，這些都是特定人操作的，而這些特定人是少數的，採用不勾選的方式的話，以後這些人妖這許可權，只需要給這些人的角色勾選上許可權即可。
而針對上面說的某些奇葩需求，即把每個用戶都有的許可權還要單獨做成新許可權控制，則需要在許可權配置給每個頁面時，進行特殊的設定了，可以在配置時，新增條件：是否給擁有該頁面的所有使用者勾選（否<默認>、是），預設值採用“否”，可以勉強大部分煩惱，只有少部分中二的許可權，才會需要修改這預設值。
不過一般情況下，也不會有這麼中二的許可權新增需求，所以不需要新增這個預設條件也是可行的，真發生時，就麻煩角色管理人員一個個勾選過去了啊，這個不開發，可以省一些開發和測試的量。
五、給頁面配置許可權上面說了這麼多許可權，其實這時候就要說的是，這些許可權從哪裡來啦？總不是憑空出現在角色管理中吧？這時候需要用到的就是頁面維護的功能了。簡單說來這個頁面維護的功能就是給新增的頁面和新增的許可權進行關聯，並進行分配好，可以便於角色管理。
這其中頁面按鈕這是把所有的按鈕做一起，為了方便管理，而不需要每一個頁面做成頁面按鈕不一樣，給技術增加難度。相應頁面有相應的按鈕關聯，沒有的關聯按鈕，就算勾選了也不會讓相應角色下的使用者，到達相應頁面憑空多一個操作的。
在這裡說下上述四（2）中說到的，給按鈕配置個預設條件的，如下圖所示，這些即可，不過有點影響美觀就是，但是相對來說會比較實用一點，所以針對具體的系統和情況，需要好好衡量下。
六、總結一支軍隊隊伍內部各單位的任務職責清楚明白，各項事務井井有條，才能夠在對戰時發揮出更大的殺傷力。後臺許可權也是如此，劃分清晰、管理明白，才能夠事半功倍，讓相應的用戶使用起來更方便、更有效率，才能夠提高生產力。
每一個成功的APP背後，都有一個可靠支持的後臺，而這許可權管理就是後臺的骨架，支撐著後臺成為一個更強大的後臺，所以做好後臺許可權管理是很有必要的
以上就是個人關於後臺許可權管理的一些看法，可能比較片面和偏見，有些條理也不太清晰，僅代表個人意見，歡迎交流。
本文由 @ 夜月沉星 原創發佈于人人都是產品經理。未經許可，禁止轉載。
題圖來自PEXELS，基於CC0協議