说来容易做来难,大部分人都倒在头一步了
拿 charles 抓包看一下两边的请求,99.99999999% 是不一致的,你这个问题我遇到过无数次
开源精神不为牟利——藉此安慰吧
页面下线,接口不下,反正有字段记录你的请求时间呢,到时候直接以作弊为由砍掉你的所有收益。“最终解释权归本公司所有”。
我相信楼主的 RP 肯定没问题,只是有曾经的同事去了猎豹一段时间后愤然离职说是办公室政治文化太厉害,被排挤出来了。不知可信度如何
对于代码能力不怎么强的人来说,rf 可以实现一些自己想实现又没能力实现的功能,但是毕竟是别人的架子,就得按照人家的规矩来,可能很多时候实现得很笨。高手肯定不屑于这么做
绕开前端,走接口
乙醇大大,开个专栏可好?
还在用 Robotframework 写接口测试用例的小白瑟瑟发抖。。。。究竟 RF 写到什么程度就算 “毕业” 了呢?
明天到暴雪总部上班,签证飞机票报销!
思寒大佬扎心了,但是说得很中肯
耐着性子看完了,楼主你这就是个标准的。。。。。。团队毒瘤啊
这么好的条件,却没有工作地点,楼主你想招地球人去哪里上班?
七上八下,翻译过来就是 7up8down,触发服务器预警,down!~屏蔽,bang·~
不轻易发表意见&不轻易站队,更不轻易喷人。尊重开源精神
8-12k,这么惨么?3 年经验的
不错,已 add star
去了鼓楼那个部门面过,感觉并不太好,没问什么太难得东西,但是依然 fail 了,没缘
不慌,小场面 不怕你不用
只是端外注册,核心还是要在 app 内注册
接口没有鉴签校验么?以前做的时候往往卡在这一步,没有秘钥
原本的图形验证码逻辑存在漏洞,用户在输入了正确的图形验证码后会产生一个有效的鉴权 id,持续若干时间。在这个时间段内,都可以发送短信验证码的请求。我们在前端做了设置,只要用户点击了发送短信验证码,就同时触发一个刷新图形验证码的请求。但是没有考虑到攻击者可以通过接口绕开前端的限制,直接调用短信验证码的请求,达到刷我们用户信息的目的。
做了请求频率和 IP 限制,但是不能规避大规模分布式跑脚本这种情况,只能说防一般的攻击手段吧
同感落地之艰难,楼主好赖是做出了东西,我这空有 title 啥都做不出来的才叫纠结,更别提落地了
楼主再不更新,吃瓜群众就替你补了:运营转测试,测试转开发的一点感想,就是没有感想