微信小程式登入態控制深入分析
最近微信小程式終於開放了個人註冊，我當然不程式設計客棧能浪費這個炫技的好機會，「菲麥日程」小程式正在全力推進中，盡請期待~~
在登入態控制中，摸索嘗試了小一陣子，特此分享
一、微信建議的登入態控制
說明：1）小程式內通過wx.login介面獲得code
2）將code傳入後台，後台對微信伺服器發起乙個https請求換取openid、session_key
3）後台生成乙個自身的3rd_session（以此為key值保持openid和session_key），返回給前端。
ps:微信方的openid和session_key並沒有發回給前端小程式
4）小程式拿到3rd_session之後保持在mzayoukfi本地
5）小程式請求登入區內介面，通過wx.checksession檢查登入態，如果失效重新走上述登入流程，否則待上3rd_session到後台進行登入驗證
二、可不可以不接受它的建議
不是我反骨，而是我的微信小程式不需要獲取什麼私密資料，用不到se程式設計客棧ssion_key，只需要乙個openid，微信特別強調了，為了自身應用安全，session_key 不應該在網路上傳輸，可沒說不可以傳輸openid，那麼如果我將openid直接返回給前端小程式，會不會方便很多？下面我們來具體分析下：
永不過期的openid：
要知道，session_key有過期時間，必須適時重新獲取，而針對每乙個小程式，唯一標識使用者的openid可不會過期，如果只在使用者第一次登入的時候，通過後台請求到openid，小程式快取到本地，之後每次請求都以這個openid作為唯一憑證，豈不是一本萬利~~
事實上，上面的做法忽略了乙個致命的問題，手機上是可以切換微信賬戶的，如果手機i上原先登入了賬戶a，已經儲存了使用者a的openid，有一天手機i上切換到了賬戶b上，小程式檢測到openid存在，並不會重新獲取openid，那麼賬戶b就請求到了賬戶a的資料，這就造成資料亂象了
登入態過期後重新獲取openid：
上述的問題並不能打消我使用openid作為登入憑證的念頭，只需要稍作改進，資料就不會亂竄：每次進入小程式通過wx.checksession檢測登入是否失效，如果失效重新獲取openid，要知道，手機切換了登入賬號，登入態一定會過期，這樣雖不能一本萬利，但也足夠省心。
這個時候應該有乙個然而，以永不過期的openid作為登入憑證，並不是明智之舉，一旦被人截獲，就再也沒有翻身的機會了，而維護乙個第三發的session，至少擁有有效期，這在很大程度上增加了安全性。並且，現在不需要使用session_key，不代表以後，保持系統的可擴充套件性，才能以不變應萬變
事實證明，我還是應該接受它的建議
三、基於mzayoukfiredis維護3rd_session
維護3rd_session需要乙個記憶體資料庫，這裡我選用了redis
維護會話態是記憶體資料庫的典型應用場景，畢竟量小，並且要求速度快，這麼乙個小應用，當然也可以自己在記憶體中維護乙個物件來進行會話id的處理，但是肯定難以跟乙個成熟的系統相媲美
拋開**實現，這似乎就是一句話可以概括的事情，生成乙個唯一的隨機串sessionid，以此為key，openid和微信方的session_key為value存入redis，並把sessionid傳回給客戶端。
但是，翻遍小程式的官方文件，除了一句據說的wx.checksession對開發者來說是透明的，並沒有小程式登入態何時過期的具體說明，如何才能同步前後端的會話過期時間呢？
四、前後端會話過期時間同步
一開始，我還是試圖尋找小程式的登入態時效
在code2session介面返回的資料中，有乙個可疑的字段expires_in，它的值是7200，似乎儲存到redis中的sessionid設定為7200就可以同步了。可是實踐的結果再次讓人失望，不管是設定成7200還是60*60*24（一天），都出現了小程式會話尚在有效期，而伺服器端會話已經過期的情況，這直接導致了小程式帶著已經快取的sessionid到伺服器端請求介面，返回未登入的情況
看來還是只有wx.checksession才知道小程式會話啥時候過期，於是，作戰方案重新做了調整，如果wx.checksession檢測到會話失效，那麼帶上已經快取在本地的sessionid(如果有的話)，重新發起登入請求，後台從code2session中拿到新的請求結果後，生成新的隨機sessionid並入庫reids，並且把老的sessionid移除（如果有的話）
當然不移除也不會帶來什麼功能上的影響，但是會存在兩個問題，首先，跟使用open_id作為登入憑證一樣，舊的sessionid永不過期，其次，無用的session資料占用redis資源，會拖垮訪問效能
五、「脫貧致富指數」統計
我給小程式的使用者數安了乙個高大上的名字「脫貧致富指數」，純屬娛樂，切勿當真
為了統計使用小程式的使用者數，需要乙個表來儲存使用者資料，後台提供乙個介面，讓小程式將使用者資料傳上來進行乙個註冊操作，當然可以把這個功能合併到登入介面上，每次登入都把前端小程式獲得的微信使用者資料帶上，如果發現資料庫中還沒有該使用者的資訊，則進行入庫操作
不難發現，其實只需要使用者第一次登入的時候註冊一次就行了，所以上述方法雖然簡便，但是有點浪費頻寬，所以應該額外提供乙個註冊介面，登入介面只需要返回乙個使用者是否已經註冊的標誌，讓客戶端決定是否需要獲取使用者資訊，進行註冊操作（當然後台也不會讓同乙個使用者重複入庫）
那麼問題就變成如何判斷使用者是第一次登入了：
1）判斷登入請求中有沒有帶上sessionid，如果沒帶上，肯定是第一次登入；如果帶上了就是登入過的使用者？不，別忘了，前面說過，使用者可能會在同一裝置切換賬戶，那就有可能在登入介面中帶上了別人sessionid，那並不能表明使用者曾經登入過
2）通過帶上來的sessionid從redis中拿到openid，跟在code2session新請求到的openid進行比對，如果一致，可以證明使用者曾經登入過，否則，仍需要使用者進行註冊
總結時間是浪費了那麼一些，但是進過思考摸索，**肯定更完備了~~
本文標題: 微信小程式登入態控制深入分析
本文位址: /ruanjian/j**a/187322.html
微信小程式中使用者登入和登入態維護
讓使用者登入，標識使用者和獲取使用者資訊，以使用者為核心提供服務，是大部分小程式都會做的事情。我們今天就來了解下在小程式中，如何做使用者登入，以及如何去維護這個登入後的會話 session 狀態。引用小程式官方文件的登入流程圖，整個登入流程基本如下圖所示 登入流程圖 下面我們來逐步分解一下這個流程圖...
深入分析 微信小程式與H5的區別
第一條是執行環境的不同。小程式的開發過程中會用到html5相關的技術 並非全部 官方文件中著重強調了指令碼內是無法使用瀏覽器中常用的window物件和document物件 基於這一點，像zepto jquery這種操作dom的庫就被完全拋棄了 第二條是開發成本的不同。這裡我提出了乙個問題，當我們面對...
微信小程式登入流程 微信登入
提高使用者體驗 制定產品策略 token 登入態是個邏輯詞彙，token可以理解為登入態的具象化 資料化，在上面的流程圖中，可以看到token是由開發者伺服器建立的乙個字元，而且需要跟openid和session key相關聯，關聯完成之後開發者伺服器將 token下發到客戶端，客戶端儲存在本地，後...