RESTful 提供 api 接口，但是我很燥的就是进行签名的时候 GET 方式要怎么签？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 2563 天前的主题，其中的信息可能已经有所发展或是发生改变。

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 前提下，这个签名问题的！！求教！！

get

签名

users

参数

36 条回复 • 2017-12-13 21:54:04 +08:00

chinvo

2017-12-12 21:51:25 +08:00

get 就不签名了，用 header 传个 apikey 或者 basic authentication 呗

BOYPT

2017-12-12 21:53:00 +08:00

整个请求 URI 签名，写在 Header

lifeintools

2017-12-12 21:53:05 +08:00 via iPhone

。。楼上说的对。。加头部

StevenTong

2017-12-12 21:56:57 +08:00

我们用 jwt token 请求不加密。

kosilence

2017-12-12 22:26:20 +08:00 via iPhone

楼上说的对，头部

voocel

2017-12-12 22:33:51 +08:00 via Android

楼上都说的对

hcymk2

2017-12-12 23:29:07 +08:00

签名目的是什么？如果是防篡改的话，为啥不直接用 https

sunjourney

2017-12-12 23:45:04 +08:00

加密解密如果都是在前端，你搞这套有什么用？不如上 https

jameslan

2017-12-13 03:56:41 +08:00 via Android

签名？你 private key 放在前端？

pizida

2017-12-13 07:19:04 +08:00 via iPhone

@chinvo 嗯我也想过 get 不进行签名，其实服务也是在内网，理论上比较安全。因为主要是一些服务接口，没有登录体系，给后台调用的。basic authentication 就觉得没必要了。

pizida

2017-12-13 07:20:09 +08:00 via iPhone

@BOYPT 那 POST 的时候也是整个 URL+POST 参数一起签名？

pizida

2017-12-13 07:22:03 +08:00 via iPhone

@hcymk2 是的，主要防篡改，因为业务原因是直接通过 IP 请求，就没上 HTTPS。而且也不需要用户认证逻辑，想着直接走 HTTP 方便点

pizida

2017-12-13 07:23:05 +08:00 via iPhone

@sunjourney 不是前端，给后台调用的，所以安全设计考虑好是有必要的，主要防止篡改和重放攻击

pizida

2017-12-13 07:24:22 +08:00 via iPhone

@jameslan 不是放前端，后端发请求，private 参与哈希，将 sign 传过来。我纠结的是 restful 后到底哪些参数要进行签名

lightening

2017-12-13 08:26:28 +08:00 via iPhone

你签名是想防谁做什么？

xrlin

2017-12-13 08:37:32 +08:00 via Android

用 jwt，签名时加上客户端信息、特殊标志避免被截获利用，但为何不用 https 呢?加个 https 不必你这自己签名方便? 直接用 ip 访问不方便以后迁移。

timothyqiu

2017-12-13 09:10:41 +08:00

感觉你这个需求可以参考七牛的管理凭证签名： https://developer.qiniu.com/kodo/manual/1201/access-token

给 `<path>?<query>\n<body>` 签名。

pizida

2017-12-13 09:18:32 +08:00

@lightening 其实是内网服务，公司内部调用，不做签名问题也不大。主要防篡改和重放攻击

pizida

2017-12-13 09:20:15 +08:00

@xrlin jwt 是啥，我研究下。感谢，另外 HTTPS 这个感觉这里没必要，提供的接口没有太多敏感逻辑，只要是一些公共的 curd

pizida

2017-12-13 09:20:41 +08:00

@timothyqiu 感谢，我研究下。

LeeSeoung

2017-12-13 11:19:48 +08:00

api + 参数一起签名

codeyung

2017-12-13 11:27:07 +08:00

header 或者 JWTJsonwebtoken https 一套就行

njwangchuan

2017-12-13 14:00:34 +08:00

https + Basic Auth，足以搞定。
对于 Post 请求重复提交问题，每个请求里面客户端自己生成一个 uniqueRequestId （ UUID ）参数，用于判断重复提交问题。
一些大型交易网站的 API 接口都能这么干，没必要搞那么复杂。

flyingghost

2017-12-13 16:26:47 +08:00

你的需求里既然有防篡改，那其实就是 https 解决的问题。和内不内网毫无关系啊。
而且上个 https 又不复杂。

ipwx

2017-12-13 16:32:02 +08:00

安全领域，最忌讳自己造轮子。你如果要防止重放，用 requestId 就可以了。要是为了防篡改 /防窃听，就这种初级校验方式，真的有用吗？

pizida

2017-12-13 16:40:56 +08:00

@ipwx 有什么好轮子推荐吗？

pizida

2017-12-13 16:41:25 +08:00

@flyingghost 好的，感谢回答，会考虑用 HTTPS

pizida

2017-12-13 16:42:07 +08:00

@codeyung JWTJsonwebtoken 看起来不错，研究下

pizida

2017-12-13 16:42:55 +08:00

@njwangchuan 我这个主要不是给客服端请求，是给其他机器提供的后台服务

8355

2017-12-13 17:55:28 +08:00

按照你的需求 /users/1 部分不需要加入签名只要给 type=2 签名就可以了.
具体原因看 RESTful API 设计指南

codeyung

2017-12-13 18:40:49 +08:00

@pizida 像我做 open API 给其它用户用都是首先作一个 oauth2 那个 token 在验证 url 的访问权限如果安全再返回数据

TIGERB

2017-12-13 18:52:46 +08:00

get 不用签了吧，必要的验证下登录状态不就行了么

ipwx

2017-12-13 19:01:21 +08:00

@pizida https 呗。

odirus

2017-12-13 19:20:52 +08:00

参数签名，我使用得比较多的场景是服务与服务之间的认证。

例如自己系统的服务端调用别人的支付系统，主要方便对调用方的鉴权，防止其他人恶意调用接口（前提是颁发的密钥别被第三方窃取了）

liukefeng2008

2017-12-13 19:30:52 +08:00

是时候拯救 LZ 一波了，参考 http://docs.aws.amazon.com/zh_cn/general/latest/gr/signature-version-2.html

solee

2017-12-13 21:54:04 +08:00

jwt token 放 Header