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

写的文字量还成,实际上这两天心情真是……我一度觉得自己可能搞不定这项任务了,
一点一点摸索,最终完成脚本,还是比较有成就感的。
今年上半年突破了这一个挑战,算是有些收获。


↙↙↙阅读原文可查看相关链接,并与作者交流