1. 程式人生 > >Flask 原始碼閱讀筆記

Flask 原始碼閱讀筆記

我覺得我已經養成了一個壞習慣,在使用一個框架過程中對它的內部原理非常感興趣,有時候需要花不少精力才

明白,這也導致了學習的緩慢,但換來的是對框架的內部機理的熟悉,正如侯捷所說,原始碼面前,了無祕密。這也是

本文產生的直接原因。

一.flask session原理

flask的session是通過客戶端的cookie實現的,不同於diango的伺服器端實現,flask通過itsdangerous這個苦將session的內容序列化到瀏覽器的cookie,當瀏覽器再次請求時將反序列化cookie內容,也就得到我們的session內容。比如說session['name']='kehan',客戶端session如下,

我們來解密這個cookie儲存了什麼值該cookie通過.分割,分成了三部分:內容序列化+時間+防篡改值
通過第一部分我們就獲得了session['name']的值,我們看看第二部分
第二部分儲存的是時間,itsdangerous庫為了減少時間戳的值,之前減掉了118897263,所以我們要加上。這個時間flask是用來判斷session是否過期使用的。第三部分是session值和時間戳以及我們SECRET_KEY的防篡改值,通過HMAC演算法簽名。也就是說即使你修改了前面的值,由於簽名值有誤,flask不會使用該session。所以一定要儲存好SECRET_KEY,以及確保它的複查度,不然一旦讓別人知道了SECRET_KEY,就可以通過構造cookie偽造session值,這是很恐怖的一件事。
我們知道一般為了保護session,所以session的生成還會包含客戶端user_agent,remete_addr等,如果你覺得使用flask提供的保護力度不夠,可以使用flask_login這個擴充套件,一幫在flask使用認證時都會使用這個擴充套件,簡單易用,還提供了更加強度的session保護。

二. flask擴充套件import 原理

我喜歡flask的一個理由就是匯入簡單,非擴充套件的都可以通過from flask匯入,擴充套件的都是通過from flask.ext.匯入,非常簡潔。用django的過程中,經常不記得該從哪裡匯入,在flask的世界裡,你無需煩惱。那麼flask的擴充套件
匯入原理是什麼呢?主要通過sys.meta_path實現的
當匯入 from falsk.ext.example import E是將會執行flask/ext/__init__.py
def setup():
    from ..exthook import ExtensionImporter
    importer = ExtensionImporter(['flask_%s', 'flaskext.%s'], __name__)
    importer.install()
install將會向sys.meta_path新增模組裝載類,當import時會呼叫其find_module,如果返回非None,會呼叫load_module載入
比如當我們 from flask.ext.script import Manager時
會呼叫find_module('flask.ext.script'),prefinx是flask.ext所以將會呼叫load_module()
此時將會嘗試import flask_script模組或flaskext.script

   def install(self):
        sys.meta_path[:] = [x for x in sys.meta_path if self != x] + [self]

    def find_module(self, fullname, path=None):
        if fullname.startswith(self.prefix):
            return self

    def load_module(self, fullname):
        modname = fullname.split('.', self.prefix_cutoff)[self.prefix_cutoff]
        for path in self.module_choices:
            realname = path % modname
            __import__(realname)

三. flask sqlalchemy原理

sqlalchemy是python中最強大的orm框架,無疑sqlalchemy的使用比django自帶的orm要複雜的多,使用flask sqlalchemy擴充套件將拉近和django的簡單易用距離。先來說兩個比較重要的配置app.config['SQLALCHEMY_ECHO'] = True =》配置輸出sql語句
app.config['SQLALCHEMY_COMMIT_ON_TEARDOWN'] = True =》每次request自動提交db.session.commit(),
如果有一天你發現別的寫的檢視中有db.session.add,但沒有db.session.commit,不要疑惑,他肯定配置了上面的選項。這是通過app.teardown_appcontext註冊實現
        @teardown
        def shutdown_session(response_or_exc):
            if app.config['SQLALCHEMY_COMMIT_ON_TEARDOWN']:
                if response_or_exc is None:
                    self.session.commit()
            self.session.remove()
            return response_or_exc
