【问题标题】:Is there a method for accessing variables in the parent scopes of a function是否有一种方法可以访问函数的父范围内的变量
【发布时间】:2016-11-22 21:48:45
【问题描述】:

给定对function 的引用,是否可以访问其父作用域中的变量名称和/或值?例如:

let ref = (function myClosure() {
  const foo = 'foo';
  const bar = 'bar';
  
  return {
    sneaky() {
      // use the variables somehow
      // since some browsers optimize functions
      // by omitting parent scopes from the context
      // that are not used
      console.log(foo, bar);
    }
  };
}());

// given `ref.sneaky` in this scope, how to access the scope in `myClosure`?
console.log(ref);

在开发者控制台中检查ref,我们发现:

注意包含foobarClosure 对象。如果无法以编程方式获取此闭包对象,是否有任何目前提出的 ECMAScript 标准,例如 Symbol.scope,它可以包含给定函数的父“闭包对象”数组?

更新

为了解决 @Bergi 和 @Oriol 的 cmets,我添加了一些说明。

let ref = (function myClosure() {
  const foo = 'foo';
  const bar = 'bar';
  
  return {
    sneaky(...variableNames) {
      // use the variables somehow
      // since some browsers optimize functions
      // by omitting parent scopes from the context
      // that are not used
      console.log(foo, bar);
      
      return Object.assign(...variableNames.map(variableName => ({
          [variableName]: eval(variableName)
        })
      ));
    }
  };
}());

// given `ref.sneaky` in this scope, how to access the scope in `myClosure`?
console.log(ref.sneaky('foo', 'bar'));

当然,如果提前知道变量名,并且子作用域中存在eval,则此方法有效,但如果这两个条件都不满足怎么办?

【问题讨论】:

  • 真的没有意义。如果他们打算公开曝光,他们将是
  • @charlietfl 对我来说,这个问题更像是一种智力练习,而不是我打算使用的东西。我只是想知道控制台实用程序用于显示函数引用中的闭包的方法是否可以在 JavaScript 中访问,以及是否有一个标准提案正在制定中以使这成为可能。我认为仅仅基于所谓的变量范围“意图”就说这没有意义是没有道理的,因为无论如何这是一种假设情况。
  • 不确定我是否理解,但ref.sneaky() 不起作用?
  • @Oriol 没有。我要问的是访问我在屏幕截图中显示的Closure 对象。我目前正在更新我的问题以澄清这一点。
  • @PatrickRoberts 啊,所以你想访问环境记录,对吧?但这是规范的内部问题。实现甚至不需要它们。

标签: javascript scope closures metaprogramming symbols


【解决方案1】:

给定一个函数的引用,是否可以通过编程方式访问其父作用域中的变量名称和/或值?

没有。

目前是否有任何提议的 ECMAScript 标准,例如 Symbol.scope,它可以包含给定函数的父“闭包对象”数组?

没有。如果有,它永远不会被接受,因为闭包是在 javacript 中真正封装的唯一方法,而引入这样的访问器将是一个巨大的安全漏洞(有关参考,请参阅 http://www.ieee-security.org/TC/SP2011/PAPERS/2011/paper023.pdfhttp://web.emn.fr/x-info/sudholt/papers/miss13.pdf)。

【讨论】:

  • 我很抱歉,但是说范围界定是一种安全措施是绝对荒谬的。正如我刚刚展示的那样,即使它不能以编程方式实现,它显然也不会阻止任何打算利用任何客户端 API 方法或受范围“保护”的敏感数据的公开的人。那么,为什么你说这个提议永远不会被接受?
  • @PatrickRoberts:因为它可以通过编程实现漏洞利用。目的不是保护 USER 表单本身。目的是保护第三方代理的 USER 表单脚本注入。
  • @PatrickRoberts:你展示了什么?调试器不是程序访问,用户不是威胁。我们在这里讨论的是第三方脚本的安全性。
  • 好吧,这更有意义,我想我没有考虑过那个向量。我仍然认为范围界定不会保护任何东西,第 3 方脚本仍然可以将脚本作为字符串访问,从中剥离范围并使用像 Babel 这样的解释器对其进行评估,以获得它想知道的关于环境的任何信息在范围内,尽管这可能非常复杂和乏味。
  • @PatrickRoberts:“以字符串形式访问脚本” - 不一定。 API 的限制和大多数同源策略可以防止这种情况发生。但是,是的,这就是人们所关心的安全性。
猜你喜欢
  • 2018-08-16
  • 2019-01-05
  • 2019-12-03
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-09-24
  • 1970-01-01
  • 2012-01-13
相关资源
最近更新 更多