时间：2021-07-01 10:21:17 帮助过：20人阅读
对于 api_token 的校验，其安全性还可再增强：
增强地方一：
再增加2张表，一个接口表，一个授权表，设计参考如下：
接口表
| 字段名 | 字段类型 | 注释 |
| api_id | int | 接口ID |
| api_name | varchar（120） | 接口名，以"/"作为分割线，如 blog/Index/addBlog |
| api_domain | varchar（255） | 所属领域 |
| is_enable | tinyiny(1) | 1可用，0不可用 |
| add_time | int | 添加时间 |
（注：只列出了核心字段，其它的再扩展吧！！！）
授权表
| 字段名 | 字段类型 | 注释 |
| client_id | int | 客户端ID |
| api_id | int | api编号 |
| api_name | varchar(120) | |
| is_enabled | tinyint(1) | 是否可用 1:可用 0:不可用 |
| add_time | int | 添加时间（戳） |
| expire_time | int | 过期时间（戳） |
（注：只列出了核心字段，其它的再扩展吧！！！）
执行过程如下：
1、移动端与服务端生成的 api_token 进行对比，如果不相等，则直接返回错误，否则，进入下一步；
2、根据接口URL，组装 api_name，再加上客户端传回的 client_id 为参数，查找 “授权表”记录，如果记录存在，且有效（是否可用，是否过期），则表示权限验证通过，返回接口数据，否则返回错误信息；
增强地方二：
对于一些很特殊的接口，怎么特殊，哪些算特殊，我也不知道，总而言之，就是感觉http请求有可能被劫取，传递参数有可能被窜改等情况，还是举个例子来说吧：
有个直接转账接口，页面上 我输入的是5元，表示我要给对方某某转账5元，结果在http传递过程中，被人劫取并窜改成了 10000元，而且入账对象改成了“黑客”的账号，那不是亏大发了，思考了一下，应该有2种方案解决这个问题，
方案一：走https，这个就不多说，比较公认的安全机制；
方案二：走数字签名，实现原理如下：
一个http请求，假如需要传递如下3个参数
参数名1=参数值1
参数名2=参数值2
参数名3=参数值3
我们可以再追加一个参数，该参数的名为 identity_key （名字是什么不重要），该参数的值为 前几个参数值按顺序相加，再加密后的结果。
即：
identity_key = md5('参数值1' + '参数值2' + '参数值3' + '加密密钥');
于是，最终传递的参数有：
参数名1=参数值1
参数名2=参数值2
参数名3=参数值3
client_id=client_id值
identity_key=md5('参数值1' + '参数值2' + '参数值3'+ 'client_id值' + '加密密钥')
服务端接到参数后，再按相同的加密规则重新生成一份 identity_key，服务端的identity_key和客户端的identity_key 进行校对，如果不相等，表示被窜改过，接下来怎么操作，自己看着办吧！