写在前面,关于签名的应用场景 除了我们后端经常使用的接口签名来校验数据这些常见的场景,对于数据安全性要求比较严格的业务来说,大部分落库的核心数据 也都需要签名,为啥? 因为怕数据库的数据被篡改数据或者被攻击了,通过数据库签名就能保证每一行数据的可靠安全性
1、常见的签名算法
老生常谈,我就不一一举例了
- MD5
- AES
- RSA
2、步入正题
最近开发的某系统的一个订单的赔付的功能,那么赔付订单的流水表数据就很关键了,必须加签名- -什么?有bug?不存在的!
bug 背景:
签名检验失败:db sign check error old: 39a22a50f78b076497aa703e2677cf0e but new is: 45caf3b7b67508675c87c324c74240f8
不难看出 数据的签名校验失败了 是不是有人动过?(眼睛睁大的像个铜铃):
相信眼尖的盆友立马发现 这个时间为啥不一致啊
生成签名的时候 日志显示秒位是15,怎么到了数据库就变成16了?最后查询记录再校验签名肯定不对啊!
经过测试发现居然会进位:条件if time.millisecond > 500 就会发生进位 比如15.873 最后就变成16了 - -
3、如何规避这个进位问题
func timeTest() {defer EnterExitFunc()()fmt.Println(int(time.Now().Weekday()))now := time.Now()fmt.Printf("now: %v\n", now)dateStr := now.Format("2006-01-02 15:04:05")fmt.Println(dateStr)date, _ := time.ParseInLocation("2006-01-02 15:04:05", dateStr, now.Location())fmt.Printf("after: %v\n", date)fmt.Println(date.Format("2006-01-02 15:04:05"))
}// output打印如下:
now: 2023-08-10 15:11:00.40468 +0800 CST m=+0.000770626
2023-08-10 15:11:00
after: 2023-08-10 15:11:00 +0800 CST
2023-08-10 15:11:00
仔细看发现经常转换之后 时间的微秒位没有了 这样就规避了微秒进位问题
当然还有另外一个办法 从建表语句开始 定义字段的时候使用 datetime(6) 或 timestamp(6)