Heim  >  Artikel  >  Backend-Entwicklung  >  求教url访问一次就失效的设计方法

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

WBOY
WBOYOriginal
2016-06-06 20:08:581737Durchsuche

比如说类似下面这种url:

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

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

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

回复内容:

比如说类似下面这种url:

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

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

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

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

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

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

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


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

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

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

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

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

加临时令牌不行??

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

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

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

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

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

访问过之后写个cookie

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

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

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

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn