You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 15, 2020. It is now read-only.
Repository navigation
This repository was archived by the owner on Oct 15, 2020. It is now read-only.
class S extends vm.Script {}
for (const n of Reflect.ownKeys(vm.Script.prototype)) S.prototype[n] = vm.Script.prototype[n]
Object.setPrototypeOf(S.prototype, null)
new S('1+2').runInThisContext() // throws
This is somewhat interesting; the native code checks that the script object (the new S in rhis case) is an instance of ContextifyScript. For us, we do that via the javascript semantics of instanceof, and due to your manipulations of the prototype that instanceof check fails (in both v8 and chakracore) but v8's native implementation of ContextifyScript::HasInstance uses different internal behaviors to do with function templates to determine that the object was originally related to ContextifyScript.
@jdalton do you have a scenario where you wanted to do something like this and expected it to work?
I did check the other case, where you take a non-vm.Script object and set its prototype to vm.Script.prototype, and that ends up erroring out with "Illegal Invocation" in both v8 and chakra. I think that the requirement from native code here is just that we can get access to the wrapped native object that is created as part of ContextifyScript (which is the superclass of vm.Script), but I don't believe that with chakra/chakrashim we can currently tell how an object was constructed.
I ran into some code working in node-V8 and not in node-chakracore. The workaround was to set the prototype to that of the ContextifyScript prototype instead of null.
Activity
MSLaguana commentedon Jun 23, 2018
This is somewhat interesting; the native code checks that the script object (the
new Sin rhis case) is an instance of ContextifyScript. For us, we do that via the javascript semantics ofinstanceof, and due to your manipulations of the prototype that instanceof check fails (in both v8 and chakracore) but v8's native implementation ofContextifyScript::HasInstanceuses different internal behaviors to do with function templates to determine that the object was originally related toContextifyScript.MSLaguana commentedon Jun 25, 2018
@jdalton do you have a scenario where you wanted to do something like this and expected it to work?
I did check the other case, where you take a non-
vm.Scriptobject and set its prototype tovm.Script.prototype, and that ends up erroring out with "Illegal Invocation" in both v8 and chakra. I think that the requirement from native code here is just that we can get access to the wrapped native object that is created as part ofContextifyScript(which is the superclass ofvm.Script), but I don't believe that with chakra/chakrashim we can currently tell how an object was constructed.jdalton commentedon Jun 25, 2018
I ran into some code working in node-V8 and not in node-chakracore. The workaround was to set the prototype to that of the ContextifyScript prototype instead of
null.MSLaguana commentedon Jun 25, 2018
I'm curious what the intent of the code was; why was the code removing the prototype?
jdalton commentedon Jun 25, 2018
Creating a "safe" reference to the
vmmodule here the safe() helper willnullthe prototype.