response_or_exc為異常值,預設為sys.exc_info()[1]
上面self.session.remove()表示每次請求後都會銷燬self.session,為什麼要這麼做呢?
這就要說說sqlalchemy的session物件了。
from sqlalchemy.orm import sessionmaker
session = sessionmaker()
一幫我們會通過sessionmaker()這個工廠函式建立session,但這個session並不能用在多執行緒中,為了支援多執行緒
操作,sqlalchemy提供了scoped_session,通過名字反映出scoped_session是通過某個作用域實現的
所以在多執行緒中一幫都是如下使用session
from sqlalchemy.orm import scoped_session, sessionmaker
session = scoped_session(sessionmaker())
我們來看看scoped_session是如何提供多執行緒環境支援的
class scoped_session(object):
    def __init__(self, session_factory, scopefunc=None):
        
        self.session_factory = session_factory
        if scopefunc:
            self.registry = ScopedRegistry(session_factory, scopefunc)
        else:
            self.registry = ThreadLocalRegistry(session_factory)
__init__中,session_factory是建立session的工廠函式,而sessionmaker就是一工廠函式(其實是定義了__call__的函式)而scopefunc就是能產生某個作用域的函式,如果不提供將使用ThreadLocalRegistry
class ThreadLocalRegistry(ScopedRegistry):
    def __init__(self, createfunc):
        self.createfunc = createfunc
        self.registry = threading.local()

    def __call__(self):
        try:
            return self.registry.value
        except AttributeError:
            val = self.registry.v
從上面__call__可以看出,每次都會建立新的session,併發線上程本地變數中,你可能會好奇__call__是在哪裡呼叫的?
def instrument(name):
    def do(self, *args, **kwargs):
        return getattr(self.registry(), name)(*args, **kwargs)
    return do

for meth in Session.public_methods:
    setattr(scoped_session, meth, instrument(meth))
正如我們所看到的,當我們呼叫session.query將會呼叫 getattr(self.registry(), 'query'),self.registry()就是呼叫__call__的時機,但是在flask_sqlalchemy中並沒有使用ThreadLocalRegistry,建立scoped_session過程如下

# Which stack should we use?  _app_ctx_stack is new in 0.9
connection_stack = _app_ctx_stack or _request_ctx_stack

    def __init__(self, app=None,
                 use_native_unicode=True,
                 session_options=None):
        session_options.setdefault(
            'scopefunc', connection_stack.__ident_func__
        )
        self.session = self.create_scoped_session(session_options)

    def create_scoped_session(self, options=None):
        """Helper factory method that creates a scoped session."""
        if options is None:
            options = {}
        scopefunc=options.pop('scopefunc', None)
        return orm.scoped_session(
            partial(_SignallingSession, self, **options), scopefunc=scopefunc
        )
我們看到scopefunc被設定為connection_stack.__ident_func__,而connection_stack就是flask中app上下文,
如果你看過前一篇文章你就知道__ident_func__其實就是在多執行緒中就是thrading.get_ident,也就是執行緒id
我們看看ScopedRegistry是如何通過_操作的

class ScopedRegistry(object):
    def __init__(self, createfunc, scopefunc):
        self.createfunc = createfunc
        self.scopefunc = scopefunc
        self.registry = {}


    def __call__(self):
        key = self.scopefunc()
        try:
            return self.registry[key]
        except KeyError:
            return self.registry.setdefault(key, self.createfunc())
程式碼也很簡單,其實也就是根據執行緒id建立對應的session物件,到這裡我們基本已經瞭解了flask_sqlalchemy的魔法了,和flask cookie,g有異曲同工之妙,這裡有兩個小問題?
1.flask_sqlalchemy能否使用ThreadLocalRegistry?

    大部分情況都是可以的,但如果wsgi對多併發使用的是greenlet的模式就不適用了
2.上面create_scoped_session中partial是幹嘛的?
    前面我們說過scoped_session的session_factory是可呼叫物件,但_SignallingSession類並沒有定義__call__,所以通過partial支援

