微信小程序开发：打通微信和小程序之间用户数据的坑

 

背景：公司有APP和公众号，都绑定了开放平台，用unionid来区分用户。一天需要做一个小程序，这个时候要打通我们的用户库，然后必须拿到小程序unionid。当时公众号与小程序都互相绑定，调用前端调用小程序官方文档的登录方法拿到code给我换取用户标识，如下：

示例代码：

//app.js
App({
  onLaunch: function() {
    wx.login({
      success: function(res) {
        if (res.code) {
          //发起网络请求
          wx.request({
            url: 'https://test.com/onLogin',
            data: {
              code: res.code
            }
          })
        } else {
          console.log('登录失败！' + res.errMsg)
        }
      }
    });
  }
})

我拿code去换取用户信息，官方文档明确指出不让小程序端获取用户敏感信息，所以都是服务端来完成的，请求链接跟微信获取用户信息非常相似，这个时候被第一个坑踩中了：

解决上面的坑，然后就来拉取用户标识，小程序code是得不到用户所有的信息，官方文档又给出说明：

其中满足的条件官方文档说的不是很清晰，我们当时小程序和公众号互绑了，但是就只有微信绑定到了开放平台上，小程序没有，我们以为这样可以返回unionid，第二个坑小程序也是需要绑定开放平台的，当时以为是符合unionid的情况，以为这样获取不到，继续查看官方文档：

返回的数据中有一个encryptedData加密参数，包括敏感数据在内的完整用户信息的加密数据，接下来就是解密了，官方提供了c++,Node,python语言的demo，Java找到的基本上都是如下：

需要导入两个重要的jar包：

import org.bouncycastle.jce.provider.BouncyCastleProvider;
import org.codehaus.xfire.util.Base64;

 pom文件也需要导入下面的依赖，xfire是用于解密base64的编码，不导入这个包也可以用base64decode进行解码，bouncycastle亲测没有用，不导入也是可以解密成功的，所以图简单的pom文件基本上不需要加任何依赖

        
            org.codehaus.xfire
            xfire-core
            1.2.6
        
        
            org.bouncycastle
            bcprov-jdk16
            1.46
        

接下来就是解密的算法了：

public static JSONObject getUserInfo(String encryptedData, String sessionKey, String iv) {
        try {
            byte[] dataByte = Base64.decode(encryptedData);
            byte[] keyByte = Base64.decode(sessionKey);
            byte[] ivByte = Base64.decode(iv);

            //密钥必须是16位的整数倍
            int base = 16;
            if (keyByte.length % base != 0) {
                int groups = keyByte.length / base + (keyByte.length % base != 0 ? 1 : 0);
                byte[] temp = new byte[groups * base];
                Arrays.fill(temp, (byte) 0);
                System.arraycopy(keyByte, 0, temp, 0, keyByte.length);
                keyByte = temp;
            }
            // 初始化
            Security.addProvider(new BouncyCastleProvider());
            Cipher cipher = Cipher.getInstance("AES/CBC/PKCS7Padding","BC");
            SecretKeySpec spec = new SecretKeySpec(keyByte, "AES");
            AlgorithmParameters parameters = AlgorithmParameters.getInstance("AES");
            parameters.init(new IvParameterSpec(ivByte));
            // 初始化
            cipher.init(Cipher.DECRYPT_MODE, spec, parameters);
            byte[] resultByte = cipher.doFinal(dataByte);
            if (null != resultByte && resultByte.length > 0) {
                String result = new String(resultByte, "UTF-8");
                return JSONObject.parseObject(result);
            }

        } catch (Exception ex) {
            System.out.println("解密失败");
            ex.printStackTrace();
        }
        return null;
    }

 都弄好了后就是实现方法了，当时思路是让前端登录拿到code的同时也去访问用户信息拿到解密的关键数据，我们当时用的是get请求，这个时候踩了个第三个大坑，前端传的加密参数encryptedData中有用+号拼起来的长串字符串，在传输的时候+字符会自动转译为空格，如下：

