微信小程序的令牌流程

  • Post author:
  • Post category:小程序


我们可以自己设计一套账号密码体系。我们可以自己设计一套账号密码体系,然后模拟登陆和获取用户令牌。

但是小程序是构建微信下面的,微信已经有了身份认证体系,我们没有必要自己设计账号密码体系。我们可以借用微信体系来做自己的权限体系。所以不需要传入账号密码了,小程序为每一个登录的用户生成Code,Code就是数字码。我们需要把Code码传向getToken接口。Code码是啥,既然我们没有自己的用户身份体系,那么我们必须有一个凭据去微信微服务,去换取用户身份标识。我们在getToken里得到Code码,我们向微信服务器发送请求,然后把Code码传递给微信服务器,微信服务器在接收到code码之后,她会返回给你两个主要信息openid和session_key。这个openid就是用户身份标识。我们最重要的就是要给每一个用户生成ID号,比如说我们在传入账号密码之后,写数据库的时候,你的数据库就会帮你生成代表用户唯一身份的ID,这个ID我们通常叫做UID。这个ID我们依附微信,所以要微信给我们返回openid,这个openid简单理解就是用户身份标识。这个openid不仅仅是用于用户身份标识,还有别的用处。比如说我们做微信支付,就需要openid。使用code换取的信息除了openid还有session_key。我们简单说下session_key的作用(有些产品用不到),在小程序里可以直接访问服务器拿到加密信息,由于这个信息是加密的,所以你想解密这个信息就需要session_key。之所以要解密信息是因为这个信息包含了一个变量,这个变量 叫做


unionid


,这个unionid和我们普通ID一样的意义。这个unionid表示的是用户的唯一标识,但是区别在于openid一个用户针对一个小程序是一个openid。但是一个用户在不同的小程序openid是不同的,哪怕小程序是属于同一个账户下的(一个身份申请很多小程序)。那么同一个用户,同一个身份注册小程序,他的openid是不同的,如果让一个身份下面所有小程序他的id是相同的,就是使用unionid。这个unionid不仅在小程序相同的,只要是同一个账号注册的小程序,公众号,服务号,这些体系下面的所有unionid对于同一个用户来说,都是相同的。我们要做不同小程序的用户关联,要保证用户id唯一,这个时候openid就不行了,必须使用unionid,因为unionid是不变的。

openid作用:1代表用户唯一标识,2比如说做微信支付,是需要使用openid的也就是说他除了身份标识之外,还要有一些功能性的作用。

在我们业务层里,我们通过微信服务器拿到openid之后,我们需要把openid存起来,存到数据库里。我们没有自己做用户的身份权限,而是自己做身份权限,最终拿到了用户的唯一标识。并且把唯一标识存储起来了。此时我们用户身份体系就建立完成了。我们要考虑一下,客户端如何访问我们的API,我们需要把openid返回到客户端,让客户端每次访问都携带openid,这样就知道你这个用户身份是否可以访问接口。我们可以不可以 直接把openid返回到小程序里,让小程序在下一次访问我们的下单接口的时候,携带openid?技术上面可以,放到实际情况,我们不能把openid返回到小程序。2个原因,1openid这种用户信息,不应该存储到客户端,出于安全性考虑,不介意把用户ID作为标识,返回到客户端。2 openid固定不变,所以说openid没有失效期。如果这个openid一但传到客户端去,丢失了之后,安全性非常差,一定要是有一个失效期的id。解决方法就是生产令牌,把令牌返回到客户端去,同时令牌是具有一定有效期的。下次访问就需要携带令牌,你通过令牌,再去找到对应令牌的openid 从而,间接拿到openid。

切记openid不要传到客户端去!只能放在服务器。

同时为了减轻数据库压力,比如说有很多HTTP请求,我们需要缓存机制。数据库持久化记录openid,但是令牌,不要存到数据库了。我们验证是为了验证令牌是否合法,所以说我们可以把令牌存储在缓存中。这样的一个是节约了数据库性能压力,另外也可以加快用户的访问速度。因为缓存查询绝对比查询数据库要快的。不过缓存的维护非常麻烦,远远比数据库麻烦。所以不要乱用。

小程序访问接口就很简单了,小程序只需要携带令牌,然后我们的服务器校验令牌,就是他不会直接查数据库了,是和缓存读取相关信息,并且校验,验证之后才会调用下单接口。如果不合法就会像客户端返回异常。


我们在小程序拿到令牌之后,携带令牌就可以访问受保护的接口。小程序携带令牌,在address接口到缓存里面换取UID。这样做的好处是,如果不是这样一种形式,而是小程序是从postbody提交到Address里去的,这就会让A用户和B用户(都是合法用户),他们都有Token令牌,A用户的令牌,但是Body里的Uid传递的是B用户的。如果Address接口使用的Body的Uid,这就会变成A用户修改B用户的用户地址。我们这样获取UID的方法就避免了这个问题,就不要明文传递,你携带你的令牌就好了,我自然有办法得到你的Uid。不过如果B用户令牌丢失了,给A用户拿到了,A用户用B用户的令牌来访问,我们的接口就真的没办法了╮(╯▽╰)╭所以令牌一定要有有效期。不能让令牌永久有效。



版权声明:本文为jhkj_5154原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。