微信小程序登录态控制深入分析

微信小程序登录态控制与实战体验

随着微信小程序的日益普及，登录态控制成为了开发者们关注的焦点。最近，微信小程序开放了个人注册，这为开发者们提供了大展身手的机会。“菲麦日程”小程序正在积极推进中，届时将为大家带来全新的体验。在此，我想分享一下在微信小程序登录态控制中的与体验。

一、微信推荐的登录态控制流程

1. 小程序内通过wx.login接口获取code。

2. 将code传输到后台，后台向微信服务器发起https请求，以获取openid和session_key。

3. 后台生成一个自身的3rd_session（以它为key值，保存openid和session_key），并将其返回给前端。

值得注意的是，微信强调session_key不应在网络上传输，但为了应用的安全，openid的传输是可以接受的。

二、是否可以不遵循微信的建议？

虽然微信的建议是为了保障应用的安全，但在某些情况下，我们是否可以做出调整？例如，只使用openid作为登录凭证。确实，session_key具有过期时间，需要适时重新获取。但openid，作为每个小程序的唯一用户标识，是不会过期的。

直接使用openid作为登录凭证存在风险。手机上可以切换微信账户，如果直接缓存openid，可能会请求到错误账户的数据，导致数据混乱。在登录态过期后重新获取openid是更明智的选择。

三、基于redis的3rd_session维护

为了更高效地管理登录态，我们可以使用redis来维护3rd_session。redis作为一个内存数据库，非常适合用于维护会话态。我们可以生成一个唯一的随机串作为sessionid，以它为key，将openid和微信方的session_key作为value存入redis。

小程序登录态的过期时间对于开发者来说是一个谜。微信官方文档并没有明确说明。为了确保前后端会话过期时间的同步，我们需要不断和实践。

四、前后端会话过期时间的同步

在小程序登录态的时效之初，我遇到了一个棘手的问题。在code2session接口返回的数据中，有一个关键的字段expires_in，其值为7200。我曾以为将其值存储到redis中的sessionid即可实现同步。无论设置为7200还是一天的时长606024，都出现了小程序会话尚在有效期，而服务器端会话已经过期的情况。这导致小程序带着已缓存的sessionid到服务器端请求接口时，返回了未登录的提示。

在对wx.checkSession的中，我了解到它可以帮助检测小程序会话的过期情况。我们调整了策略：如果wx.checkSession检测到会话失效，那么带上已缓存在本地的sessionid（如果有的话），重新发起登录请求。后台则从code2session中获取新的请求结果，生成新的随机sessionid并存入redis，同时移除老的sessionid（如果有的话）。

不移除老sessionid会带两个问题。和使用open_id作为登录凭证一样，旧的sessionid永不过期，无用的session数据占用redis资源，可能导致访问性能下降。为了更有效地管理会话数据，我们必须确保旧的sessionid得到妥善处理。

五、以“脱贫致富指数”统计用户增长——不过是场娱乐游戏

为了给小程序的用户数一个有趣的名字——“脱贫致富指数”，我开始了用户数据统计的。为了统计使用小程序的用户数，我们需要一个表来保存用户数据。后台提供了一个接口，让小程序将用户数据上传进行注册操作。虽然这个功能可以合并到登录接口上，但每次登录都带上用户数据略显浪费。更合理的做法是为用户提供一个额外的注册接口。登录接口只需返回一个用户是否已经注册的标志，让客户端根据此决定是否需要获取用户信息并进行注册操作。这样，我们只需要在用户第一次登录时进行注册操作即可。

那么如何判断用户是第一次登录呢？我们首先需要判断登录请求中是否带有sessionid。如果没有，那肯定是第一次登录；但如果带有sessionid，就一定意味着这是已登录的用户吗？答案并非如此绝对。因为用户可能在同一设备上切换账户，那么之前的sessionid可能仍然存在于登录请求中。更可靠的做法是通过redis中的openid与code2session新请求到的openid进行比对，确认用户是否曾经登录过。如果两者一致，证明用户已登录过；否则，仍需要用户进行注册操作。虽然这个过程花费了一些时间，但通过思考和摸索，我们的代码将变得更加完善。感谢大家的阅读和支持！希望能对大家有所帮助！