假设有这么个场景
某天,你接到一个任务,需要开发一个作品投票的网站,可以让别人访问链接进入活动页面,每天给心仪的作品投几票。
这看起来好像很简单,但是有个问题,整个流程里没有登录系统,也就是说没法区分用户。
那还怎么存储用户数据?
localStorage
嗯哼,这好像只能这样了吧。可这安全性也太差了,分分钟被人刷票。
那就来点复杂的 —— 心理战术。
没有登录系统,稍懂点前端的就会猜出用户数据存在本地上,因为前端有权限问题,无法获取到IP或者MAC地址之类的唯一标识,那只能存浏览器本地。
所以我们需要在localStorage存储数据,只写不读,这是一个烟雾弹,用来迷惑别人。
当然,这还不够,太直白了,需要加密处理。
不仅如此,我们还要发送请求,并让后台返回数据,同样加密处理,这也是一个烟雾弹,目的是过滤掉半吊子,减小风险。
而真实的数据我们要存储在不常用的地方,比如IndexedDB
。
IndexedDB是浏览器里的数据库,因为其使用麻烦,加之兼容性问题,所以很少被使用。
综合考虑,所以我们采用localforage
,这是一个npm包,有兴趣可以了解一下。
localforage优先使用IndexedDB存储,即使我们将数据藏在这,一旦被人破掉前面两关,查看其它本地存储就会暴露。
那么试着最后的欺骗,给数据加密,key和value都是由空格组成的数据,即使数据在变动,也难以感知。
当然这样还不够骚,再来个临时变量,把数据存在内存中,优先使用内存中的数据,没有数据再从localforage里取。
以上便是整个策略,
①xhr虚假请求
②localStorage迷惑
③偏门存储
④空白数据
⑤内存防护
明明就是个简单的功能,却搞这么复杂。没办法啊,前段时间我正好碰上了。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。