背景
最近在对接一个同事写的支付公用模块，然后对第三方服务引起一两个小思考。
思考
回调
来看看我们同事是如何做回调的。
首先，请求支付接口的时候，将回调URL作为请求body的一个参数[不加密]。
{
"xxx": "xxx",
"xxx": "xx",
"xxxxx": "xxxxx",
"callBackUrl": "http://www.baidu.com"
}
然后，当第三方支付服务成功后，支付服务会对上面的回调URL发出一次http请求，然后固定请求体带上以下参数：
{
"code": 0,
"充值订单号": "3333333333333333",
"支付订单号": 361504175005106176,
"支付状态": "SUCCESS",
"充值数额": 88.00,
"subject": "游戏",
"gmtCreate": "2019-08-21 10:49:21",
"gmtPayment": "2019-08-21 10:49:21",
}
到这里，我们可以看到
1、回调url是没有加密的，那么如果有黑客拦截到此数据，就可以拿到此url不断地攻击服务器了。
2、回调时的参数是支付服务方固定的，而且没有做到扩展，调用方不能增加自定义参数。
那么比较好的解决方案有什么呢，我们可以参考一下阿里的对象存储OSS是怎么做的。
Callback
用户只需要在发送给 OSS 的请求中携带相应的 Callback 参数，即能实现回调。
Callback包含下面字段(json格式)：
{
"callbackUrl":"121.101.166.30/test.php", // 回调url
"callbackHost":"oss-cn-hangzhou.aliyuncs.com", // 回调host
"callbackBody":"{"mimeType":${mimeType},"size":${size}}", //回调请求体
"callbackBodyType":"application/json" // 回调请求体类型
}
然后将Callback对象转成Json字符串，再进行Base64编码，最后将Base64编码后的字符串作为一个请求参数即可。最后的请求体可能为如下：
{
"xxx": "xxx",
"xxx": "xx",
"xxxxx": "xxxxx",
"callBack": "23jdf7adf8gfasg98g78a9dgda"
}
这样的话，我们可以看到，这就算是被别人拦截了，第一眼看过去肯定是懵逼的。但是呢，只要猜到是base64编码的，反编码后还是可以看到里面的东西。如果对安全性的要求是极致的，大家还可以加上加密算法[可解密]，千万不要加密完不能倒退回来。。。
Sign算法
一般的Sign算法，将请求参数以key1=value2&key2=value2的格式拼接起来，然后再拼接header的参数，最后的格式为：hKey1=hValue2&hKey2=hValue2&data=xxxx，而data的值就是上面请求参数拼接后的字符串，最后进行加密。
我们可以想象，如果客户端的拼接顺序和服务端拼接的顺序不一致，那么最后加密后的字符串肯定是不相等，那么最后必须是服务端返回一句话：签名不合法。
下面，我们看一下一开始SignUtil中对请求参数的拼接函数：
/**
* 将参数进行拼接
* 返回结果为: key1=value1&key2=value2&key3=value3
*
* @param map Map参数
* @return String
*/
public static String mapToString(Map<String, Object> map) {
StringBuffer builder = new StringBuffer();
map.forEach((key, value) -> builder.append(key).append("=").append(value).append("&"));
builder.deleteCharAt(builder.length() - 1);
return builder.toString();
}
我们可以看到，是遍历Map来进行拼接。Map如果以顺序分类，可以分为两大类：一种是有序（例如LinkedHashMap和TreeMap），一种是无序（HashMap）。如果支付服务提供的SignUtil提供的拼接方法如上，那么就是说，我们开发者并不知道支付服务端是传入哪种类型的Map来进行拼接；这时候如果支付服务端使用的是TreeMap，而我们自己在不知道的前提下使用了比较常用的HashMap，那么这时候就出大问题了，签名永远是错误的。
解决方法（支付服务方提供SignUtil）：
1、第三方服务的开发文档必须提醒开发者该传入的Map类型。
拼接方法传入参数还是可以为Map，因为利用了泛型这样比较通用，但是呢文档该注重提醒开发者是传入有序的还是无序的实现类。
2、拼接方法传入参数指定Map类型，甚至具体到实现类。
虽然说这样没有使用到泛型，显得不够通用，可是正因为如此，能强制规定开发者的输入，能避免非常多不必要的坑。
/**
* 将参数进行拼接
* 返回结果为: key1=value1&key2=value2&key3=value3
*
* @param map HashMap参数
* @return String
*/
public static String mapToString(HashMap<String, Object> map) {
StringBuffer builder = new StringBuffer();
map.forEach((key, value) -> builder.append(key).append("=").append(value).append("&"));
builder.deleteCharAt(builder.length() - 1);
return builder.toString();
}
总结
如果是做提供第三方服务的程序猿，我们必须考虑到接口的通用性，还有更重要的是准确性；然后还有就是文档应该简洁而不简单，能让开发者看文档即可一次搞定对接，而不是浪费不必要的时间去尝试，去揣测第三方服务究竟是如何设计的。