refactor: allow resolution of variables in the proto chain #578
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
resolveVariableReference
enforces variables names to be own properties. This seems to be very restrictive, and instead, Reflect.has() orin
operator is probably better. In our case, the args structure provided to messages might be optimized in various ways (very likely be immutable structures) that does not necessary have a flatten structure, and instead it might rely on the__proto__
chain.Perf Considerations
I believe this change will not necessary introduce a significant chante in terms of performance. Yes, missing variable names lookups will take one more step (most likely a look up on
Object.prototype
which is probably optimized by engines already), but that should not move the needle IMO.Security Implications
The interpolation is already very secure (by doing the escaping), with this change, poisoning of the Object.prototype is possible, but again, you can only attack message if the consumer is not providing the variable name, in which case Object.prototype lookup will occur. There are other different ways to do a similar attack, including patching
Object.prototype.hasOwnProperty
on itself :), so I will consider this to not be an issue.TODO