阿里、腾讯云 API 签名设计怎么都这么麻烦，还要转大写排序之类的步奏，为什么不设计成全部参数一起 base64 后签名，传 base64 和签名，一样能防篡改
edis0n0 · 2023-02-04 19:08:52 +08:00 · 2322 次点击这是一个创建于 643 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
Chad0000 2023-02-04 19:18:53 +08:00 via iPhone
我的更简单，整个 Raw Body 直接签名。
前提是 Post 一把梭。 |
 |
2
lhx2008 2023-02-04 19:20:53 +08:00
不排序，同一个请求的签名没有唯一性
|
 |
4
neptuno 2023-02-04 19:27:27 +08:00 via iPhone
防止大家不懂，乱写签名，然后上网提工单询问
|
 |
5
chenqh 2023-02-04 19:29:26 +08:00
java 的 base64 和一般语言的 base64 不一样,好像会加换行
|
 |
6
nightwitch 2023-02-04 19:32:58 +08:00 via Android
不是所有语言都有 base64 编解码的标准库，即使有，实现也会有差别。
|
 |
7
yin1999 2023-02-04 19:35:55 +08:00 via Android
@edis0n0 base64 一下怎么保证唯一，签名算法要做得尽量通用，不论是用 js 、Java 、go 、Python 还是其它语言。不排序如何保证最终要处理的字符串是相同的
|
 |
8
gwy15 2023-02-04 19:38:22 +08:00  1
这跟 base64 有啥关系……
|
 |
9
lovelylain 2023-02-04 19:44:28 +08:00 via Android
整个签名后内容和签名分别放到哪里呢？再嵌套一层放到原内容地方的话，要解析两次参数，不会所有人认为这样更优雅吧。微信支付新的 api 是整个 body 签名，签名放 header 。
|
 |
10
eason1874 2023-02-04 19:59:42 +08:00
楼主的意思是先 base64 再签名，那相当于给字符串签名，没有唯一性问题
但是这样做比排序的计算量大多了，体积也增加三分之一，浪费资源，我也不赞同 |
 |
11
rekulas 2023-02-04 22:57:27 +08:00
base64 后签名自然是不行，不过题主提出的问题确实也存在，现在各大平台签名计算很麻烦，有 sdk 还好，没 sdk 还要自己封装，而且各个平台的签名并不完全统一，有些要求全小写，有些全大写，有些海外平台要求更复杂
其实以前签名很简单，直接提供一个 key ，把 key 传递过去即可，不过可能处于安全、隐私 防重放考虑，逐渐改为签名方式了，但是签名计算着实有点反人类 我有个想法，直接非对称鉴权，平台提供用户私钥自身保存公钥，用户直接使用私钥对请求参数、随机数、时间戳进行加密传递给平台，这样也不需要考虑签名问题了，非对称加密都是全语言统一的，在不担心泄露 key 的情况下完成了鉴权，也杜绝了重放攻击，实现也简单。在对接过的各个平台中似乎也有过类似方式的，但太久远已经忘了是谁了，毕竟不是主流 |
 |
12
vagusss 2023-02-05 00:57:00 +08:00
如果接口用 post ，参数用 json ，直接对整个 json 字符串签名，这时候应该就不用排序了吧。
|
 |
13
yyf1234 2023-02-05 15:19:24 +08:00 via iPhone
“base64 一下就是唯一的”，你能保证每个语言的 json 序列化后顺序一样吗
|
 |
14
leido 2023-02-06 09:54:53 +08:00 via Android
兼容 aws
|
 |
15
unco020511 2023-02-06 11:27:28 +08:00
你不排序咋保证参数列表生成的签名是唯一的,不唯一怎么在服务端校验?http 传递过程可能能确保你的参数顺序不变,但经过类似 retroft/spring 的框架转换之后可就不一定,所以当然需要先排序啊
|
 |
16
baobao1270 2023-02-07 13:00:31 +08:00
Amazon 也是这样设计的啊
猜测一下：可能身份验证在边缘节点处理了，所以要尽可能降低对性能的需求 |
Select Language