最近新需求來了，要給系統增加幾個資源權限。盡量減少代碼的改動和程序的復雜程度。所以還是使用裝飾器比較科學
之前用了一些登錄驗證的現成裝飾器模塊。然后仿寫一些用戶管理部分的權限裝飾器。
比如下面這種
|
1
2
3
4
5
6
7
8
9
10
11
12
|
def permission_required(permission): def decorator(f): @wraps(f) def decorated_function(*args, **kwargs): if not current_user.can(permission): abort(403) return f(*args, **kwargs) return decorated_function return decoratordef admin_required(f): return permission_required(Permission.SMY)(f) |
調用權限的時候很好理解。直接仿寫admin_required的格式就好了。然后每個頁面入口用語法糖這樣寫： @admin_required
于是頁面的入口權限就做好了。但是資源權限和頁面權限不同。上面內容中提到的permission是寫在model.py的靜態內容里面的。
從封裝來看，至少是看不出來哪個地方暴露了用戶查詢的方法（菜鳥水平下）。只能簡單的看出來if判斷的時候似乎使用了current_user這個變量的內置方法
但是current_user其實是一個第三方的包的內容，和登錄模塊引入的包相同，是一整套記錄token信息的代碼。詳細內容太多。從這個地方出發去寫，會go die
因為哪怕我知道其實調用的.can(permission)是model類里面定義的類方法?？墒莄urrent_user是取了哪個部分的東西還是不清楚。
所以不管它。從頭來梳理一下裝飾器的內容。
首先一個簡單的裝飾器寫法是很好理解的。比如原函數是這樣寫的：
|
1
2
3
4
5
6
7
8
9
10
|
def page(): if user == 'admin': form = Form() if request.method=='POST': db.session.add(form) db.session.commit() flash("success") return 0 |
這當然是隨便寫的一個函數（明顯有很多問題），只是用來表達一個過程。首先通過路由調用這個函數的時候，會先執行第一個if判斷。這個判斷即我們想要的驗證內容
驗證通過以后，說明用戶可以訪問這個頁面，然后頁面內容會渲染出來，交互功能也被允許……
那么裝飾器，就是把這個if的功能提取出來了。那么原函數寫成這樣的形式：
|
1
2
3
4
5
6
7
8
9
10
|
@admin_checkdef page(): form = Form() if request.method=='POST': db.session.add(form) db.session.commit() flash("success") return 0 |
單從這個函數來說，這樣寫并沒有任何好處，似乎本來一行代碼搞定的問題，多用了幾行代碼。我們展開這個形式的完整代碼看一下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
def admincheck(func): if user=='admin': return func def page(): form = Form() if request.method=='POST': db.session.add(form) db.session.commit() flash("success") return 0page = admincheck(page()) |
上面的裝飾器只是把page=admincheck這一句寫成了@模式。
但是這種寫法只能解決最基本的驗證問題。也就是相對獨立的入口驗證。這個驗證還沒有拿到程序傳遞到page()函數當中的參數。也就是說，這個驗證這么看起來沒什么用處
不過機制是這樣。接下來就可以研究怎樣的做法是把路由傳遞過來的請求數據進行驗證然后繼續執行的了。
|
1
2
3
4
5
6
7
|
def admincheck(func): def inner(arg): if user == 'admin': if arg == 'false': abort(403) return func(arg) return inner |
同樣的，多個參數的時候，只需要把 def inner(arg)改寫成def inner(arg1,arg2)
n個參數的時候，則寫成def inner(*args,**kwargs) 這個需要注意一下。*args是元組，即('user',1);**kwargs是字典，即{'user':1}
同時寫這兩個形參的話，基本上就能處理所有傳遞進來的參數類型了。
當然。除此以外還有更復雜的裝飾器寫法。不過能處理傳遞過來的參數并且不影響被裝飾函數的正常執行。基本上實現了之前的功能。
那么回過頭來看示例當中的寫法。最外層使用def permission_required(permission): 的意義，顯然是想要實現復用。
|
1
2
|
def admin_required(f): return permission_required(Permission.SMY)(f) |
上面的(permission)形參顯然對應permission_required(Permission.SMY)中(Permission.SMY)這個參數。把這個參數的形參傳遞到方法體內部
這也是為什么要在裝飾器decorator(f)外面再嵌套一層函數的原因——實現復用
于是之前這個寫法的內容就很清晰了
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
def permission_required(permission):#通過形參實現了一個裝飾器類。對于不同針對性的裝飾器，都可以調用這個函數的實現，而只需要做最小的改動（傳遞形參） def decorator(f): #這個才是裝飾器開始執行的第一步 @wraps(f) #這個裝飾器實際上是為了保證函數的原始屬性不發生改變。所謂原始屬性，指的是__name__ 這種屬性 def decorated_function(*args, **kwargs): #這個裝飾器方法把原函數的形參繼承了。因此實際上相當于在原函數開頭增加了這個函數的內容 if not current_user.can(permission): #這個地方很明顯。current_user是從內存中?。ǚ斩耍?，然后permission就會根據我們實際需要驗證的permission進行形參到實參的轉化 abort(403) #明顯的異常處理，當然，403是一個粗暴的方法。更粗暴的方法，我會用redirect(url_for(logout))... return f(*args, **kwargs) #結束判斷，把參數傳遞給原函數（此處的f()即是原函數（更具體的權限驗證裝飾器），只是f是個丑陋的形參而已） return decorated_function return decorator |
這樣差不多就結束了。如果有人想補充，歡迎留言。
以上這篇Python裝飾器實現幾類驗證功能做法實例就是小編分享給大家的全部內容了，希望能給大家一個參考，也希望大家多多支持服務器之家。
