84669 personnes étudient
152542 personnes étudient
20005 personnes étudient
5487 personnes étudient
7821 personnes étudient
359900 personnes étudient
3350 personnes étudient
180660 personnes étudient
48569 personnes étudient
18603 personnes étudient
40936 personnes étudient
1549 personnes étudient
1183 personnes étudient
32909 personnes étudient
手游、端游可以做到在程序内部加密要传递给服务器的数据,页游怎么做呢?假设一个场景, UserA 在MapA, UserB 在MapB打怪升级,然后突然被UserA切入战斗。
服务器的攻击接口肯定是暴露的,假如UserA curl一个请求攻击B(B的id肯定是暴露的), 即使js对传给服务器的B的id加密,对应的服务器解密,但是js加密代码是可以找到的。
我的问题是,页游怎么保证请求的合法性?
光阴似箭催人老,日月如移越少年。
不能保证
最多做到让非法请求成本变高,比如代码混淆、定期换api
逻辑验证?比如攻击只能发生在特定条件下,等等
加 token,token 里包含相关场景信息和随机信息。
类似于一些云存储上传文件或者其他文件操作时需要通过服务器获取一个 token,带该 token 的请求才能被正确处理。
这就是一个反爬虫的过程,这种接口很难完全杜绝伪造请求,就像一楼说的那样,加大非法请求的成本。建议可以参见一些网站的反爬虫技术,当然了,像一些验证码的技术就不可用了;可以做ip限制,请求频率限制,请求头数据中加入验证信息,随机令牌的使用,网页客户端的代码加密,然后服务端中严格控制业务逻辑的验证,就比如你问题中提到的被UserA切入战斗,服务端接收到请求后可以保证在战斗结束前不让第二个用户插入,当然这可能和你的业务不符合,这只是一个思路
其实就是前后端绑定问题,很遗憾在页游上无法实现,即使是在端游上也存在被逆向出来接口和secret的可能,更别说源代码几乎公开的页游了。
不过也不是完全没办法,我大概罗列了几条
逻辑验证,即使不通过你的页游发起请求,用户能做到的事也应该和通过页游操作时一样,换句话说就是让不通过页游操作变的没有必要
通过secret签名每一个请求
混淆secret,将secret拆分保存在多个变量里,甚至弄个密码加密secret等等
定期更换secret
定期更换接口甚至改变认证逻辑
token 保存在全局变量中,而不要保存在cookie或localstorage中,每次登陆先获取token
token过期自动废除机制和token刷新机制
不能保证
最多做到让非法请求成本变高,比如代码混淆、定期换api
逻辑验证?比如攻击只能发生在特定条件下,等等
加 token,token 里包含相关场景信息和随机信息。
类似于一些云存储上传文件或者其他文件操作时需要通过服务器获取一个 token,带该 token 的请求才能被正确处理。
这就是一个反爬虫的过程,这种接口很难完全杜绝伪造请求,就像一楼说的那样,加大非法请求的成本。
建议可以参见一些网站的反爬虫技术,当然了,像一些验证码的技术就不可用了;可以做ip限制,请求频率限制,请求头数据中加入验证信息,随机令牌的使用,网页客户端的代码加密,然后服务端中严格控制业务逻辑的验证,就比如你问题中提到的被UserA切入战斗,服务端接收到请求后可以保证在战斗结束前不让第二个用户插入,当然这可能和你的业务不符合,这只是一个思路
其实就是前后端绑定问题,很遗憾在页游上无法实现,即使是在端游上也存在被逆向出来接口和secret的可能,更别说源代码几乎公开的页游了。
不过也不是完全没办法,我大概罗列了几条
逻辑验证,即使不通过你的页游发起请求,用户能做到的事也应该和通过页游操作时一样,换句话说就是让不通过页游操作变的没有必要
通过secret签名每一个请求
混淆secret,将secret拆分保存在多个变量里,甚至弄个密码加密secret等等
定期更换secret
定期更换接口甚至改变认证逻辑
token 保存在全局变量中,而不要保存在cookie或localstorage中,每次登陆先获取token
token过期自动废除机制和token刷新机制