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

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

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

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

　　下面我用多張圖按部就班的方式來講明一下權限系統的演變。

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

　　

　　最簡單的權限系統，它只須要驗證用戶帳號與密碼是否正確就能夠了，進入系統後經過檢查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（本羣已滿）、733466321（能夠加2羣）    做者博客：http://www.cnblogs.com/EmptyFS/