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
這是比較簡單的實現方法。除了這種外，還能用來在執行函數之后輸出消息。先寫到這里。下班。