This commit fixes a Remote Code Execution (RCE) reported by
npm-security. Access to non-enumerable "constructor"-properties
is now prohibited by the compiled template-code, because this
the first step on the way to creating and execution arbitrary
JavaScript code.
The vulnerability affects systems where an attacker is allowed to
inject templates into the Handlebars setup.
Further details of the attack may be disclosed by npm-security.
Closes#1267Closes#1495
Fixes#1327
- This commit creates a shallow copy of the "options" passed to
Handlebars.compile() in order to prevent modifications
- Note that "new Handlebars.Compiler().compile(..., options)" still
modify the options object. This might change in the future, if
anybody needs a fix for that.
Closes#1341
If the @partial-block is called as parameter of a helper (like in
{{#if @partial-block}}...{{/if}}, the partialBlockWrapper is executed
without "options"-parameter. It should still work in without an error
in such a case.
Fixes#1319
Original behaviour:
- When a block-helper was called on a null-context, an empty object was used
as context instead. (#1093)
- The runtime verifies that whether the current context equals the
last context and adds the current context to the stack, if it is not.
This is done, so that inside a block-helper, the ".." path can be used
to go back to the parent element.
- If the helper is called on a "null" element, the context was added, even
though it shouldn't be, because the "null != {}"
Fix:
- The commit replaces "null" by the identifiable "container.nullContext"
instead of "{}". "nullContext" is a sealed empty object.
- An additional check in the runtime verifies that the context is
only added to the stack, if it is not the nullContext.
Backwards compatibility within 4.0.x-versions:
- This commit changes the compiler and compiled templates would not work
with runtime-versions 4.0.0 - 4.0.6, because of the "nullContext"
property. That's way, the compiled code reads
"(container.nullContext || {})" so that the behavior will degrade
gracefully with older runtime versions: Everything else will work
fine, but GH-1319 will still be broken, if you use a newer compiler
with a pre 4.0.7 runtime.
Fixes#1252
- This fix treats partial-blocks more like closures and uses the closure-context of
the "invokePartial"-function to store the @partial-block for the partial.
- Adds a tes for the fix
Original PR by @travnels, commit-message edited by @nknapp
* Upgraded eslint to 19.0.0
* Cleaned up duplicate rules 'no-extra-parens', 'quote-props'
* eslint rule 'no-empty-label' was replaced.
Rule 'no-empty-label' was removed and replaced by: ‘no-labels’. ‘no-labels’ already in the project
* eslint rule 'space-after-keywords' has been replaced
Rules 'space-after-keywords' and 'space-return-throw-case' wer removed and replaced by ‘keyword-spacing’.
* Added parsoer-option: sourceType='module'
* Add unnecessary=false to 'quote-props' to remove warnings about unnecessarily quoted property.
Code corrections
* helpers.js: unused variable 'depthString' removed, detected by new eslint
Fixes#1284
Appearently, there is a use-case of stringifying the error in order to
evaluated its properties on another system. There was a regression
from 4.0.5 to 4.0.6 that the column-property of compilation errors
was not enumerable anymore in 4.0.6 (due to commit 20c965c) and
thus was not included in the output of "JSON.stringify".
The root cause of #1218 is that `invokePartial` creates a stack of data frames
for nested partial blocks, but `resolvePartial` always uses the value at top of
the stack without "popping" it. The result is an infinite recursive loop, as
references to `@partial-block` in the partial at the top of the stack resolve to
itself.
So, walk up the stack of data frames when evaluating. This is accomplished by
1) setting the `partial-block` property to `noop` after use and
2) using `_parent['partial-block']` if `partial-block` is `noop`
Fix#1218
The root cause of #1218 is that `invokePartial` creates a stack of data frames
for nested partial blocks, but `resolvePartial` always uses the value at top of
the stack without "popping" it. The result is an infinite recursive loop, as
references to `@partial-block` in the partial at the top of the stack resolve to
itself.
So, walk up the stack of data frames when evaluating. This is accomplished by
1) setting the `partial-block` property to `noop` after use and
2) using `_parent['partial-block']` if `partial-block` is `noop`
Fix#1218
Nils Knappmeier
Qiang Li
Nils Knappmeier
Lon Ingram
Charles O'Farrell
kpdecker
machty
Mark Christian