html/template: allow actions in JS template literals

[rolandshoemaker]

This proposal is mutually exclusive with the already accepted proposal in #60055, but I believe is worth considering.

While prototyping the implementation for #60055 (see http://go.dev/cl/507995), we realized that it is actually not incredibly complicated to manage the state changes between template literals and nested string interpolation contexts (i.e. `${ ... }`) that would be necessary to allow us to safely support actions within JS template literals.

There are a handful of seemingly valid use cases for template literals which the current behavior (disallowing actions within template literals) breaks, namely it prevents using an action to construct a multiline string. With proper handling of template literals, we are in the position to possibly allow actions within them safely.

In order to prevent an action switching the context, strings inserted into the template literal context would need to have the characters $, {, } escaped. Actions in the string interpolation context would be treated the same as actions in the top-level JS context.

If accepted, the following templates would become acceptable (reverting the restrictions added in http://go.dev/cl/482079, and closing the existing loopholes).

// actions allowed within the string portion of the template literal,
// with the characters $, {, and } escaped.
<script>var a = `{{.}}`</script>

// actions allowed within the string interpolation portion of the
// template literal, with the same restrictions as the top-level JS context.
<script>var a = `${ {{.}} }`</script>

This would revert the restrictions added in http://go.dev/cl/482079, and deprecate ErrJSTemplate (which is, unfortunately, slated to be added in 1.21).

cc @golang/security @jupenur

[dwrz]

I would prefer this proposal, if it's feasible. :)

I haven't tried them yet, but the three workarounds that have come up for multiline strings appear to be:

1. A script data block, as proposed by @jupenur: html/template: refuse to parse complex JS template literals #60055 (comment). I prefer this one, but it does require an element lookup, e.g., document.getElementById('date-row-template').innerHTML.

2. Installing a template function like the following:

package main

import "strings"

func multilineJS(input string) string {
	lines := strings.Split(input, "\n")

	// Escape single quotes.
	for i, line := range lines {
		lines[i] = strings.ReplaceAll(line, `'`, "\\'")
	}

	// Reassemble.
	return "'" + strings.Join(lines, "' + \n'") + "'"
}

func main() {
	input := `<tr>
<td>'你好世界'</td>
<td>{{ .Start }}</td>
<td>{{ .End }}</td>
</tr>`

	print(multilineJS(input))
}

But this gets trickier (1) if you want to handle single and double quotes, (2) if you want to preserve newlines in JavaScript, I think you need add them to the string:

`<tr>\n
<td>'你好世界'</td>\n`

3. For my use case, I've been trying to avoid using dynamic forms, but it's meant round-trips form submissions instead of using the client to add more input fields.

Regardless, I really appreciate the work and time on this issue. I use Go's templates because I much prefer them to JavaScript, trying to use the latter only when necessary.

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[rsc]

As long as we can do this securely, this sounds like a win for everyone.

[rsc]

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

[rsc]

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

[gopherbot]

Change https://go.dev/cl/507995 mentions this issue: html/template: support parsing complex JS template literals

[gopherbot]

Change https://go.dev/cl/532595 mentions this issue: html/template: only track brace depth when we are in a JS tmpl lit

[jupenur]

@rolandshoemaker sorry for not getting to this sooner; I've been on PTO. The current (already merged) implementation is broken and escaping fails in this template:

<script>var foo = `${ foo({ a: { c: `${ {{.}} }` }, b: {{.}} })}`</script>

The new change at https://go.dev/cl/532595 doesn't seem to fix this either even though it does fiddle with the brace depth logic. The problem is that brace depth gets reset to 0 in places where there's nesting, and that breaks brace depth tracking for the outer JS template literals.

[rolandshoemaker]

Oh bah, you are correct, I thought I'd fixed this based on a particular case I was fixating on, but I realize now we actually need to track brace depth per-nesting level in order to properly address this.

[gopherbot]

Change https://go.dev/cl/532995 mentions this issue: html/template: track brace depth for each nested expression

[rolandshoemaker]

@jupenur I think http://go.dev/cl/532995 captures the correct behavior now, but each time I do this I'm less and less convinced I've gotten it right (which, given this is the... third(?) attempt at it, I've not got great odds). Enumerating all of the cases here is painful.