Python装饰器实现几类验证功能做法实例

最近新需求来了，要给系统增加几个资源权限。尽量减少代码的改动和程序的复杂程度。所以还是使用装饰器比较科学

之前用了一些登录验证的现成装饰器模块。然后仿写一些用户管理部分的权限装饰器。

比如下面这种

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类里面定义的类方法。可是current_user是取了哪个部分的东西还是不清楚。

所以不管它。从头来梳理一下装饰器的内容。

首先一个简单的装饰器写法是很好理解的。比如原函数是这样写的：

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

这当然是随便写的一个函数（明显有很多问题），只是用来表达一个过程。首先通过路由调用这个函数的时候，会先执行第一个if判断。这个判断即我们想要的验证内容

验证通过以后，说明用户可以访问这个页面，然后页面内容会渲染出来，交互功能也被允许……

那么装饰器，就是把这个if的功能提取出来了。那么原函数写成这样的形式：

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

单从这个函数来说，这样写并没有任何好处，似乎本来一行代码搞定的问题，多用了几行代码。我们展开这个形式的完整代码看一下：

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