有个项目 前后端分离 后端只能出个接口 然后前端是纯的JS代码请求 加入前端带个我后端指定的字符串来,才能请求成功,这个字符串用户可以通过查看JS源码 可以看到啊 这个方案就是没有意义了吗
有个项目 前后端分离 后端只能出个接口 然后前端是纯的JS代码请求 加入前端带个我后端指定的字符串来,才能请求成功,这个字符串用户可以通过查看JS源码 可以看到啊 这个方案就是没有意义了吗
说没有意义,其实还是有点意义的。至少可以防止一些人看到你的请求。
但是,不得不否认的是,这个方法,的确是比较容易被破解。
一般比较严格的校验方法是,首次请求后端时后端返回一个token,此token一段时间内有效。在有效时间内带上此token可返回数据。
具体的token操作可参见我的另一个回答:https://segmentfault.com/q/10...
确实没有意义,api和普通的页面展示没什么区别,无非就是普通的页面混合了标签,更难采集罢了,想限制一些功能,就通过会员类似的功能来限制,不重要的内容本来就是放在公网让人访问的,普通页面不限制,api同样不用限制。
网页浏览的webapi和给app提供的api还是有区别的,app由于加固等措施可以存储敏感信息,所以可以加token等能防止普通的接口也不会被轻易访问,而js是完全透明的,所以无法做到同app似的限制普通的接口。
也未必没有意义啊,可以在用户第一次访问时候生成一个随机字符串,放入cookie,以后的请求都从cookie里面去字符串来验证用户,我觉得这样的方案也可以啊。
有点类似auth2的验证方式
3 回答5.2k 阅读✓ 已解决
5 回答2.1k 阅读
1 回答4.2k 阅读✓ 已解决
3 回答1.9k 阅读✓ 已解决
2 回答2k 阅读✓ 已解决
1 回答3.1k 阅读✓ 已解决
2 回答2.3k 阅读✓ 已解决
你这个方案是个不算方案的方案。。哈哈
因为你的这个方案的适用范围是互联网原始社会时期的一个“验签”方式。
随着前端程序猿的增多,他肯定知道这样能看 js 代码,进而能知道你们的秘密。
当这个秘密不再是秘密的时候,web 安全就会进入下一个阶段,给你们的字符串进行加密,然后再传给后端进行校验。
攻防总是相辅相成互相进步的,然后 web 安全就又进入下一阶段,等等等等。
cookie session md5 des rsa token oauth ssl cert 都是一步步发展过来的。
所以说 你这个方案的本质是可行的 只是方式是最原始的