咱们知道,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
})
}
})
复制代码