求教url访问一次就失效的设计方法

发布于 2022-09-02 15:24:46 字数 471 浏览 20 评论 0

比如说类似下面这种url:

https://foo.com/?timestamp=时间&nonce=随机串&sign=签名

我能想到的方法有以下几种:
1、存数据库:首次访问,把该url存库,第二次访问,查库;
2、存session,先存,后查;
3、存redis、mencache等,先存,后查;
以上几种方法虽然能够达到要求,但是每次都得先存再查,数据量小还好,如果有上千万、上亿条数据呢?也这么查吗?有没有好的解决办法?

我正在考虑能不能根据url的规则设计一个算法来对url进行是否访问过的验证,就算存数据也只存少许数据,而不用存整个url。

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(11

北凤男飞 2022-09-09 15:24:47

你主要不是纠结数据量的问题吗?
那么,为!什!么! 不用COOKIE, 将数据保存在用户本地终端

§普罗旺斯的薰衣草 2022-09-09 15:24:47

通过timestamp来做就好办很多了, 一般timestamp超过一定范围就当做是无效url, 所以nonce入库或者redis, 一段时间后失效就好,因为会先用timestamp判断这个请求是否过期, 再用nonce来判断是否重复请求., timestamp范围30秒左右基本上是够用了的

旧时光的容颜 2022-09-09 15:24:47

我觉得你只要保证每一次访问的 时间戳都必须大于上次访问记录的时间戳就好了。
上次访问的时间戳可以维持在session里

残月升风 2022-09-09 15:24:46

你总是要在后台存储“url是否访问过”这个信息的,这一点跑不了,凭算法手段无法消灭这个问题。

但这个需求的容易之处在于:请求与请求之间是没有联系的,你可以用任意的方法去分表、分库。例如以URL作为分桶依据(注),直接把数据库请求分散到数据库集群中。上千万上亿也是能做到的。

这个需求的真正困难之处在于原子性,即两个请求同时到达服务器时,如何抵抗两个事务同时操作数据库的时间差,造成的数据不一致。

不过这一点的解决也可以靠分表+数据库的锁机制实现。分表分库在这里更是同时承担了(1)分担请求数量压力(2)分担加锁带来的性能压力两个作用。


注1:当然实务上,要先对URL要做一下规范化,避免?v1=1&v2=2?v2=2&v1=1被判定为不同的URL等乌龙情况发生。

注2:实际上根据业务逻辑,用单次有效的索引字符串/token/nonce key(不管叫啥了,随你喜欢)做key才是最好的,省的处理URL的麻烦。

注3:一般而言数据库集群套件,会自动承担平摊分桶的算法,无需手工编写。

心是晴朗的。 2022-09-09 15:24:46

url本身没有变化, 那服务器端总得有什么东西变化
所以若要严格保证1次, 保存这件事感觉是逃不掉的

你现在这个就不用存整个url,存nonce就可以

苍风燃霜 2022-09-09 15:24:46

加临时令牌不行??

面犯桃花 2022-09-09 15:24:46

不需要整个url,其实说穿了就是访问你的网页需要凭密码,而且密码只能用一次。
你自己设想的方法中,session不是全局的,所以用不了,只有数据库或者redis两种选择。

实在是无法理解为什么要让url失效...

攒一口袋星星 2022-09-09 15:24:46

不管用上面方法存储, 服务器不存储怎么可能做的到

涙—继续流 2022-09-09 15:24:46

随机串取长一点儿。URL有有效时间,然后存储那些 URL 有效。可以存储在数据库,定时+访问过后清理数据库。
一般的注册用户邮箱验证/修改密码就是这样的。
从概率上来说,未获得合法 随机数和 sign 的恶意攻击者在有效时间内是遍历不出所有可能的。如果再加一些IP尝试次数限制,这样做就很安全了。

如果你不是要验证,一个URL 可以访问最多一次的话 nonce 设为一个递增的数吧。

傾旎 2022-09-09 15:24:46

访问过之后写个cookie

给妤﹃绝世温柔 2022-09-09 15:24:46

毫秒级时间戳加随机字符串HASH值作为key有效时间缓存任意内容(简单即可如1),先时间戳判断有效时间,再验证该缓存是否存在,这两参数必传

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文