在CI环境中运行Insomnia集合时OAuth2授权报错[oauth2] Failed to get token ReferenceError: window is not defined的解决咨询

我太懂你这个糟心的问题了——GUI里跑Insomnia集合顺风顺水，OAuth2授权弹窗输个账号密码就行，结果一到CI用inso run collection命令跑，直接报window is not defined的错，连带着所有测试都失败，属实头疼。

其实根源很好理解：GUI模式下的Insomnia是依赖浏览器环境的，授权弹窗靠的是浏览器的window对象，但CLI是纯Node.js的无交互环境，根本没有这个浏览器专属的API，所以原来的授权流程直接就崩了。给你几个可行的解决思路：

• 改用OAuth2密码授权模式（最推荐）
  这是专门为无交互环境设计的授权方式，完全不需要弹窗。打开你的Insomnia请求，切换到「Auth」标签页，把授权类型改成「Password Credentials」，然后填入你的用户名、密码，还有OAuth2服务器的Token端点地址、客户端ID/密钥（如果你的服务要求的话）。配置好之后，CLI运行时会直接用这些参数向授权服务器请求token，全程不需要依赖任何浏览器API，完美适配CI环境。

• 预生成Token，通过环境变量注入
  如果你的OAuth2服务支持生成长期有效的token，或者你能在CI运行前通过脚本自动获取token，可以把这个token存在CI的环境变量里（比如叫CI_AUTH_TOKEN）。然后在Insomnia的请求里，把授权方式改成「Bearer Token」，值引用这个环境变量{{ $env.CI_AUTH_TOKEN }}。这样CI运行时直接用预先生成的token，跳过整个授权流程，简单粗暴又有效。

• 清理脚本中的浏览器依赖代码
  检查一下你在Insomnia里写的请求前/后脚本，有没有残留依赖window对象的代码（比如GUI里用来提示弹窗的逻辑）。这些代码在CLI环境下完全跑不通，必须删掉或者改成Node.js兼容的写法，比如把弹窗提示换成直接用配置参数请求token的逻辑。

另外还要注意，确保CI服务器的网络能正常访问你的OAuth2授权服务器，别被防火墙或者代理拦了，不然就算配置对了也拿不到token。

内容来源于stack exchange