flask-login ----系统权限设计部分小结

tips:

事实证明。开发是一项苦力活。但是代码只有自己写的才是令人感到放心的。不过仅仅是从开发角度来说。从维护和安全角度来说，当然还是引入模块比较爽

 

但是引入的模块总会有一些问题。碰到的最大问题就是，暴露的只有接口，内部实现的时候调用了什么一概不知

百度很渣，python的资料用百度实在是不能查出来什么有用的东西。

 

这周工作基本上是做一个经典的权限管理模型，一个线上平台的应用场景：

公司-合作伙伴-合作伙伴下属账户

站点-权限组-用户

 

python代码量不是很多。但是建议使用蓝本对于整个web进行功能分离：

合作伙伴主账户的管理功能，涵盖：用户管理，站点分配，用户组管理。写到这里发现一个问题。系统的关键参数，比如用户名，最好是不能进行修改。同时在创建时进行校验。保证不越权

一般用户的访问功能：数据库性能管理；告警监控管理；个人信息修改（密码，邮箱等）

最高管理员权限：站点添加；合作伙伴管理

 

系统中权限按照二进制位进行分配。每个功能模块都设置了相应的权限。但是目前系统不需要更加详细的权限设置。但是这样设计是为以后进一步细分留下的空间。

 

说完这个接下来是sqlalchemy的经典model设计

其中User部分需要内置一些函数，用来实现一些验证。我觉得在这个地方做这些，是为了减少代码开销。对于性能来讲是差不多的。主要函数就是一些比如密码哈希加密，哈希解密，返回用户拥有权限这样的简单验证

 

当引入flask-login模块的时候，需要注意user表，flask-login默认使用

def load_user(user_id):
    return User.query.get(int(user_id))

但是这边还不是很直观。因为这边传递的是一个形参。在527行的部分，其实内部实现的实参是取User表的id列。但是一般在多表结构设计的时候，基本上不会把所有的表的主键都用简单的id进行注册

至少我们是用例如partner_id；user_id这样的列名作为主键的。所以这个部分会涉及到修改

 

除此以外，flask-login所处的空间是项目（环境）的site-package包当中。因此内部引用的时候有一些相关文件的引用。我将这个包提取出来。然后修改所有我代码当中指向这个文件的引入。希望这个文件的移植性更好。但是结果是SQLAlchemy在构建类的时候就错误了。项目无法启动。所以暂时我又把这个模块给放回去了。

 

但是这个模块的功能无非也就是一些简单的装饰器。所以在开发的第二阶段。可能的情况下，还是自己写装饰器更好一些。

一般来说，装饰器类会写在app/decorator.py这个路径下面。这样在引用的时候更方便一些。当然在每个文件中写一些内部的装饰器类函数也是可以的。不过我感觉不方便管理。至少修改的时候就比较麻烦

 

装饰器+语法糖，对于开发效率和代码可读性是一个很大的提升。在学这个的时候明白了面向切面编程是一个什么东西。

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 decorator

这是比较简单的实现方法。除了这种外，还能用来在执行函数之后输出消息。先写到这里。下班。