框架底層和接口終於改造完成了，小白再次找到老菜。

　　小白：老大，上次你對後臺權限系統簡單的講了一下，我一點頭緒都沒有，現在有空完整的說一說嗎？

　　老菜：說到權限系統，要講明白真不容易，權限系統並不是越復雜越好，要根據項目的需要而定，有的系統只有幾個人操作，並沒有必須使用功能強大且復雜的權限管理系統；而有的大型企業，各地區存在分公司，業務與銷售數據分級管理，系統數據甚至需要不同角色允許查看不同的數據列，對數據的增、刪、查、改都有非常細致的限制，這就需要使用對應的功能強大的權限管理模塊，來處理不同的業務需求。

　　下面我用多張圖循序漸進的方式來說明一下權限系統的演變。

　　首先我們來看看最簡單的權限系統是怎麽管理的

　　最簡單的權限系統，它只需要驗證用戶賬號與密碼是否正確就可以了，進入系統後通過檢查session是否失效，來判斷用戶是否退出，登錄進入系統後，所有功能項都開放給用戶操作。

　　相對於前面一種權限，稍微復雜點的權限管理，它只需要管理到菜單級別，簡單的對於頁面的訪問不做控制，復雜點的也只需要在所有鏈接中，根據訪問url生成對應的加密串，在被訪問頁面的相關接口使用同樣的密鑰與規則，生成對應的加密串，然後比較兩個加密串是否一致就可以防止絕大部分的非法訪問了。

　　這種權限管理，需要增加菜單（主鍵id、菜單名稱、頁面url、排序、是否啟用、創建時間）和菜單權限管理功能。菜單和頁面url的加密處理，在返回菜單時可以由服務器統一生成傳回給客戶端，客戶端只有通過服務器端生成的url才能進入對應的頁面。至於怎麽做到加密串識別的，可以通過下面方式進行處理：

　　用戶登錄後自動生成唯一的由大小寫字母和數字組成的標識串做為密鑰，然後加上時間戳、被訪問頁面名稱、ip、頁面訪問參數（比如id值等），用md5加密生成一個加密串，然後將加密串和時間戳、頁面訪問參數等內容組合成url參數，生成可以訪問的url。當用戶點擊該url訪問時，被訪問頁面接收到這些參數後，通過一樣的加密次序進行處理，生成同樣的加密串與提交過來的加密串進行比較，就可以識別用戶有沒有權限訪問該頁面了。用戶通過擅改頁面名稱或訪問參數，被訪問頁面可以很容易檢查到加密串不一致而拒絕訪問，可以輕易做到用戶只能通過指定url才能訪問頁面。因為用戶不知道密鑰是什麽，所以他很難進行造假訪問無權限訪問的頁面。

　　這樣處理看起來好像很復雜的樣子，實際上開發起來很簡單，且只需要一個菜單與菜單權限表，菜單權限表將菜單和管理員賬號綁定起來，授權指定管理可以訪問的菜單項，權限管理相對來說非常簡單且容易實現。

　　對於上面這種權限，它無法控制頁面按鍵，也就是說它無法控制增刪改查等各種操作，所以就延伸出下面這種權限管理方法。

　　對於前後端分離的系統來說，頁面列表數據查看、新增、修改、刪除等各種操作，都需要通過ajax將數據或參數提交給對應的接口，然後接口再將運算的結果返回回來，所以我們可以通過限制接口的訪問來做到對頁面按鍵功能的控制。

　　對於這種權限管理，我們只需要在前面的菜單管理功能中進行擴展就可以實現了，在菜單表（主鍵id、菜單名稱、頁面url、排序、是否啟用、創建時間）中增加上一級菜單id、接口路由地址、是否顯示這幾個字段就可以了。

　　由於需要增加頁面按鍵對應的接口控制，為了讓菜單分級展示頁面與按鍵綁定的關系，所以需要添加父級菜單id，而接口中路由地址這個字段，熟悉python的bottle框架的小夥伴，可以很清晰的知道每個接口都是通過我們自己設置的路由來訪問的，比如說前面獲取產品指定主鍵id實體的地址

@get(‘/api/product/<id:int>/‘)
def callback(id):
    """
    獲取指定記錄
    """

　　@get(‘/api/product/<id:int>/‘) 這個就是url訪問的路由地址，這些路由地址在整個項目中都是唯一的，且接口被訪問時我們很容易直接獲取到這個路由標識。所以在開發時，我們可以在底層直接做個攔截，通過判斷用戶是否有勾選這個路由對應的菜單項，來查看用戶是否有訪問該接口的權限。

