-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Built-in properties cannot be accessed using Reflect, when Proxy is passed as vm context #7458
Comments
I'm not sure I'd expect that to work, since target is // Test 2
assert.strictEqual(
typeof vm.runInNewContext("String",
new Proxy({},{
get: function(target, property, receiver) {
return Reflect.get(global, property);
}
})),
'function'); |
nodejs#7458 https//github.com/nodejs/issues/6158
The workaround does not make use of the new context, but simply forwards the current one. This breaks the sandboxing. For example:
|
Was hoping this might be fixed in Node 8.0.0, but looks like it's still an issue: > vm.runInNewContext("String", {})
[Function: String]
> vm.runInNewContext("String", new Proxy({},{}))
[Function: String]
> vm.runInNewContext("String", new Proxy({},{get: function(target, property) { return target[property] }}))
undefined
> vm.runInNewContext("String", new Proxy({},{get: function(target, property) { return Reflect.get(target, property) }}))
undefined Basically, contextifying a Proxy that has a handler that traps |
This is still an issue in Node.js 10.0.0, right? @nodejs/vm Does this seem like a confirmed bug? Or is it not clear that it's a bug? If it is a bug, should we add a |
i'm currently of the opinion that this is not a bug, for i submit to you the following: > vm.runInNewContext("String", new Proxy({}, { has() { return false } }))
[Function: String]
> the proxy said it had the property "String" and didn't allow property access to walk up to the next level |
I'm of the same opinion: not a bug, just misuse of proxies. Note how // passing {}
vm.runInNewContext("String", new Proxy({}, {get: function(target, property) {
return target[property] // undefined, naturally
}}))
// passing {String}
vm.runInNewContext("String", new Proxy({String}, {get: function(target, property) {
return target[property] // now it works
}})) I'll close this out. |
ok, thanks, so to clarify my use-case: if you want to trap It seems a reasonable workaround I guess, but it still feels a bit weird to me that... vm.runInNewContext("String", new Proxy({},{})) ...works (i.e. if you're NOT trapping |
@doughsay yeah that stuff tripped me up too, you might want to take a look at proxy membranes |
So I accept that this isn't a bug as-stated, but that still leaves us without any means of proxying a context global while forwarding requests to the original global. The proposed workaround does not work, as the String being passed is now the outer context's string, not the new context String. To adapt the previous example, the following will fail:
|
Use |
Associated with #6158
Empty Proxy object correctly handles this case, but unfortunately it's impossible to access 'built-in' from custom getter (using Reflect)
Second test returns AssertionError: 'undefined' === 'function'
The text was updated successfully, but these errors were encountered: