Kong外掛程式session分析

因為最近要開發自定義kong認證外掛程式，比如使用casbin鑑權或者cas sso 單點登入等功能。遇到避免二次登入的問題，故考慮使用kong 自帶的session外掛程式。

那麼就遇到了第乙個問題，session外掛程式是怎麼工作的？

kong session 原始碼位址

在plugins目錄我們看到乙個標準的kong外掛程式檔案列表

handler.lua定義了優先順序為1900，並將hearder_filter,和access兩個方法委託給了hearder_filter,access兩個檔案。

handler的優先順序為1900，高於所有內建認證的外掛程式。那麼按照從高到底執行的邏輯，session外掛程式應該優先於所有認證外掛程式的執行。

既然session外掛程式是第乙個執行的，並不知道後續認證外掛程式是否認證成功，那麼session外掛程式怎麼可能又知道認證成功後去設定session呢?

經研究，我發現外掛程式認證順序並不完全像文件上說的，按照優先順序次序執行的。

具體來說，外掛程式階段分為兩個部分，即將請求實際**前和**後。

從上到下，access及之前是**前的動作，hearder_filter及之後是**後請求返回後的動作。在不同外掛程式間，**前的動作是按priority優先順序從大到小的順序執行，而**後的動作按優先順序從小到大執行。

這樣就很好明白，session外掛程式首先是在access中判斷是否有cookie，驗證許可權。然後執行許可權外掛程式驗證。如果驗證成功最後執行session外掛程式中header_filter邏輯，寫session。用於下次請求。

看下原始碼，果然是這樣。

在header_filter.lua中，_m.execute(conf)方法前兩行：

local credential = kong.client.get_credential()
local consumer = kong.client.get_consumer()

加上之後的邏輯我們可以看到，其實session判斷的是以上兩個變數。

所以我們自定義認證外掛程式中，priority 小於1900，然後在認證結束後設定kong.client.get_credential()，kong.client.get_consumer()兩個變數就好了。

具體設定方法可以使用kong.client.authenticate(consumer, credential)方法。

以上