从技术角度去解析重庆微信小程序开发登陆环节的安全控制，今天我们就细致的剖析如何去做，当然我不会直接分享代码，由于程序代码因人而异，你能够这样写，我能够那样写。所以我只分享原理，引见办法，至于详细的编程完成，置信关于正在阅读这篇文章的你不算什么。
之前有玩家想运用永不过时的opind来停止用户登录态的维护，但是招致了很多问题：
... 从技术角度去解析重庆微信小程序开发登陆环节的安全控制，今天我们就细致的剖析如何去做，当然我不会直接分享代码，由于程序代码因人而异，你能够这样写，我能够那样写。所以我只分享原理，引见办法，至于详细的编程完成，置信关于正在阅读这篇文章的你不算什么。
之前有玩家想运用永不过时的opind来停止用户登录态的维护，但是招致了很多问题：
一：永不过时的openid一旦被截取，那么这个用户的一切数据就全部透明了！这是十分风险的！！！
二、假如运用永不过时的openid缓存在本地来维护用户登录态会招致用户数据乱传！何为乱传，用户A运用小程序获取到了opid并缓存，假如这时分用户在同一设备切换了微信账号用户B，再次进入微信小程序，这时分曾经有缓存的用户A的openid，这时分就不会提示登录。这时分用不B就运用的是用户A的数据！这也是十分风险的！！！
好了，看来我们还是运用微信官方引荐的运用自定义3rdsessionid来处理了。维护3rd_session需求一个内存数据库，这里我选用了redis维护会话态是内存数据库的典型应用场景，毕竟量小，并且请求速度快，这么一个小应用，当然也能够本人在内存中维护一个对象来停止会话id的处置，但是肯定难以跟一个成熟的系统相媲美
抛开代码完成，这似乎就是一句话能够概括的事情，生成一个独一的随机串sessionid，以此为key，openid和微信方的session_key为value存入redis，并把sessionid传回给客户端。
但是，翻遍小程序的官方文档，除了一句听说的wx.checkSession对开发者来说是透明的，并没有小程序登录态何时过时的详细阐明，如何才干同步前后端的会话过时时间呢？
前后端会话过时时间同步
假如wx.checkSession检测到会话失效，那么带上曾经缓存在本地的sessionid(假如有的话)，重新发起登录恳求，后台从code2session中拿到新的恳求结果后，生成新的随机sessionid并入库reids，并且把老的sessionid移除（假如有的话）
当然不移除也不会带来什么功用上的影响，但是会存在两个问题，首先，跟运用open_id作为登录凭证一样，旧的sessionid永不过时，其次，无用的session数据占用redis资源，会拖垮访问性能。
为了统计运用小程序的用户数，需求一个表来保管用户数据，后台提供一个接口，让小程序将用户数据传上来停止一个注册操作，当然能够把这个功用兼并到登录接口上，每次登录都把前端小程序取得的微信誉户数据带上，假如发现数据库中还没有该用户的信息，则停止入库操作
不难发现，其实只需求用户第一次登录的时分注册一次就行了，所以上述办法固然烦琐，但是有点糜费带宽，所以应该额外提供一个注册接口，登录接口只需求返回一个用户能否曾经注册的标志，让客户端决议能否需求获取用户信息，停止注册操作（当然后台也不会让同一个用户反复入库）
那么问题就变成如何判别用户是第一次登录了：
1）判别登录恳求中有没有带上sessionid，假如没带上，肯定是第一次登录；假如带上了就是登录过的用户？不，别忘了，前面说过，用户可能会在同一设备切换账户，那就有可能在登录接口中带上了他人sessionid，那并不能标明用户曾经登录过
2）经过带上来的sessionid从redis中拿到openid，跟在code2session新恳求到的openid停止比对，假如分歧，能够证明用户曾经登录过，否则，仍需求用户停止注册