　　而是否顯示字段，主要是為了菜單列表輸出時，將這些按鍵項隱藏，不直接在菜單中顯示出來。

　　而用戶權限的管理，跟前面的一樣，只需要管理員賬號綁定可以訪問的菜單項就行了。

　　對於人員比較多，且人員流動比較頻繁的企業來說，使用前面的權限管理起來，會很麻煩。因為人員流動後，需要經常對權限進行相應的調整，無論是新員工入職還是員工更換崗位，都需要重新設置對應的管理員訪問權限。為了使權限管理起來更加簡單化，這時需要引入職位（角色）與部門（權限組）的概念。對於企業來說，職位比角色更容易理解，不同的職位有不同的工作職責，對於企業的管理系統操作來說也是一樣的，不同的職位也有不同的操作權限。而部門主要是為了方便對職位進行分組管理，因為職位多時沒有對應的分組，查詢不方便，如果有相似的職位，也容易混淆。

　　對於企業來說，人員由於流動關系可能會經常變化，而職位則相對來說是比較固定的，所以權限由前面直接綁定管理員，改為菜單權限綁定職位。當一位員工更換崗位時，只需要更改他所綁定的職位，對於新入職的員工，也只需要綁定他所入職崗位，他們就可以擁有該職位的所有權限。

　　當然也會存在一些特殊的需要，比如說某人與同事都隸屬於同一個職位，但他是老員工可以擁有更多的權限，這時可以增加一個新職位（通過制定職位級別）來區分他們的權限。

　　又比如說，如果權限需要限制部門訪問權限，而該部門內的職位只能設置當前部門對應的權限，如果有員工需要跨部門擁有其他權限時，可以通過更改管理賬號綁定多職位的方式來實現，也就是說一個員工他只可以綁定一個主部門，但他可以同時擁有多個職位，然後享有多個職位共有的權限。

　　對於常見的企業權限需求來說，這個權限設置就可以滿足大部分項目的要求了，後面章節會重點介紹當前這個權限管理體系。

　　有些項目在權限上可能還有其他方面的特殊需求，比如說前面的權限管理它們都是頁面的訪問控制，如果想要對頁面的查看項和可操作項進行更細一步的控制時，它們就做不到了，這時我們就需要引入新的權限管理體系。

　　比如說企業內部的文檔系統，所有用戶對於自己部門或擁有權限的內容都有查看、新增、修改、刪除、歸檔等操作權限，使用按鍵無法對這些權限進行細分控制。

　　這時可以創建一個文檔權限管理表來專門管理這些操作權限，通過將文檔分類記錄與職位綁定的方式，在用戶查看或操作這些文檔時，檢查該用戶是否擁有對應的權限來進行權限管理。這種權限管理一般是前面權限管理功能的擴展，可以靈活管理各種不同的權限需求。

　　如果你的系統想要應用到那些大型的企業中，就像前面所講到的，需要對各地區分公司，業務與銷售數據要求分級管理，系統數據甚至需要不同角色允許查看不同的數據列，對數據的增、刪、查、改都有非常細致的限制，我們還需要再對權限系統進行更大的擴展，來實現更細粒度的權限管理。

　　比如說我們的部門編碼是如下規則（實際項目中，部門劃分可能有很大的區別，而要實現跨部門跨權限查詢，那又是另外的算法了）：

01  XX公司
    0101  CEO
        010101 財務部
        010201 銷售部  
            01020101  華南地區分公司
                0102010101  廣東地區 
                0102010102  廣西地區 
                0102010103  海南地區 
            01020102  華北地區分公司
                0102010201  北京地區 
                0102010202  天津地區 
                0102010203  河北地區 

　　所有的訂單和銷售數據都必須綁定對應的部門編碼，這樣我們在做數據統計時，就可以通過當前用戶所在位置的編碼+%方式組合sql語句進行查詢篩選，限制用戶只能查看自己分管部門以下的所有數據，而不能跨部門或跨權限查詢到高一級部門的數據。這種方式對於數據量不算太大的項目來說，它是最簡單的最容易實現的管理方式。

　　當然要實現類似的數據權限管理功能方式有很多，這裏就不一一討論了。

　　在實際開發中，業務的不一樣，權限需求可能是千奇百怪，什麽樣的需求都可能有，這就需要我們深入的去分析需求，結合系統功能模塊，設計出對應的權限管理系統，以滿足不同企業的權限管理需要。

版權聲明：本文原創發表於 博客園，作者為 AllEmpty 本文歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則視為侵權。

python開發QQ群：669058475 作者博客：http://www.cnblogs.com/EmptyFS/

我的第一個python web開發框架（33）——後臺管理系統權限設計