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
The author may want the reviver to be called before the object is placed into the import graph. So that all imports may now yield the revived object for efficiency and performance.
But at that point, it could very well be debated that the author ought to be using a normal ECMAScript/Wasm export:
But, paired with @devsnek's suggestion about using a reviver function in the record/tuple proposal, this could be the key to resolving all of the immutability/mutability debates (#1, #2, #3, etc), possibly pleasing the average developer's expectations, while still providing the extra (small) step to make sure that interested developers don't shoot themselves in the foot by using an immutable object instead.
But I do believe that not freezing them or making them immutable becomes a security vulnerability.
For example, a web page author has a large, server-generated JSON module that is needed only upon the user interacting with a specific part of the page.
JSON module contents:
[ "foo", "bar", "quz" ]
They don't want to import it unless it's necessary due to both, server-side and client-side performance and resource costs, so they choose to lazily import it using a dynamic import call, only once the user has interacted with the page.
It could probably be exploited by malicious actors.
But, even if they had accessed it, parsing it into a Tuple first would've thrown a TypeError, as proxies cannot be inside of a tuple/record, safely preventing whatever the malicious actor planned on doing.
The text was updated successfully, but these errors were encountered:
ghost
changed the title
Reviver Function upon import?
Reviver function upon import?
Oct 17, 2020
Could it be possible to use a reviver function upon importing the JSON module?
Maybe another option, in line with the assertions proposal; ex:
The author may want the reviver to be called before the object is placed into the import graph. So that all imports may now yield the revived object for efficiency and performance.
But at that point, it could very well be debated that the author ought to be using a normal ECMAScript/Wasm export:
But, paired with @devsnek's suggestion about using a reviver function in the record/tuple proposal, this could be the key to resolving all of the immutability/mutability debates (#1, #2, #3, etc), possibly pleasing the average developer's expectations, while still providing the extra (small) step to make sure that interested developers don't shoot themselves in the foot by using an immutable object instead.
But I do believe that not freezing them or making them immutable becomes a security vulnerability.
For example, a web page author has a large, server-generated JSON module that is needed only upon the user interacting with a specific part of the page.
JSON module contents:
They don't want to import it unless it's necessary due to both, server-side and client-side performance and resource costs, so they choose to lazily import it using a dynamic import call, only once the user has interacted with the page.
Example ECMAScript:
But, before it was ever imported by the author's code, another module had imported it and modified it:
It could probably be exploited by malicious actors.
But, even if they had accessed it, parsing it into a Tuple first would've thrown a
TypeError
, as proxies cannot be inside of a tuple/record, safely preventing whatever the malicious actor planned on doing.The text was updated successfully, but these errors were encountered: