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