14zZ4xDT39FrcltAZ3VpAD0ZYlHnjRPDGChIYMSteakmghnZbkxleBuo twdkfEIaJxtj/c0nY wQArWz/7cG7F7YhNRMh3 4ADLVSzoCCJigcCN9UOxl6EdeTyfTGUFSh32OxhVF3469sB0LdYW15C hIMZ3esiVNuugcnayJHM5PRVOepWetlZYUT/5gr7wWkIJk IG8gYdGQC7zx9gsYiF7Db/nVll3fwQOMWxPOZGN5RAb83sghik2kpn18bUTGJp6QyCwOaemprpPQ3GK5pnF3KzEo0LX4xwPzN7sRE/f/HB0n1JFou2PlrTYfgyhndBnmSz/lKXEyzpzolL5UfKlFDQPs 1qsuuDdGtk7qxdGQfbs1FgUW2mfnRmQnbbAzeByjQaAL2xL2NpNiX72oNhMMejoR0zU6anD4knneRbvAXjhhU2c1tzoupR7UaQqljpIOHQDtL4B4A qa2mYhwm/qy1juNnQYFQKHKak=


14zZ4xDT39FrcltAZ3VpAD0ZYlHnjRPDGChIYMSteakmghnZbkxleBuo+twdkfEIaJxtj/c0nY+wQArWz/7cG7F7YhNRMh3+4ADLVSzoCCJigcCN9UOxl6EdeTyfTGUFSh32OxhVF3469sB0LdYW15C+hIMZ3esiVNuugcnayJHM5PRVOepWetlZYUT/5gr7wWkIJk+IG8gYdGQC7zx9gsYiF7Db/nVll3fwQOMWxPOZGN5RAb83sghik2kpn18bUTGJp6QyCwOaemprpPQ3GK5pnF3KzEo0LX4xwPzN7sRE/f/HB0n1JFou2PlrTYfgyhndBnmSz/lKXEyzpzolL5UfKlFDQPs+1qsuuDdGtk7qxdGQfbs1FgUW2mfnRmQnbbAzeByjQaAL2xL2NpNiX72oNhMMejoR0zU6anD4knneRbvAXjhhU2c1tzoupR7UaQqljpIOHQDtL4B4A+qa2mYhwm/qy1juNnQYFQKHKak=         

当时都怀疑半天解密算法了，后来对比前后端数据才发现问题所在。解决办法有两个，一个是在前端传输的时候对参数进行URL编码，然后再后端来解码后进行解密，第二种办法就是用post请求已json对象的方式传输，完美解决。

当然并没有完，当时以为没问题，结果推服务器上测试时踩了第四个坑，发现会出现间歇性的解密失败，线下进行了不断的登录调试，发现于code换取的sessionkey参数过期时间有关，每次新的sessionkey第一次解密的时候都会失败，当时考虑应该就是碰到了临界问题，但是官方也比较坑没有说sessionkey的具体缓存时间，只说明用户越频繁使用小程序，session_key有效期越长。服务器端缓存也没有意义。

解决办法，小程序官方有一个获取sessionkey：

示例代码：

wx.checkSession({
  success: function(){
    //session_key 未过期，并且在本生命周期一直有效
  },
  fail: function(){
    // session_key 已经失效，需要重新执行登录流程
    wx.login() //重新登录
    ....
  }
})

现在逻辑就变更为了每次去判断sessionkey是否过期，没有过期再来进行解密，过期了就重新拉取解密相关参数。至此，小程序登录与公众号用户打通完全实现。坑也比较多，很多的方法都没有给具体服务端的实现，都是靠前端的配合，没有微信方便都可以服务端自己来解决。当然也可以用全局access_token进行获取，下篇编写。希望对大家开发会有帮助，如有错误也欢迎大家指正。