猿人学web端爬虫攻防大赛赛题解析_第三题：访问逻辑

1、前言

好嘛，终于来到第三关了，继上次解完第二题后，大致看了下第三题，题目难度标注是“简单”，这可还行！终于碰到一道简单的赛题了，凭借前两题积累的小经验和小技巧，这题想来应该不会有什么大问题。然而我还是高估了自己，低估了题目，最终依然没能在不借助外力，不参考其他大佬解题思路的前提下把他整出来，怅恨久之！不过跟这道题死磕的一星期里还是有一些收获，闲言少叙，接下来进入正题！

2、题目理解

这道题的名称其实很有意思，从题目链接点进来以后，会发现网页的title显示的是罗生门，好奇的我专门查了下罗生门什么意思，因为这搞不好会为解题提供点思路。一番百度搜索后发现就是说真相扑朔迷离、真假难辨，进而让我思考到会不会是提供假数据什么的，后来发现路子走歪了，关键还在于网页的访问逻辑！

3、解析过程

3.1、逻辑分析

3.1.1、一回生

一开始还是照例，打开开发者模式，观察访问页面是发生了哪些请求

从观察到的请求链接来看，不出所料，数据也是通过AJAX请求获得的，
观察这个请求的返回值：http://match.yuanrenxue.com/api/match/3，可以发现数据就是通过这个api返回的。
那么问题来了，这个请求是否携带了什么加密参数，或者cookie信息？查看请求头，发现请求时的确携带了这个叫sessionid的cookie信息，并且响应头里也返回了Set-Cookie，也就是说在发送完请求后，服务器会返回sessionid，大胆推测一下，之后请求的时候带上这个sessionid是否可以会通过服务器校验，直接返回数据？

经过几次翻页，可以发现之后的请求，我们cookie里携带的是这个sessionid，服务器每次也会返回Set-Cookie信息，并且与最初的sessionid一致。
看起来发现了不得了的规律，接下来，就在请求头里携带这个sessionid模拟一下，直接请求这个数据接口！理想很丰满，现实很骨干，当场失败！看起来返回了一段类似加密的代码，这里尝试了一同分析，发现这段js脚本跟我们的sessionid毫无关系，就是干扰项。

3.1.2、二回熟

上面那波分析显然没走到正途上，再回头仔细看看访问页面时发送的所有请求，可以看出每次请求数据时，都会先请求logo这个链接，之后才是数据页，那么整个逻辑会不会是访问logo时先返回了sessionid，之后再带着它去访问数据页。

为了验证上面的想法，先把cookie清一清，重新刷新下页面：

可以发现在初次请求时，logo页是不带cookie的，并且响应头里的确返回了Set-Cookie值：
而在请求数据api接口时，发现这里携带的sessionid的值与请求logo页面返回的Set-Cookie的sessionid值是一致的，也就是说，每次请求数据时，确实是：先请求了logo页面，之后再带着这里返回的sessionid去请求数据api接口。

经过上面一番分析，可以说整个访问逻辑基本已经清晰了，要想拿到数据，首先就要访问logo页，否则无法携带正确的cookie信息发起数据请求。

3.1.3、三回滑铁卢

就目前而言这题对我来说已经没什么秘密了，就是这样！接下来还不是轻轻松松请求到数据，验证我严谨缜密的推理的时候！事实证明，人有时候还是不能盲目自信，尤其是当你还是个菜鸡的时候，你走的每一步都要再三考虑，是不是还有哪里