Flask 源碼解析：session

原文：http://cizixs.com/2017/03/08/flask-insight-session

全文約 11700 字，讀完可能需要 18 分鐘。

這是 flask 源碼解析系列文章的其中一篇，本系列已發布文章列表：

session 簡介

在解析 session 的實現之前，我們先介紹一下 session 怎麼使用。session 可以看做是在不同的請求之間保存數據的方法，因為 HTTP 是無狀態的協議，但是在業務應用上我們希望知道不同請求是否是同一個人發起的。比如購物網站在用戶點擊進入購物車的時候，伺服器需要知道是哪個用戶執行了這個操作。

在 flask 中使用 session 也很簡單，只要使用 導入這個變數，在代碼中就能直接通過讀寫它和 session 交互。

上面這段代碼模擬了一個非常簡單的登陸邏輯，用戶訪問 來登陸，後面訪問頁面的時候 ，會返回該用戶的名字。我們看一下具體的操作實例（下面的操作都是用httpie來執行的，使用 命令也能達到相同的效果）：

直接訪問的話，我們可以看到返回 ：

然後我們模擬登陸請求， 是列印出請求， 是告訴伺服器這是表單數據， 是把請求的 cookie 等信息保存到這個變數中，後面可以通過變數來指定 session：

最重要的是我們看到 response 中有 的頭部，cookie 的鍵是 ，值是一堆看起來隨機的字元串。

繼續，這個時候我們用 參數把這次的請求帶上保存在 中的信息，登陸後訪問，可以看到登陸的用戶名：

這次注意在發送的請求中，客戶端帶了 頭部，上面的值保存了前一個請求的 response 給我們設置的值。

總結一下：session 是通過在客戶端設置 cookie 實現的，每次客戶端發送請求的時候會附帶著所有的 cookie，而裡面保存著一些重要的信息（比如這裡的用戶信息），這樣伺服器端就能知道客戶端的信息，然後根據這些數據做出對應的判斷，就好像不同請求之間是有記憶的。

解析

我們知道 session 是怎麼回事了，這部分就分析一下 flask 是怎麼實現它的。

請求過程

不難想像，session 的大致解析過程是這樣的：

請求過來的時候，flask 會根據 cookie 信息創建出 session 變數（如果 cookie 不存在，這個變數有可能為空），保存在該請求的上下文中

視圖函數可以獲取 session 中的信息，實現自己的邏輯處理

flask 會在發送 response 的時候，根據 session 的值，把它寫回到 cookie 中

注意：session 和 cookie 的轉化過程中，應該考慮到安全性，不然直接使用偽造的 cookie 會是個很大的安全隱患。

在flask 上下文那篇文章中，我們知道，每次請求過來的時候，我們訪問的 和 變數都是 實例的變數。在 方法的最後有這麼一段代碼：

它初始化了 變數，保存在 上，這樣後面就能直接通過 來使用它。如果沒有設置 變數， 就會返回 None，這個時候會調用 來生成一個空的 session，這個特殊的 session 不能進行任何讀寫操作，不然會報異常給用戶。

我們來看看 方法：

在 中，所有和 session 有關的調用，都是轉發到 的方法調用上（這樣用戶就能用自定義的 來控制 session 的使用）。而默認的 有默認值：

後面遇到 session 有關方法解釋，我們會直接講解 的代碼實現，跳過中間的這個轉發說明。

根據請求中的 cookie 來獲取對應的 session 對象。之所以有 參數，是因為根據 app 中的安全設置（比如簽名演算法、secret_key）對 cookie 進行驗證。

這裡有兩點需要特殊說明的：簽名演算法是怎麼工作的？session 對象到底是怎麼定義的？

session 對象

默認的 session 對象是 ，這個類就是一個基本的字典，外加一些特殊的屬性，比如 （flask 插件會用到這個變數）、 （表明實例是否被更新過，如果更新過就要重新計算並設置 cookie，因為計算過程比較貴，所以如果對象沒有被修改，就直接跳過）。

怎麼知道實例的數據被更新過呢？ 是基於 實現的，這個類可以指定一個函數作為 參數，每次有字典操作的時候（ 、 、 、 、 、 、 ）會調用這個函數。

NOTE： 的實現很巧妙，但是並不複雜，感興趣的可以自己參考代碼。主要思路就是重載字典的一些更新操作，讓它們在做原來事情的同時，額外調用一下實現保存的某個函數。

對於開發者來說，可以把 簡單地看成字典，所有的操作都是和字典一致的。

簽名演算法

都獲取 cookie 數據的過程中，最核心的幾句話是：

其中兩句都和 有關， 保證了 cookie 和 session 的轉換過程中的安全問題。如果 flask 發現請求的 cookie 被篡改了，它會直接放棄使用。

我們繼續看 方法：

我們看到這裡需要用到很多參數：

：密鑰。這個是必須的，如果沒有配置 就直接使用 會報錯

：為了增強安全性而設置一個 salt 字元串（可以自行搜索「安全加鹽」了解對應的原理）

：序列演算法

：其他參數，包括摘要/hash 演算法（默認是 ）和 簽名演算法（默認是 ）

是庫的類，主要用來進行數據驗證，增加網路中數據的安全性。 提供了多種 ，可以方便地進行類似 json 處理的數據序列化和反序列的操作。至於具體的實現，因為篇幅限制，就不解釋了。

應答過程

flask 會在請求過來的時候自動解析 cookie 的值，把它變成 變數。開發在視圖函數中可以使用它的值，也可以對它進行更新。最後再返回的 response 中，flask 也會自動把 session 寫回到 cookie。我們來看看這部分是怎麼實現的！

之前的文章講解了應答的過程，其中 方法在根據視圖函數的返回生成 response 對象之後，會調用 方法進行處理。 方法的最後有這樣兩句話：

這裡就是 session 在應答中出現的地方，思路也很簡單，如果需要就調用 ，把當前上下文中的 對象保存到 response 。

的代碼和 對應：

這段代碼也很容易理解，就是從 和 變數中獲取所有需要的信息，然後調用 設置最後的 。這樣客戶端就能在 cookie 中保存 session 有關的信息，以後訪問的時候再次發送給伺服器端，以此來實現有狀態的交互。

解密 session

有時候在開發或者調試的過程中，需要了解 cookie 中保存的到底是什麼值，可以通過手動解析它的值。 在 中的值，是一個字元串，由句號分割成三個部分。第一部分是 加密的數據，第二部分是時間戳，第三部分是校驗信息。

前面兩部分的內容可以通過下面的方式獲取，代碼也可直觀，就不給出解釋了：

總結

flask 默認提供的 session 功能還是很簡單的，滿足了基本的功能。但是我們看到 flask 把 session 的數據都保存在客戶端的 cookie 中，這裡只有用戶名還好，如果有一些私密的數據（比如密碼，賬戶餘額等等），就會造成嚴重的安全問題。可以考慮使用flask-session這個三方的庫，它把數據保存在伺服器端（本地文件、redis、memcached），客戶端只拿到一個 sessionid。

session 主要是用來在不同的請求之間保存信息，最常見的應用就是登陸功能。雖然直接通過 自己也可以寫出來不錯的登陸功能，但是在實際的項目中可以考慮這個三方的插件，方便我們的開發

參考資料

flask-session github page

Flask 源碼閱讀筆記

題圖：pexels，CC0 授權。

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！