课题背景

浏览器插件的重要使用场景之一就是 采集源网站上的数据，而数据的提取方式又可分为“页面 DOM 解析提取”、“API 请求获取”等。

一般，在由用户打开的页面上直接解析 DOM 节点来获取数据的方式最为“稳妥”，因为用户可视的所有数据都能在源网站无感知的情况下被解析采集，即，这种方案无论是对源网站的侵入性还是对我们采集方的可采集性来说都是最友好的。但是，“由用户打开页面再采集数据的方式”流程较为繁琐、用户参与度太高、对采集效率不够友好。

所以，普遍的需求场景是：用户提交一批需要采集数据的网页链接，再由插件后台循环请求源网站链接或接口获取数据。然而，在这种使用场景下，插件方或多或少的都会遇到源网站的风控问题。

今天，我们就来简单说几种“应对源网站风控”的方案与适用场景。

应对方案与优劣

方案一：确认源网站风控关键点并解决

该方案最考量“ JS 逆向工程的功底与实践能力”，需要插件开发者从反复的观察、断点中确认源网站的风控关键点并逐一应对、突破。

该方案的优势在于：

• 一旦把风控关键点掌握了（比如，破解了对方的加密参数 等），那么只要注意不给源网站造成压力，就可以在用户无感知的情况下&利用插件后台 快速 采集数据；

• 而且，因为技术方案中大概率只会涉及到 Service Worker 层，所以技术方案和开发流程都较为简单；

方案二：请求重放

但是，一般风控等级比较高的网站，短时间是无法试验出风控关键点或无法快速找到应对方案的（比如，找不到加密串的来源 等），那么，我们就可以退一步来使用“请求重放”方案。

“请求重放” 依据的是：当用户自行打开源网站时，源网站自身的请求可以顺利通过源网站风控系统的检测，那么我们只要想办法拿到这些“可以通过源网站风控系统的请求及参数”，然后在适当的时候重新触发去请求一次即可。

比起方案一，此方案更为复杂：

以 Chrome 插件为例，需要涉及到 chrome.webRequest.onBeforeSendHeaders 的监听设置、chrome.tabs 对浏览器选项卡的操作、相关请求数据的存储/使用；而且，因为请求的二次重放，还是比较容易被风控系统识别的（同样的参数、同样的头部信息的请求多次请求 源网站真的要逮你的话还是比较好识别的），所以后续的跟进必不可少；

但是，从需求场景与开发复杂性的折中角度来说，本方案还是有优势的：

• 虽然，此方案要和第三方案一样，需要由插件自发操控浏览器选项卡去让网页的请求被触发、记录外，用户会直接感知到浏览器选项卡的打开、关闭，但好在所有的技术方案都停留在插件 Service Worker 层的开发，所以对开发者比较友好；

• 而且，这种方案非常适合 源网站的数据来源于API 的场景，即，无法从网页页面上直接解析获得数据的场景；

方案三：由插件操控 TAB 并解析数据

当在某些场景中，我们发现“页面中存在所有需要的数据 & 尽量降低风控风险”时，也就是，需要获取的数据可能 挂载在 DOM 节点上、DOM 节点实例上、window 这种全局变量上 时，方案三就上场了，该方案一般这么设计：

用户从页面提交一堆网页链接之后提交给插件 Service Worker ，由 Service Worker 逐个打开 TAB 页、检测 TAB 页关键 DOM 节点是否加载完毕后，可以由 chrome.scripting 获取 DOM 节点信息后并解析，也可以向页面发送消息、由 Content 层解析当前页面的 DOM 数据后上报给 Service Worker；

不论从理论的角度还是从实践得出，第三种方案无疑是最“稳妥”的（除非源网站将打开的 TAB 页数量或频率作为风控关键点），因为它最贴近“用户操作路径”。

但是这种方案比较复杂，涉及到了 Content 层与 Service Worker 层的通信技术 或 chrome.scripting 的使用（越复杂的技术方案，出错点就会越多），而且这种方案并不适用于“无法从页面 DOM 中获取全部数据”的场景；

写在最后

应对源网站风控问题的最核心方案就是：尽量贴近“用户操作路径”（这也是RPA方案的宗旨）。

当下，本文记录的几种方案都是我在工作中使用比较多的，但它们之间并没有特别绝对的好坏之分，只有在平衡各方面的情况之后选择一种而已。就比如，在我的以往的工作经历中，其实还遇到过一种场景：源网站直接改写了浏览器暴露的 fetch API，并将风控最复杂的关键点内置在改写的 fetch API 中，同时介于当时“需求比较紧急”，我就直接改写了上面阐述的第三种方案：

当 Service Worker 接收到源网站链接之后，自动打开 TAB 页后，由 TAB 页的 Content 层发起 API 请求拿到数据后再返回给 Service Worker。

好啦，到此，本文只是简单的从插件开发方的角度阐明了几种“应对源网站的风控管理的方案”，并且可能由于我所遇场景的局限性，方案也比较局限，如果你有更好的方案，欢迎留言一起讨论哈～

另外，这会开一个文章系列，所以具体的各个方案的落地，敬请关注后续文章哦～