这是一个创建于 2861 天前的主题，其中的信息可能已经有所发展或是发生改变。
RT. 如果是 POST 请求，那么很简单，所有参数我一股脑儿的进行哈希加密生成签名。 但是如果遇到 GET 请求，按照 restful 的用法，比如 api.test.com/users/1?type=2，这个 type 获取来签名很正常，但是这个 users/1 她实际上也是在 GET 参数里面的，我也可以 parse 后一起加密，但是这样子对调用方就很麻烦啊，他可能很困惑，我传递的参数是 type，为什么要把 users/1 也进行加密，这个 users/1 对于调用放来说是请求路径，并不是 GET 参数，但实际上对服务方这个也是 GET 参数，那么问题来了，这个 users/1 到底要不要参与签名，如果参与，这样子很容易有坑，调用方认为这不是 GET 参数，如果不参与，这签名也就没意义了，任意改变 user/id 里面的 id，这样子签名都能通过。
各位大神都是怎么处理在使用 restful 前提下，这个签名问题的！！求教！！
 | 1 chinvo 2017-12-12 21:51:25 +08:00 get 就不签名了，用 header 传个 apikey 或者 basic authentication 呗 |
 | 2 BOYPT 2017-12-12 21:53:00 +08:00 整个请求 URI 签名，写在 Header |
 | 3 lifeintools 2017-12-12 21:53:05 +08:00 via iPhone 。。楼上说的对。。加头部 |
 | 4 StevenTong 2017-12-12 21:56:57 +08:00 我们用 jwt token 请求不加密。 |
 | 5 kosilence 2017-12-12 22:26:20 +08:00 via iPhone 楼上说的对，头部 |
 | 6 voocel 2017-12-12 22:33:51 +08:00 via Android 楼上都说的对 |
 | 7 hcymk2 2017-12-12 23:29:07 +08:00 签名目的是什么？ 如果是防篡改的话，为啥不直接用 https |
 | 8 sunjourney 2017-12-12 23:45:04 +08:00 加密解密如果都是在前端，你搞这套有什么用？不如上 https |
 | 9 jameslan 2017-12-13 03:56:41 +08:00 via Android 签名？你 private key 放在前端？ |
 | 10 pizida OP @chinvo 嗯我也想过 get 不进行签名，其实服务也是在内网，理论上比较安全。因为主要是一些服务接口，没有登录体系，给后台调用的。basic authentication 就觉得没必要了。 |
| 12 pizida OP @hcymk2 是的，主要防篡改，因为业务原因是直接通过 IP 请求，就没上 HTTPS。而且也不需要用户认证逻辑，想着直接走 HTTP 方便点 |
| 13 pizida OP @sunjourney 不是前端，给后台调用的，所以安全设计考虑好是有必要的，主要防止篡改和重放攻击 |
| 14 pizida OP @jameslan 不是放前端，后端发请求，private 参与哈希，将 sign 传过来。我纠结的是 restful 后到底哪些参数要进行签名 |
 | 15 lightening 2017-12-13 08:26:28 +08:00 via iPhone 你签名是想防谁做什么？ |
 | 16 xrlin 2017-12-13 08:37:32 +08:00 via Android  1 用 jwt，签名时加上客户端信息、特殊标志避免被截获利用，但为何不用 https 呢?加个 https 不必你这自己签名方便? 直接用 ip 访问不方便以后迁移。 |
 | 17 timothyqiu 2017-12-13 09:10:41 +08:00 1 感觉你这个需求可以参考七牛的管理凭证签名： https://developer.qiniu.com/kodo/manual/1201/access-token 给 `<path>?<query>\n<body>` 签名。 |
| 18 pizida OP @lightening 其实是内网服务，公司内部调用，不做签名问题也不大。主要防篡改和重放攻击 |
| 19 pizida OP @xrlin jwt 是啥，我研究下。感谢，另外 HTTPS 这个感觉这里没必要，提供的接口没有太多敏感逻辑，只要是一些公共的 curd |
| 20 pizida OP @timothyqiu 感谢，我研究下。 |
 | 21 LeeSeoung 2017-12-13 11:19:48 +08:00 api + 参数一起签名 |
 | 22 codeyung 2017-12-13 11:27:07 +08:00 header 或者 JWTJsonwebtoken https 一套就行 |
 | 23 njwangchuan 2017-12-13 14:00:34 +08:00 https + Basic Auth，足以搞定。 对于 Post 请求重复提交问题，每个请求里面客户端自己生成一个 uniqueRequestId （ UUID ）参数，用于判断重复提交问题。 一些大型交易网站的 API 接口都能这么干，没必要搞那么复杂。 |
 | 24 flyingghost 2017-12-13 16:26:47 +08:00 你的需求里既然有防篡改，那其实就是 https 解决的问题。和内不内网毫无关系啊。 而且上个 https 又不复杂。 |
 | 25 ipwx 2017-12-13 16:32:02 +08:00 安全领域，最忌讳自己造轮子。你如果要防止重放，用 requestId 就可以了。要是为了防篡改 /防窃听，就这种初级校验方式，真的有用吗？ |
| 27 pizida OP @flyingghost 好的，感谢回答，会考虑用 HTTPS |
| 29 pizida OP @njwangchuan 我这个主要不是给客服端请求，是给其他机器提供的后台服务 |
 | 30 8355 2017-12-13 17:55:28 +08:00 按照你的需求 /users/1 部分不需要加入签名 只要给 type=2 签名就可以了. 具体原因看 RESTful API 设计指南 |
| 31 codeyung 2017-12-13 18:40:49 +08:00 @pizida 像我做 open API 给其它用户用 都是首先作一个 oauth2 那个 token 在验证 url 的访问权限 如果安全再返回数据 |
 | 32 TIGERB 2017-12-13 18:52:46 +08:00 get 不用签了吧，必要的验证下登录状态不就行了么 |
 | 34 odirus 2017-12-13 19:20:52 +08:00 参数签名，我使用得比较多的场景是服务与服务之间的认证。 例如自己系统的服务端调用别人的支付系统，主要方便对调用方的鉴权，防止其他人恶意调用接口（前提是颁发的密钥别被第三方窃取了） |
 | 35 liukefeng2008 2017-12-13 19:30:52 +08:00 |
 | 36 solee 2017-12-13 21:54:04 +08:00 jwt token 放 Header |
Select Language