 |
LinJunzhuV2EX 第 67766 号会员，加入于 2014-07-12 15:41:04 +08:00今日活跃度排名 13583 |
LinJunzhu 最近回复了
2 天前 回复了 LinJunzhu 创建的主题 › 程序员 › API 验证签名时，若 payload 的 json value 为复杂对象时该如何处理？ |
@also24
我自己实现过 HTTP 代理服务，所以对 HTTP 协议自认为还是理解的。
你说的 request body，我完全懂，并没有误会成 object -> request body。
为什么不想直接对 request body 进行签名，是因为部分 Http 库并不支持直接设置 json string 作为 request body，而是通过设置对象，再由 Http 库自己转为 json string -> request body。
因为想要一个约定俗成的方案，所以想看看大家的做法，现在我知道了哈哈
非常感谢你的答复 ：）
我自己实现过 HTTP 代理服务，所以对 HTTP 协议自认为还是理解的。
你说的 request body，我完全懂，并没有误会成 object -> request body。
为什么不想直接对 request body 进行签名，是因为部分 Http 库并不支持直接设置 json string 作为 request body，而是通过设置对象，再由 Http 库自己转为 json string -> request body。
因为想要一个约定俗成的方案，所以想看看大家的做法，现在我知道了哈哈
非常感谢你的答复 ：）
2 天前 回复了 LinJunzhu 创建的主题 › 程序员 › API 验证签名时，若 payload 的 json value 为复杂对象时该如何处理？ |
@index90
我自己实现过 HTTP 代理服务，所以对 HTTP 协议自认为还是理解的。
你说的 request body，我完全懂，并没有误会成 object -> request body。
为什么不想直接对 request body 进行签名，是因为部分 Http 库并不支持直接设置 json string 作为 request body，而是通过设置对象，再由 Http 库自己转为 json string -> request body。
因为想要一个约定俗成的方案，所以想看看大家的做法，现在我知道了哈哈
非常感谢你的答复 ：）
我自己实现过 HTTP 代理服务，所以对 HTTP 协议自认为还是理解的。
你说的 request body，我完全懂，并没有误会成 object -> request body。
为什么不想直接对 request body 进行签名，是因为部分 Http 库并不支持直接设置 json string 作为 request body，而是通过设置对象，再由 Http 库自己转为 json string -> request body。
因为想要一个约定俗成的方案，所以想看看大家的做法，现在我知道了哈哈
非常感谢你的答复 ：）
2 天前 回复了 LinJunzhu 创建的主题 › 程序员 › API 验证签名时，若 payload 的 json value 为复杂对象时该如何处理？ |
@fkdog 搜索了下，so 确实可以反编译， 但这不是 API 不加任何防护的理由：）
2 天前 回复了 LinJunzhu 创建的主题 › 程序员 › API 验证签名时，若 payload 的 json value 为复杂对象时该如何处理？ |
@also24 只能说你考虑不周到...
2 天前 回复了 LinJunzhu 创建的主题 › 程序员 › API 验证签名时，若 payload 的 json value 为复杂对象时该如何处理？ |
@index90 更正： payload 为 request body
2 天前 回复了 LinJunzhu 创建的主题 › 程序员 › API 验证签名时，若 payload 的 json value 为复杂对象时该如何处理？ |
@index90 你这个方案没有把 payload 放进去生成 Signature 的逻辑是吧？
其实我纠结的点在于：
若是在 application/json 的基础上进行交互
1、若 payload 内的 value 为数组、json 对象 时，那么就递归遍历排序， 这就满足需求了，但是在网上也没看到这样的实现方案，大家的 value 都是简单类型，所以不确定这样的实现是否合理
2、忽略 value 为数组、json 对象的逻辑计算，这就跟你的方案差不多。
所以才发了贴，问下大家的做法 ：）
其实我纠结的点在于：
若是在 application/json 的基础上进行交互
1、若 payload 内的 value 为数组、json 对象 时，那么就递归遍历排序， 这就满足需求了，但是在网上也没看到这样的实现方案，大家的 value 都是简单类型，所以不确定这样的实现是否合理
2、忽略 value 为数组、json 对象的逻辑计算，这就跟你的方案差不多。
所以才发了贴，问下大家的做法 ：）
2 天前 回复了 LinJunzhu 创建的主题 › 程序员 › API 验证签名时，若 payload 的 json value 为复杂对象时该如何处理？ |
2 天前 回复了 LinJunzhu 创建的主题 › 程序员 › API 验证签名时，若 payload 的 json value 为复杂对象时该如何处理？ |
@geelaw
>这两个和你说的场景不同，考虑 A 公司向 B 用户通过支付宝收款，则收款请求是 A 的服务器发出的而不是 B 的设备发出的。要求 A 进行消息认证的目的是为了确保收款请求确实是 A 的意思而不是别人栽赃。
那我们回到这个场景，微信支付商户文档也是对参数进行了键值对的排序组合。
若 参数值为 一个 json 对象，而非基本类型(String, int)，该如何做解析？
>这两个和你说的场景不同，考虑 A 公司向 B 用户通过支付宝收款，则收款请求是 A 的服务器发出的而不是 B 的设备发出的。要求 A 进行消息认证的目的是为了确保收款请求确实是 A 的意思而不是别人栽赃。
那我们回到这个场景，微信支付商户文档也是对参数进行了键值对的排序组合。
若 参数值为 一个 json 对象，而非基本类型(String, int)，该如何做解析？
2 天前 回复了 LinJunzhu 创建的主题 › 程序员 › API 验证签名时，若 payload 的 json value 为复杂对象时该如何处理？ |
@index90
你看我上面的回复，就能看到，我指出了 JSON 文本，和 JSON 对象（各个语言有各自的类型），我对 http 的协议还是蛮熟悉的 :)
至于为什么我一直在说 json， 是因为现在 API 交互中， 双方基本约定成俗为 content_type: application/json
直接对 request body 进行验签不可取，还是那句话，hash key 是无序的，不同语言、不同库 解析和反解析，顺序不一定一致。
你可以看下微信支付商户的 API 文档： [https://pay.weixin.qq.com/wiki/doc/api/micropay.php?chapter=4_3] 也是进行 键值对的 排序组合， 只不过微信支付的 API 参数 value，都是基本类型
你看我上面的回复，就能看到，我指出了 JSON 文本，和 JSON 对象（各个语言有各自的类型），我对 http 的协议还是蛮熟悉的 :)
至于为什么我一直在说 json， 是因为现在 API 交互中， 双方基本约定成俗为 content_type: application/json
直接对 request body 进行验签不可取，还是那句话，hash key 是无序的，不同语言、不同库 解析和反解析，顺序不一定一致。
你可以看下微信支付商户的 API 文档： [https://pay.weixin.qq.com/wiki/doc/api/micropay.php?chapter=4_3] 也是进行 键值对的 排序组合， 只不过微信支付的 API 参数 value，都是基本类型
3 天前 回复了 LinJunzhu 创建的主题 › 程序员 › API 验证签名时，若 payload 的 json value 为复杂对象时该如何处理？ |
@also24 数组的有序性我倒是不担心， 唯一疑惑的点就在于 value 为对象时，该如何确保 客户端和服务端生成 sign 的逻辑是一致的。
因为哈希对象的 key 是无顺序的，同一段 json 文本，在最终解析出来的顺序是可能不一致的；
若 value 为对象，那么客户端在生成 token 时，该 value 转换为 json 文本是：
"{\"a\":\"a\",\"b\":\"b\"}"
服务端在生成 token 时，该 value 转换为 json 文本可能是：
"{\"b\":\"b\",\"a\":\"a\"}"
所以最终会导致验签失败。
我能想到的就是对 value 为复杂对象时，也进行 key=value 的形式排序，如此递归下去
因为哈希对象的 key 是无顺序的，同一段 json 文本，在最终解析出来的顺序是可能不一致的；
若 value 为对象，那么客户端在生成 token 时，该 value 转换为 json 文本是：
"{\"a\":\"a\",\"b\":\"b\"}"
服务端在生成 token 时，该 value 转换为 json 文本可能是：
"{\"b\":\"b\",\"a\":\"a\"}"
所以最终会导致验签失败。
我能想到的就是对 value 为复杂对象时，也进行 key=value 的形式排序，如此递归下去
Select Language