11

假设有这么个场景

某天,你接到一个任务,需要开发一个作品投票的网站,可以让别人访问链接进入活动页面,每天给心仪的作品投几票

这看起来好像很简单,但是有个问题,整个流程里没有登录系统,也就是说没法区分用户。

那还怎么存储用户数据?


localStorage 嗯哼,这好像只能这样了吧。可这安全性也太差了,分分钟被人刷票。

那就来点复杂的 —— 心理战术

没有登录系统,稍懂点前端的就会猜出用户数据存在本地上,因为前端有权限问题,无法获取到IP或者MAC地址之类的唯一标识,那只能存浏览器本地。

所以我们需要在localStorage存储数据,只写不读,这是一个烟雾弹,用来迷惑别人

当然,这还不够,太直白了,需要加密处理。

不仅如此,我们还要发送请求,并让后台返回数据,同样加密处理,这也是一个烟雾弹,目的是过滤掉半吊子,减小风险。

真实的数据我们要存储在不常用的地方,比如IndexedDB

IndexedDB是浏览器里的数据库,因为其使用麻烦,加之兼容性问题,所以很少被使用。
综合考虑,所以我们采用localforage,这是一个npm包,有兴趣可以了解一下。

localforage优先使用IndexedDB存储,即使我们将数据藏在这,一旦被人破掉前面两关,查看其它本地存储就会暴露。

那么试着最后的欺骗,给数据加密,key和value都是由空格组成的数据,即使数据在变动,也难以感知

当然这样还不够骚,再来个临时变量,把数据存在内存中,优先使用内存中的数据,没有数据再从localforage里取。


以上便是整个策略,

xhr虚假请求
localStorage迷惑
偏门存储
空白数据
内存防护

明明就是个简单的功能,却搞这么复杂。没办法啊,前段时间我正好碰上了。


星空
1.3k 声望15 粉丝