抓取得物数据出现验证码的解析思路

原创来自本人的公众号:阿嚏个技术

公众号文章地址:得物采集数据出现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抓取得物小程序的图:

抓取得物数据出现验证码的解析思路_第1张图片

从蓝色标识的地方开始,向下的红箭头表示接口执行的顺序。

蓝色的地方表示收到了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如何实现处理,不在本文讨论之中,有兴趣的朋友自行在网上搜索下。

有兴趣的朋友可以搜微信公众号:阿嚏个技术,主要对自己的技术和产品做个记录。

你可能感兴趣的:(互联网开发,得物,python爬虫,geetest)