课题背景

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

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

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

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

应对方案与优劣

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

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

该方案的优势在于：

• 一旦把风控关键点掌握了（比如，破解了对方的加密参数 等），那么只要注意不给源网站造成压力，就可以在用户无感知的情况下&利用插件后台快速采集数据；
• 而且，因为技术方案中大概率只会涉及到Service Worker层，所以开发较为简单；

方案二：请求重放

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

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

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

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

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

• 虽然，此方案需要同第三方案一样，需要由插件自发操控浏览器选项卡（且会被用户感知），但好在所有的技术方案都停留在插件Service Worker层的开发，所以对开发者比较友好；
• 而且，这种方案非常适合源网站的数据来源于API，即，无法从网页页面上直接解析获得数据的场景；

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

当在某些场景中，我们发现“页面中存在所有需要的数据 & 尽量降低风控风险”时，方案三就上场了，该方案一般这么设计：

用户从页面提交一堆网页链接之后提交给插件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。

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

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