今天中午跟我的上司一顿争辩，没争辩过他们（本身我也不是争辩的好手）。争辩的内容就是一个微信公众号下多个小程序登录的问题，哈，要是不解决我真是寝食难安！！！
我们公司的小程序框架都是我搭建的，前几代就不说了。最后一代相对成熟的是根据openId生成userId，把userId放到app.js中作为全局变量。这样，只要拿到userId就可以去Redis取到任何想要的数据。
但是这一版我发现还是有问题，就是用户第一次进入该公众号绑定的其中一个小程序以后，将openID，和手机号放到user信息中（注意，第一次没有unionID），但是第二次进入该公众号绑定的另一个小程序后。还需要用户输入手机号进行用户身份的辨认，因为第二次生成的openID与unionID不足以辨认用户身份。这样的体验很不好。所以我下一代小程序框架的构想是，当获取userId时，就跳到主小程序（含用户登录模块的那个），登录成功以后，将userID返回原来的那个小程序，然后放在那个小程序的app.js中。这样一来，即节约了代码，还能优化流程。但是我的上司认为其他小程序的openID也一定要存的，但是我认为openID只能作为获取用户信息的作用，并不能作为唯一标识。
谁来说服我一下，我快要被自己犟死了！！！
是啊，后来我发现还是要存openId。
说的就是固定不变是不对的, 前端保存的不管是token还是session(你用的是userId) 都必须有过期和刷新策略才能保证安全性
这块确实要作为下一个版本的优化，还有getUserInfo那也要优化。
现在有个问题，登录能不能独立出来做成一个插件？反正就是一个获取token的过程嘛。
前端就应该用token，而不是任何ID，ID应该是后端根据token来获取。楼主用userID来做key值也是非常不安全的，userID是完全不能当token来用的。
不一定第一次就会没有 unionId，如果用户之前关注过绑定小程序的微信公众号，第一次进入小程序是游 unionId的。
第一次进入时没有unionId，学到了
传session_id去后台的session或者Redis里去取。如果你后台一个用户绑定多个openId，这块你还需要传递一个参数。以确认获取哪个app下的openId。
对的，因为假设第一次用户进入小程序，这个时候是没有unionId。用户第二次进入别的小程序，这个时候才有unionId,但是因为你第一次没有获取到，所以unionId也无法辨别用户是哪个用户。所以这块就需要拿用户第一次进入小程序的手机号进行辨认了，第三次以后就可以用unionId了。
我想问下，如果openid放在了后台存储，前端只返回session_id。那如果前端调用接口时，需要openid作为参数，那要如何处理啊？
您所查看的回复已隐藏。