最近新需求來了，要給系統(tǒng)增加幾個資源權(quán)限。盡量減少代碼的改動和程序的復雜程度。所以還是使用裝飾器比較科學

之前用了一些登錄驗證的現(xiàn)成裝飾器模塊。然后仿寫一些用戶管理部分的權(quán)限裝飾器。

比如下面這種

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)

調(diào)用權(quán)限的時候很好理解。直接仿寫admin_required的格式就好了。然后每個頁面入口用語法糖這樣寫： @admin_required

于是頁面的入口權(quán)限就做好了。但是資源權(quán)限和頁面權(quán)限不同。上面內(nèi)容中提到的permission是寫在model.py的靜態(tài)內(nèi)容里面的。

從封裝來看，至少是看不出來哪個地方暴露了用戶查詢的方法（菜鳥水平下）。只能簡單的看出來if判斷的時候似乎使用了current_user這個變量的內(nèi)置方法

但是current_user其實是一個第三方的包的內(nèi)容，和登錄模塊引入的包相同，是一整套記錄token信息的代碼。詳細內(nèi)容太多。從這個地方出發(fā)去寫，會go die

因為哪怕我知道其實調(diào)用的.can(permission)是model類里面定義的類方法。可是current_user是取了哪個部分的東西還是不清楚。

所以不管它。從頭來梳理一下裝飾器的內(nèi)容。

首先一個簡單的裝飾器寫法是很好理解的。比如原函數(shù)是這樣寫的：

def page():  if user == 'admin':    form = Form()        if request.method=='POST':            db.session.add(form)      db.session.commit()      flash("success")      return 0

這當然是隨便寫的一個函數(shù)（明顯有很多問題），只是用來表達一個過程。首先通過路由調(diào)用這個函數(shù)的時候，會先執(zhí)行第一個if判斷。這個判斷即我們想要的驗證內(nèi)容

驗證通過以后，說明用戶可以訪問這個頁面，然后頁面內(nèi)容會渲染出來，交互功能也被允許……

那么裝飾器，就是把這個if的功能提取出來了。那么原函數(shù)寫成這樣的形式：

@admin_checkdef page():    form = Form()    if request.method=='POST':      db.session.add(form)      db.session.commit()      flash("success")      return 0

單從這個函數(shù)來說，這樣寫并沒有任何好處，似乎本來一行代碼搞定的問題，多用了幾行代碼。我們展開這個形式的完整代碼看一下：

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())