我最近盯上了一个网站，说是官方的，但里面的数据藏得跟什么似的，想靠人工查，累死也查不完。我有个朋友，急着用里头的一些历史记录来做市场分析，手动扒拉了一个星期，眼睛都快瞎了，求到我头上。
本站为89游戏官网游戏攻略分站，89游戏每日更新热门游戏，下载请前往主站地址:www.gm89.me
下定决心，必须攻克这个堡垒
我先跑去把那个网站研究了一遍。这网站做得，简直就是为了防人。列表页数据是动态加载的，翻页要等老半天。最恶心的是，你查几次关键词，或者连续翻几页，直接就给你弹一个滑块验证。这个滑块不是那种随便拉一下就能过的，它会检测你鼠标移动的轨迹和时间，稍微有点程序化的痕迹，立马判定你是机器人，让你重来。我试着用现成的工具模拟了几次轨迹，次次失败。
当时我就来火了。这数据明明是公开的，你搞得这么复杂，不就是想让大家难受吗？我心里就憋着一股劲，一定要把这层“秘密”给揭开。这已经不是一个技术问题了，这是面子问题。
第一次交手：被动态加载狠狠绊倒
我先是老老实实地从前端入手。我用浏览器开发者工具把网络请求从头到尾拉了一遍。果然，列表数据是通过一个POST请求拿回来的，但请求的参数里，混着一堆时间戳和加密的字符串。我试着反向去推导这些加密字符串是怎么生成的，结果发现它们依赖于好几个前置的JS文件执行结果，这些文件之间互相调用，逻辑复杂得要命。
我花了一整天的时间，试图在本地还原这个JS的执行环境。虽然勉强跑通了，能生成合法的参数，但效率太低了。每请求一次，我要先运行几十毫秒的脚本，才能拿到合法的查询参数。而且这还没解决那个滑块验证的问题。
我算了算账，如果我用这种方式去跑数据，一天能拿到的数据量，还不如雇一个大学生在那儿手动复制粘贴来得多。这条路，走不通。
为什么我非要死磕到底？
朋友的事只是个引子。说起来，我早年也吃过这种“信息壁垒”的亏。那时候我刚开始做点小生意，急需一个行业的公开报告，结果那个官方网站也是这样，各种权限、各种限制，我不得不花了一大笔钱，从第三方手里买到了二手信息。那时候我就发誓，以后再遇到这种故意设置门槛的“公开”信息，我非得把它扒个精光不可。
为了攻克这个网站，我晚上饭都吃得不踏实，脑子里全是请求头和响应体。我把整个请求过程打印成了上百页的日志，像侦探一样，一点点地在里面找线索。
绝地反击：绕过滑块，找到后门
我把注意力从复杂的JS加密和滑块上移开，开始关注网站的底层架构。我想，既然数据最终是放在数据库里的，那么必然有一个最简单的API接口负责吐出数据，所有的花里胡哨都是套在外面的保护壳。
我重新分析了滑块出现前后的所有网络流量。我发现，每次点击搜索，网站在发起主查询请求之前，都会先发起一个特别奇怪的GET请求。这个请求没有带任何参数，但返回的响应头里，静静地躺着一个叫X-Request-Key的东西。这个Key，看起来像是随机生成的，有效期非常短。
我突然灵光一闪：滑块验证，是为了保护那个生成加密参数的JS代码不被运行；但如果这个X-Request-Key是真正的会话令牌，能不能直接用这个Key，跳过滑块，直接向API要数据？
我赶紧动手测试。我写了个简单的脚本：
- 第一步：发起那个“探路”的GET请求，硬生生地把响应头里的
X-Request-Key给抠出来。 - 第二步：我构建了一个极度干净、没有加密参数的POST请求，只带了最基本的查询条件和分页信息，然后把那个
X-Request-Key塞进了请求的头部（模拟成正常的浏览器会话）。 - 第三步：发送请求。
屏幕上闪了一下，我心跳都快停了。结果，数据直接以最原始的JSON格式吐出来了！干干净净，没有滑块，没有复杂的JS加密！我成功地找到了网站的“后门”，绕开了所有防御措施。
我赶紧把这个流程自动化封装起来，跑了一晚上，第二天早上，我朋友需要的全部历史数据，已经整齐地躺在了他的电脑里。这个所谓的“秘密官网”，在我的工具面前，彻底失去了它的秘密。
我看到那些自以为藏得很好的网站，就忍不住想笑。只要是数据，它就一定有出口。
技术这东西，就得拿来解决实际问题。
