原创来自本人的公众号:阿嚏个技术
公众号文章地址:得物采集数据出现geetest验证码的解析方式
本文仅提供反爬技术的分析思路,勿做商业用途,如有侵权,请联系删除。
之前写过一篇爬得物数据的文章《毒(得物)APP历史购买数据抓取》,阅读数还是挺不错的,不过那篇文章其实有些误导,当时是通过在手机上模拟用户的点击和滑屏操作,然后获取相关页面,再对内容进行识别来获取所需数据,那种方式一是效率不高,2天还没解析完一个商品的历史数据;二是数据误差大,因为模拟滑屏操作有定位和延时加载的问题,会导致很多重复数据。有些网友也指出了其中的问题,有网友也说api的效率高,的确研究了其API后做的采集方式很快,一个商品的数据基本就是分分钟的事情。
不过......
得物也是在不断进化的,很快接口的方式发生了变化,甚至有些接口已经失效。相信前一段时间跑API的朋友,会发现接口会经常返回401(请求直接被拒绝),485(请求需要验证码)的错。例如:
{"code":485,"data":{"challenge":"202c8c44a1226df446e1207519df6180","gt":"2acebf85e53151975f4a82b8a812ff02","newCaptcha":true,"resultCode":485,"serverStatus":1},"msg":"请校验验证码","status":485}
出现验证码的情况,手机APP人工操作也是会出现的,为了防爬得物还是牺牲了一些用户体验。
那么下面就是针对这种情况进行分析,给大家提供下思路,供大家参考。
先上图,下面是通过charles抓取得物小程序的图:
从蓝色标识的地方开始,向下的红箭头表示接口执行的顺序。
蓝色的地方表示收到了485状态的返回(图中下部的红框可以看到),然后调用了geetest的滑块验证功能,手工把滑块滑到正确的位置后,小程序向dewu的安全反爬接口发了2个请求,请求返回成功后又可以继续浏览相关界面。这就是这个验证码处理的过程,在上图中用黄色框分别标识了3个步骤。
那么解题思路来了,在我们碰到接口返回485的时候,我们是不是处理好geetest的验证即可?对的,我验证过了。
# 发起搜索商品请求
json_data = search_by_keywords_load_more_data('GV7903', 0, 1, 1)
resp = json.loads(json_data)
print(resp)
# 需要进行验证
if resp['code'] == 485:
# 通过geetest进行验证码处理
validate, new_chanllge = get_geetest_slide(resp['data']['gt'], resp['data']['challenge'])
# 获取geetest处理结果
if validate:
# 将geetest的结果去反爬接口验证
val = check_validate(validate, new_chanllge)
# 验证成功进行第二次商品搜索
if val:
json_data = search_by_keywords_load_more_data('GV79', 0, 1, 1)
print('second request:', json_data)
执行的结果如下,second request的请求就返回了正常的数据。
至于geetest如何实现处理,不在本文讨论之中,有兴趣的朋友自行在网上搜索下。
有兴趣的朋友可以搜微信公众号:阿嚏个技术,主要对自己的技术和产品做个记录。