到這裡你就知道為什麼每次請求結束要self.session.remove(),不然為導致存放session的欄位太大

這裡說一下對db.relationship lazy的理解,看如下程式碼
class Role(db.Model):
    __tablename__ = 'roles'
    id = db.Column(db.Integer, primary_key=True)
    name = db.Column(db.String(64), unique=True)
    users = db.relationship('User', backref='role', lazy='dynamic')


class User(db.Model):
    __tablename__ = 'users'
    id = db.Column(db.Integer, primary_key=True)
    username = db.Column(db.String(64), unique=True, index=True)
    role_id = db.Column(db.Integer, db.ForeignKey('roles.id'))
假設role是已經獲取的一個Role的例項
lazy:dynamic => role.users不會返回User的列表, 返回的是sqlalchemy.orm.dynamic.AppenderBaseQuery物件
                當執行role.users.all()是才會真正執行sql,這樣的好處就是可以繼續過濾

lazy:select => role.users直接返回User例項的列表,也就是直接執行sql

注意:db.session.commit只有在物件有變化時才會真的執行update


四. flask moment原理

flask moment簡單封裝了moment.js,moment.js通過js提供了對時間的支援,感興趣的童鞋可以關注下,功能非常強大。flask moment原理很簡單,使用帶有時間的格式話字串在dom載入後,使用moment.js處理一下,
該步操作有moment.include_moment()完成。如果使用其它語言,如中文,呼叫moment.lang('zh-cn')
如果使用了flask bootstrap,只需要在最後新增以下程式碼即可(需要jquery支援)
{% block scripts %}
{{ super() }}
{{ moment.include_moment() }}
{{ moment.lang('zh-cn') }}
{% endblock %}
flask moment還提供了過了多長時間統計,refresh為True時,每分鐘重新整理一次,refresh也可為具體的重新整理時間,單位為分鐘
{{ moment(current_time).fromNow(refresh=True) }}


看上面我們知道,flask moment在模板中匯入了moment這個物件,這是如何實現的呢?
    def init_app(self, app):
        if not hasattr(app, 'extensions'):
            app.extensions = {}
        app.extensions['moment'] = _moment
        app.context_processor(self.context_processor)

    @staticmethod
    def context_processor():
        return {
            'moment': current_app.extensions['moment']
        }
通過app.context_processor給模板上下文添加了額為屬性
def render_template(template_name_or_list, **context):
    ctx.app.update_template_context(context)


在render_template中會把前面註冊的變數新增到context,所以在模板中就可以使用moment了,
而flask bootstrap是通過app.jinja_env.globals['bootstrap_find_resource'] = bootstrap_find_resource實現的
我們知道flask在初始化jinja環境的時候就將request,g,session等注入到全域性了
rv.globals.update(
            url_for=url_for,
            get_flashed_messages=get_flashed_messages,
            config=self.config,
            # request, session and g are normally added with the
            # context processor for efficiency reasons but for imported
            # templates we also want the proxies in there.
            request=request,
            session=session,
            g=g
        )
但我在看原始碼時發現_default_template_ctx_processor也會注入g,request,如下
def _default_template_ctx_processor():
    """Default template context processor.  Injects `request`,
    `session` and `g`.
    """
    reqctx = _request_ctx_stack.top
    appctx = _app_ctx_stack.top
    rv = {}
    if appctx is not None:
        rv['g'] = appctx.g
    if reqctx is not None:
        rv['request'] = reqctx.request
        rv['session'] = reqctx.session
    return rv
這不是重複嘛,有啥必要呢?
哈哈,認真看上面rv.globals.update的註釋部分能大概明白。
flask模板可以使用巨集,需要使用import匯入,此時匯入的模板不能訪問不能訪問當前模板的本地變數,只能使用全域性變數。
這也就是為什麼global中有g,request,session的理由,也即是為了支援在巨集中使用g物件
而本地變數匯入g等是為了效率的原因,具體細節需要參考jinja2的文件。