RESTful 提供 api 接口，但是我很燥的就是进行签名的时候 GET 方式要怎么签？
pizida · 2017-12-12 21:47:30 +08:00 · 9394 次点击这是一个创建于 2571 天前的主题，其中的信息可能已经有所发展或是发生改变。
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