一般我們web網站都會有cookie來儲存session ID，将使用者和伺服器保持在一次會話中，但是很遺憾，微信小程式不支援cookie，他的每一次請求就是一次會話，這樣就會産生一個問題，每次請求都需要确定目前的使用者是誰，但是我們又不能在每次請求的資料中攜帶使用者的資訊，這樣是不安全的。今天就介紹兩種方式來實作保持會話。
第一種：用戶端儲存session ID
1、通過wx.login接口擷取 code，将code傳遞到背景（一般背景都有shiro或者Spring security這種過濾器，該方法作為第一個啟動方法需要背景放過），背景通過code通路微信接口，傳回目前登陸的微信資訊。
2、背景通過微信的openID去資料庫的微信資訊表中查詢該微信号是否與背景使用者綁定過，如果綁定過，将該使用者資訊放入session中，并傳回已綁定标記，為綁定過，傳回為綁定标記。并且将會話ID傳回。
3、小程式拿到sessionID和是否綁定标記，将session ID存入緩存中或者在app.js中定一個全局變量用來存儲。如果未綁定，跳轉到綁定頁面，如果綁定，去往首頁。
4、因為背景的session都有過期時間，預設是半個小時，是以說為了確定小程式端的session ID不會過期，我們需要在他過期之前重新整理sessionID。
我們每過二十分鐘重新整理一次，也就是重新請求一次。
将該函數放到app.js的生命周期函數中，這樣一旦打開小程式就會執行
5、每次請求需要将sessionID放入cookie中，并将它設定頭request header中
第二種：小程式保持唯一辨別uuid（如果背景過濾器需要登陸驗證的話，小程式端的請求接口都需要放行），這個就不貼代碼了，基本和上面邏輯差不多，隻不過這次存的是uuid。
1、小程式請求微信，拿到code，請求背景并傳遞code
2、背景根據code請求微信，拿到openID
3、背景根據openID去微信資訊表查詢該openID是否綁定使用者，綁定了，傳回一個唯一表示uuid以及綁定辨別，沒有綁定，建立一個uuid以及未綁定辨別傳回給小程式
4、小程式判斷未綁定，跳轉到綁定頁面，根據輸入資訊+uuid傳回給背景綁定使用者，背景傳回是否綁定成功
5、根據綁定是否成功，小程式操作
小程式隻儲存uuid（相當于accesstoken），這個uuid是小程式與背景連接配接的橋。
注意：這兩種方法都是不安全的，試想一下如果sessionID被劫持到了，并且還處于目前會話中，黑客完全可以通過該session ID惡意擷取背景資料（類似CSRF攻擊）。uuid的話，因為這種請求被背景過濾器放過，是以完全可以直接請求背景資料了。