头图

花式调接口: hex vs base64

Denzel
English

背景

作为你一个前端,可能你常常自诩,你是一个无情的API调用机器,调框架API,调服务端API;但下文可能会震惊到你,至少已经让我崩溃了好几天。

从10月就接到一项需求,需要将我们平台的数据同步到集团另一个平台,how? 通过开放API!!!

这个开放API 有多难调,我大概描述一下

  • 对称加密,对方平台将给我发放一对秘钥;这似乎所有API都会这样做,毕竟安全第一!!!
  • MD5计算, 哦不,是MD5计算后转base64;这个其实也正常,为了数据传输防篡改,请求bodymd5加密也很常见;
  • 请求头摘要加签,加签是什么鬼?摘要是什么鬼?没错,还是为了安全,而且这个玩法很复杂,是我以前没见过的;
  • 只有线上环境可调,线下不可调,what??;但最难的是,环境隔离,就是不能跨机房调用,大白话就是线下机房不能调线上机房(玩法类似于我高中时的小灵通,就是只能拨本市的号码,异地恋是不可能的),这预示着什么?

预示着热更新不可用,本地调不可行?改一行代码,就需要去预发环境(预发环境属于线上机房)部署一次(> 5min), 然后调一下刚刚部署的接口,发现不对,然后又改一行代码,又部署,又调,不断重复!!!Seriously???
image.png
可能你现在想知道,是哪个平台商提供了这个API, 悄悄告诉你, 算了,你还是自己看吧:https://help.aliyun.com/docum...

花式调接口

postman 是一个好工具,但有时postman也可能力不从心(postwoman也一样),比如今天要讲的机房内调用。
所以,下面讲到的招式,可能常规前端开发不一定遇得到,也不一定用得上,但看一看又不要钱,万一赚了喃。

招式1:动态传参

通常我们调服务端API接口不通,通常只有两种情况:

  • 服务端傻逼,写了一个根本调不通的接口(我这里不存在,因为传说是通的,至少他向我证明了网关是通的);
    image.png
  • 前端傻逼,参数没按照指示来

所以,我默认按我是傻逼的方案来做,就是服务端的入参,我都通过我的接口动态传上去,哪不对我就改哪里,听起来可能有点懵逼,我画个图:有点草率。
image.png
但事情,原没有我想的那么简单,我确实懵逼了,因为这个接口,远不是入参正确就能调通那么简单。
因为我还得md5计算正确、请求头设置正确、签名正确;

而这些请求头也需要动态改变,不过这时我灵光乍现:上面这个防止自己傻逼方案, 和接口代理有什么区别, 所以我顿时有了方案2:接口代理

方案2:接口代理

proxy, 前端可能都不陌生,webpack-dev-server 就有这个功能,多是用来解决接口跨域。所以,我何必要什么动态传参,我直接加个代理不更简单,所以方案是这样的:
image.png
两行代码搞定:

// plugin.js加入插件
export const httpProxy = {
  enable: true,
  package: 'egg-http-proxy',
};

// config.js 加入配置
  config.httpProxy = {
    '/aapi': {
      target: 'http://api-gateway.test.com',
      pathRewrite: {'^/aoneapi' : ''}
    }
  };

这个方案,听起来很美好,热更新有了,线下调试有了;但由于我们平台底层有一些中间件,所以当目标平台响应了400 或 401,我们平台(node-server) 就会拦截,返回一个302重定向, 这就会导致我看不到目标平台真实的错误响应,但改底层拦截改动很大,也会影响到其他同事的开发。

方案3: 远程server直接调

鉴于前面的curl尝试, 证明最直接的接口调用,最短的链路,可以避免最少的错误

curl -v -X GET http://test.goaway.com/checkpreload -H 'Authorization: APPCODE f7f526fd3adf2f38d46'

因为NodeJs 是脚本语言,区别于Java这种编译型语言。这时候好处就体现了,考虑到服务器上有源代码,那就可以直接通过 node 命令去唤起接口调用, 所以现在链路变成了这样:
image.png
我在我的仓库中加入了一个文件(test.js),伪代码:

const rp = require('request-promise');
const { createHash, createHmac } = require('crypto');

async function handle(str = []) {
  // 省去具体实现
}

// 获取请求相关数据
const arg = process.argv.slice(ArgStart);
handle(arg);

所以当我把代码部署上去时,我就可以运行node test.js ..., like:
image.png
这样执行一下,我能自定义响应体,可以看到请求头是否符合规范,错误发生时可以清楚看到错误响应;最重要的,当我知道错误时,我可以直接在服务器上编辑代码,然后再接着运行命令测试,这样时间就大大节省了。这一切的实现,都归功于NodeJs一门脚本语言!!!
image.png

分享个知识: md5

这一次调试,我的卡点可以大概纠结于四个阶段:

  • 机房隔离,网络不通
  • Invalid md5
  • Invalid signalture
  • Authentication error since of operator not configured according to ak

卡的时间最久的,就是Invalid md5;由于最开始官方了提供了SDK,里面提供了md5计算方法:

static getContentMD5(body) {
  const hash = crypto_1.createHash('md5');
  hash.update(body);
  return hash.digest('hex');
}

但问题,就出在这,这个MD5计算和官方文档提到的不一致:
image.png
可以看出,在经过md5计算后,又用base64的方式进行了编码。
而官方SDK提供的只需要如下修改一下,就可以获得一致的结果:

static getContentMD5(body) {
  const hash = crypto_1.createHash('md5');
  hash.update(body);
  return hash.digest('base64');
}

那digest方法这个入参到底有什么机密?

细品digest入参

NodeJs官方文档

在crypto:0.1.92版本,入参的typescript是这样定义的;

type BinaryToTextEncoding = "base64" | "base64url" | "hex"

除了上面这三个参数(在0.1.94版本,已经没有base64url选项),其实这个入参还能为空, 为空时返回Buffer, 否则返回string, 所有在日常场景入参都是存在的,因为我们拿着一个Buffer 意义不大,当对hello world做md5计算时,得到的buffer是: <Buffer fc 3f f9 8e 8c 6a 0d 30 87 d5 15 c0 47 3f 86 77>
那为什么不直接用Buffer,因为对象不利于传输!!!

base64 vs hex

又可以理解为base64 vs base16;
所以当我们传入hex时,达到的结果是:fc3ff98e8c6a0d3087d515c0473f8677,这个结果正好就是上面的buffer字符串化。

而传入base64, 得到的结果是:/D/5joxqDTCH1RXARz+Gdw==
因为Buffer 本身是由一串串16进制数组成的,所以转为hex,就会很容易,而转成base64,就需要再编码

关于base64编码:网络上传输的字符并不全是可打印的字符,比如二进制文件、图片等。Base64的出现就是为了解决此问题,它是基于64个可打印的字符(A-Z、a-z、0-9、+、/)来表示二进制的数据的一种方法;转码过程:首先将待转换的字符每三个字节分为一组,每个字节占8bit,那么共有24个二进制位,然后将二进制位每6个一组分为4组。在每组前面添加两个0,每组由6个变为8个二进制位,总共32个二进制位,即四个字节。最后根据Base64编码对照表获得对应的值(位数不足情况:当位数从8bit转化6bit时,不完整的6bit中用0填充,无对应6bit的8bit向后直接用=填充
这里粗略做个变换,hex结果是32个字符,每个字符为4个二进制数
第一步: 转化为二进制数:1111-1010-0011.....-0111-0111(32 * 4 = 128)

第二步:转化为6个bit为一小组,然后三个一大组: 111110-100011-.....-011101-11(7 * 3 * 6 + 2)

第三步:补0,补=:00111110-00100011-....-00011101-00110000-=-=
 
第四步:对照表转字符:/-D-....-d-w-=-=

至少头尾是一致的,套路应该没啥问题。
至于何时用base64, 何时用base16; 对于md5计算,这个主要看服务端心情!但对于大字节流,比如文件,图片的传输,都会选用base64, 因为这可以节省流量,提高传输效率。

那base64Url 又是什么? base64Url 又称为安全的Base64,和 base64的区别仅仅在于63号和64号字符的转换上;
image.png
由于"/","="等是URL中的保留字符或不安全字符,因此如果直接在URL中传输Base64编码,保留字符和不安全字符会被替换为%XX的形式,对后端来说解码不方便。如果不替换,就会造成URL注入漏洞。所以 base64Url 其目的在于解决+、\、=在url的传输问题。

结尾

写个文章也要有个仪式感,不能虎头蛇尾,这里就结尾感叹一声吧:做个前端好难!!!

image.png

欢迎关注我的前端公众号:前端黑洞

阅读 1.9k

前端黑洞
生命不息,奋斗不止

不要假装很努力,因为结果不会陪你演戏

3.3k 声望
4.5k 粉丝
0 条评论

不要假装很努力,因为结果不会陪你演戏

3.3k 声望
4.5k 粉丝
文章目录
宣传栏