公司出于安全考虑,要对新接口进行加密,并要求测试性能,于是我就揽下这个任务。
从开发那里得知接口的加密方式是对参数进行 AES 加密,我打开 pycharm 轻轻松松写了一个 AES 加密方法,就等着提测了。
提测后用这个方法加密完参数一提交,接口频频提示参数错误。
我???
我去找开发,开发说你的参数里缺少 “签名”,我们的参数体中增加了一个签名,这个签名是通过部分参数的组分计算得出。
我觉得有点复杂,直接把开发的 java 代码要过来,然后对着 java 代码一步一步在 python 里实现。
我已经完全把逻辑复制过来了,可一提交仍然报错,再一看还是签名错误,我不解,拉开发一块 review 我的代码。
开发虽然不了解 python 但是逻辑大概能看明白,开发也认为我的实现挺完整了,就是不明白问题出在哪。
机智如我想到,反解一下不就行了!
反解开发和我的签名对比下原始参数,实现一样,那可能问题出在参数有差异上。
结果呢,因为签名使用的是哈希函数,无法反解,我的好主意就此作罢。
下午我的领导问我进度,我这还一筹莫展呢,领导没说话就走了。
我这一下压力就来了,搞个压测,一天了,连接口都没跑通呢,你这是在干啥?
心里一急,一下想到,我要不直接用开发的代码加密?
一想可以试试,打开 IDEA,就把开发的代码放进去,一运行,还真可以生成签名,只不过签名还是不对。
这下基本可以确定了,一定是参数不一致。
于是我对比了开发的传参和我的传参,发现我传参的字段顺序与开发的不一致,而哈希函数需要的参数是一个字符串,也就是说字段顺序不一致会有影响。
我固定的 json 里面的字段顺序。
再一跟开发的签名,果然一致了!
之后从网上 copy 了 AES 加密的 JAVA 工具类,对参数进行加密,一请求接口,成功!
写的文字量还成,实际上这两天心情真是……我一度觉得自己可能搞不定这项任务了,
一点一点摸索,最终完成脚本,还是比较有成就感的。
今年上半年突破了这一个挑战,算是有些收获。