0%

metamask | 修改 metamask 配置让 selenium 可以直接操作

旧版本的 metamask 可以直接使用 selenium 操作,但是,新版本的需要修改参数才行。

具体原因如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
我看到关于此功能存在一些混淆,所以我将尝试更好地解释为什么如果您在 MetaMask 之上构建基于外部网络驱动程序的应用程序,如果您不自己编译 MetaMask,那么您会遇到困难而是使用官方版本。

此功能使应用程序的全局对象无法使用 - 是故意的。
我们可以允许自己这样做,因为 LavaMoat 使应用程序的 90-99% 的全局对象变得不敏感。

这是一项安全功能——LavaMoat 本质上是一个沙箱工具,用于对 JavaScript 代码进行沙箱处理。如果某些 JavaScript 代码设法逃离 LavaMoat 沙箱并到达全局对象,它将获得对沙箱试图从中撤销的 API 的访问权限。

例如,如果 LavaMoat 沙箱化了一个负责日志记录的依赖项,它只会授予它访问权限console.log而不是fetch- 但如果依赖项中的 JavaScript 代码以某种方式设法逃脱沙箱并到达全局对象,它将获得对fetchAPI 由全局对象提供。

尽管逃脱沙箱的可能性不大,但我们在 MetaMask 中努力实施多个安全层,以防某一层以某种方式被破坏。

[这正是#360](https://github.com/LavaMoat/LavaMoat/pull/360)的含义——第二次喜欢防守。

我们使全局对象不可用,因此如果 JavaScript 代码逃离沙箱并到达全局对象,它将无法访问全局对象通常提供的任何内容,从而保护应用程序免受这种情况的影响。

最终这意味着任何试图在全局范围内(在 LavaMoat 沙箱之外)运行的 JavaScript 代码如果依赖于访问全局对象必须提供的内容,都会失败。

所以const a = 1+1; const b = []; b.push(2);会工作,因为它不包括对全局对象的访问,但是像这样的东西const x = new Array(); const y = fetch('/'); const z = new Proxy(...)会失败,因为这些不再可以通过全局对象访问。

如果您使用外部 webdriver 来操作 MetaMask,您将面临这个问题,因为您通过 webdriver 代码在应用程序中运行的任何代码都会尝试访问全局对象上的内容并且会失败。

更进一步 - 网络驱动程序本身将代码注入到被操纵的应用程序中,并且该代码也依赖于全局对象才能正常运行,因此也会失败。换句话说,无论您编写什么代码,webdriver 本身都没有准备好处理这种独特的情况。

这是我们目前感觉良好的权衡(与人们能够使用网络驱动程序操纵 MetaMask 相比,安全性要好得多)。

因此,目前您唯一的选择仍然是通过构建您自己的禁用此安全功能的 MetaMask 版本来完成您想要的。

在 MetaMask 存储库中找到scuttleGlobalThis并将其设置false为 然后使用 构建应用程序yarn dist。您最终会得到一个不再损害全局对象的本地 MetaMask 版本。

当心 - 这会降低 MetaMask 的安全级别 - 使用风险自负。

下载 chromezip

然后解压,找到 runtime-lavamoat.js 文件,将 scuttleGlobalThisenabled 改为 false。ps: 这个版本是在第 97 行。

如果要供程序使用,把修改的 metamask 再压缩成 zip,记住,应该走进文件夹里面进行压缩。

请我喝杯咖啡吧~