Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

incorrect escaping #10707

Closed
simevo opened this issue Feb 8, 2023 · 9 comments
Closed

incorrect escaping #10707

simevo opened this issue Feb 8, 2023 · 9 comments

Comments

@simevo
Copy link

simevo commented Feb 8, 2023

What version of Hugo are you using (hugo version)?

The stock package on Debian bookworm:

$ hugo version
hugo v0.110.0+extended linux/amd64 BuildDate=2023-01-27T10:03:29Z VendorInfo=debian:0.110.0-1

Does this issue reproduce with the latest release?

Yes, this is the latest release.

Problem description

I configure a global parameter baseURL = "/", and request it to be inserted as known-safe JavaScript (https://gohugo.io/functions/safejs/) within some backtick-delimited JavaScript strings inside a <script> tag.

In certain cases the slash is incorrectly escaped.

Minimal example

Extract minimal.zip in /tmp/minimal, launch hugo, then look at public/index.html:

      let a = `/</`
      let b = `\//`
      let c = `//`

based on the layouts/shortcodes/home_map.html shortcode:

      let a = `{{ .Site.BaseURL | safeJS }}</`
      let b = `{{ .Site.BaseURL | safeJS }}/`
      let c = `{{ .Site.BaseURL | safeJS }}/`

I'd have expected this output:

      let a = `/</`
      let b = `//`
      let c = `//`

but the slash in the second string is escaped. If you remove the < line from the first string, all urls are correctly unescaped.

Something weird is going on!

@jmooring
Copy link
Member

jmooring commented Feb 9, 2023

This seems like a bug (due to inconsistent output when comparing lines 2 and 3) in Go's html/template package. If I switch to using Go's text/template package with...

[outputFormats.HTML]
isPlainText = true

... I get the expected results:

 <script>
let a = `/</`
let b = `//`
let c = `//`
</script>

With the default output configuration (using Go's html/template package), if I pass the entire string through safeJS I also get the expected results:

<script>
  let a = `{{ printf "%s</" site.BaseURL | safeJS }}`
  let b = `{{ printf "%s/" site.BaseURL | safeJS }}`
  let c = `{{ printf "%s/" site.BaseURL | safeJS }}`
</script>

@bep bep added Upstream and removed NeedsTriage labels Feb 10, 2023
@bep bep added this to the v0.111.0 milestone Feb 10, 2023
@bep
Copy link
Member

bep commented Feb 10, 2023

I (think) this should test it in Go: https://go.dev/play/p/uHRYjxnzIaI?v=goprev

But that gives me:

let a = `/&lt;/`
let b = `//`
let c = `//`

Which I also assume is not correct.

@bep
Copy link
Member

bep commented Feb 10, 2023

OK, revisiting this with:

https://go.dev/play/p/Nl4_5-ynidw?v=goprev

Wrapping it in <script> makes it behave different, but still wrong, I guess.

@jmooring
Copy link
Member

Do you want me to log an issue upstream?

@bep
Copy link
Member

bep commented Feb 10, 2023

Do you want me to log an issue upstream?

Yes, that would be good (I suspect they're a little tired of my issue "spamming").

@jmooring
Copy link
Member

jmooring commented Feb 10, 2023

golang/go#58460

@jmooring
Copy link
Member

The original issue was opened on Dec 3, 2014.
golang/go#9200

@bep bep modified the milestones: v0.111.0, v0.112.0 Feb 15, 2023
@karelbilek
Copy link

This is a known go bug with no easy solution

@bep bep modified the milestones: v0.112.0, v0.113.0 Apr 15, 2023
@bep bep modified the milestones: v0.113.0, v0.115.0 Jun 13, 2023
@bep bep modified the milestones: v0.115.0, v0.116.0 Jun 30, 2023
@bep bep modified the milestones: v0.116.0, v0.117.0 Aug 1, 2023
@bep bep modified the milestones: v0.117.0, v0.118.0 Aug 30, 2023
@bep bep modified the milestones: v0.118.0, v0.119.0 Sep 15, 2023
@bep bep modified the milestones: v0.119.0, v0.120.0 Oct 5, 2023
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 26, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants