咱們知道,WEB服務器經過瀏覽器攜帶的cookie獲取session來判斷是不是同一用戶(或瀏覽器)。前端
cookie
和 session
並非同一個層面的東西。node
cookie
是實際真實存在的一個東西,是http協議規定的,如同一種載體,咱們能夠在響應頭裏面設置 cookie,只要你願意,你能夠在cookie裏面設置任何東西,無論是用戶信息用戶暱稱, 可是這樣有安全性風險,cookie裏面不適合有敏感性的信息,好比說,只放session_id
web
session
是一個抽象概念,是客戶端和服務端保持會話的一種方法,一種通用的機制。session
的意思是會話
,實現是:服務端把一個惟一標識和用戶身份的對應的關係存儲下來,存在redis
, 文件
, 數據庫
中均可以。客戶端出的請求帶上惟一標識,服務端從redis
或者 文件
或者 數據庫
中找出這個惟一標識 對應的身份,這種機制就被稱爲session
redis
session
機制大部分使用cookie
做爲載體運送這個惟一標識,也能夠採用url 鏈接、 自定義請求頭來實現。數據庫
對於小程序來講,也須要一個惟一的標識符來區分用戶,也就是session來保持會話,可是小程序沒有cookie, 所以咱們的惟一標識符會被存儲在 localstorage
裏面,每次發請求時,都會從localStorage
裏面拿到這個惟一標識符,帶在請求中。小程序
openid
和code
在平常開發中,咱們也常常聽到openid
和code
的概念。後端
openid
用來標識這個惟一的微信用戶,也就是說,一個微信用戶相對於一個公衆號(主體)的openid
是惟一的,是不會變的。微信小程序
那麼咱們如何才能知道 某一個用戶的 openid
呢?跨域
就是經過code
, 對於同一個用戶,每次獲取到的 code
都會改變,有有效期。咱們把code
做爲參數,調用指定的微信服務器的接口,就能夠拿到用戶的openid
。瀏覽器
那麼咱們如何才能拿到 code
呢?
微信內h5頁面的方法是:跳到指定的微信的承接頁面,再跳回到本頁面,url連接上就會被拼上code
。
小程序的方法是: 經過調用 wx.login()
方法,就能夠拿到用戶的code
知道了上面的前提條件,就能夠去實現一個微信小程序的登陸體系。
經過 wx.login()
獲取到用戶的code
經過wx.request()
方法請求咱們本身的後端,咱們本身的服務端把appid
, appsecret
和 code
一塊兒發送到微信服務器。 appid
和 appsecret
都是微信提供的,能夠在管理員後臺找到
微信服務器返回了 openid
咱們在本身的數據庫中,查找openid
,若是沒有查到記錄,說明該用戶沒有註冊,若是有記錄,則繼續往下走
咱們生成一個第三方session, 也就是session_id, 也就是用戶惟一標識符。在redis中,把session_id 和用戶的身份存進去。
返回 3rd_session
小程序把3rd_session
存到 storage 裏面
下次請求時,先從 storage
裏面讀取,而後帶給服務端
服務端從redis 裏面找到3rd_session
對應的記錄,而後校驗有效期
問題一:
爲何咱們要本身維護一個用戶數據庫,實現一個註冊體系?用微信的很差嗎?
由於咱們業務不光是在微信裏面玩,好比說,在app的場景下,咱們確定沒有辦法經過微信這一套來登陸。
問題二:
爲何仍需設置前端的登陸態,而不是每次用小程序的code換open_id?
由於用code換open_id的方式,須要等待wx.login() 獲取code, 須要等待node端請求微信服務器用code換取open_id。 相比於直接直接帶上登陸態,用戶等待時間更長。
最新版小程序中,只須要一個按鈕就能夠獲取到用戶的信息
獲取頭像暱稱
複製代碼
微信規定須要指定該btn的open-type
爲 getUserInfo
, 用戶信息會放在getUserInfo
的回調函數裏面。
若是用戶以前沒有受權過,則會彈出彈窗受權。
若是用戶已經受權過,則不須要彈出彈窗受權。
經過 wx.getSetting
方法能夠獲取到用戶的受權信息
wx.getSetting({
success(res) {
if (!res || !res.authSetting) {
wx.showToast({
title: '查詢受權失敗',
})
return;
}
this.setData({
authInfo: res.authSetting
})
}
})
複製代碼