作用

防止有人不停的刷接口，对接口作限制

比如说，登录接口，按道理说，应该只有app会请求这个接口

但是，如果有人抓取app的请求，就会得到登录接口的地址和请求参数

如果他写了个脚本，不断的访问登录接口，去测登录名密码，那么有些有些用户的密码策略过于简单，是很容易被试出来的

所以，接口签名就是专门用来限制这个的，只有app(自己人)才能通过校验

原理

1.服务器和app，各自存储一个相同的秘钥

2.app请求时，把传的参数用秘钥进行加密，生成一个sign签名，一同传递过去

3.服务器接到请求后，也会对传递的参数进行加密，也生成一个sign签名，拿服务器生成的sign和接口请求的sing比对一下，如果相同，那么就可以证明，是自己人请求的，就予以放行

因为这个秘钥，只有自己人才会有，同样的秘钥生成的sign签名，肯定是一模一样的

这个秘钥，一般是开发的时候，线下给到app开发，集成编译到app里面的

问题

举例，app和服务器，各自保存了一个秘钥，进行签名验证

1.app请求登录接口，账号名为abcd，密码为123456，

2.app对账户名和密码用秘钥加密生成签名，去请求登录接口

3.服务器收到请求，对账号名和密码也用秘钥加密生成签名，对比发现签名一致，然后予以通过

4.请求成功

问题1

但是，如果下次app还去请求登录的时候，生成的签名，是不是还是一模一样？

因为都是对账号和密码加密生成签名，那么只要账号和密码不变，那么生成的签名肯定是一模一样的

那如果坏人直接抓包拿到签名、账号和密码，是不是他也可以仿造登录请求，要知道，服务器只接受请求，他是分辨不出来的

所以，即使是相同的账号和密码，也要保证，每次的签名都不一致

解决办法

在对账号和密码进行加密的时候，生成当前时间的时间戳，一起加密，这样就保证了每次生成的签名都一样了

传递参数的时候，也需要把加密用的时间戳一同传递过去，因为请求时候延迟的，服务器并不知道你是哪个时间进行加密的

那么现在生成签名和请求的步骤就是：

1.app先对账号、密码、时间戳，用秘钥进行加密得到签名

2.app请求登录接口，传参：账号、密码、时间戳、签名

问题2

那么问题又来了，跟刚才的问题一样，如果有人抓包，得到账号、密码、时间戳、签名，然后去伪造请求，是不是服务器还会通过？

只要账号、密码、时间戳不变化，那么生成的签名，还是一模一样的。

解决办法

服务器对时间戳进行校验，与当前时间不能相差10秒

这样就保证了，这个签名的有效期只有10秒，过了10秒后，就失效了

如果想要新的签名，那么就需要用新的时间戳了

代码

如果需要传递很多参数的时候，还需要对参数进行排序后再加密，要不然app和服务器用了不一样的字符串加密，校验还是会失败的