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