目前国内做情趣最好的网站,阜阳交通建设工程质监局网站,丹东seo,用wordpress建站写在前面#xff0c;关于签名的应用场景 除了我们后端经常使用的接口签名来校验数据这些常见的场景#xff0c;对于数据安全性要求比较严格的业务来说#xff0c;大部分落库的核心数据 也都需要签名#xff0c;为啥? 因为怕数据库的数据被篡改数据或者被攻击了#xff0c… 写在前面关于签名的应用场景 除了我们后端经常使用的接口签名来校验数据这些常见的场景对于数据安全性要求比较严格的业务来说大部分落库的核心数据 也都需要签名为啥? 因为怕数据库的数据被篡改数据或者被攻击了通过数据库签名就能保证每一行数据的可靠安全性 1、常见的签名算法
老生常谈我就不一一举例了
MD5AESRSA
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 m0.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)
