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

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

示例代码：

//app.jsApp({  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文件基本上不需要加任何依赖

<!--小程序解密参数jar-->        <dependency>            <groupId>org.codehaus.xfire</groupId>            <artifactId>xfire-core</artifactId>            <version>1.2.6</version>        </dependency>        <dependency>            <groupId>org.bouncycastle</groupId>            <artifactId>bcprov-jdk16</artifactId>            <version>1.46</version>        </dependency>

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

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() //重新登录    ....  }})