Javascript Heap Error when using nested loops

[sudo-apt-get-updates]

If you do nested loops, then Nodejs will throw a Javascript Heap Error and the application will crash. This means that you're forced to use the client-side version of LiquidJS. Is that version safe to use if end-users are allowed to edit templates?

      {% for boxs in boxs %}
      {% for boxss in boxs %}
      {% for boxsss in boxs %}
      {% for boxssss in boxs %}
      {% for boxsssss in boxs %}
      {% for boxssssss in boxs %}
      {% for boxsssssss in boxs %}
      {% for boxssssssss in boxs %}
      {% for boxsssssssss in boxs %}
      {% for boxssssssssss in boxs %}
      Test 
      {% endfor %}
      {% endfor %}
      {% endfor %}
      {% endfor %}
      {% endfor %}
      {% endfor %}
      {% endfor %}
      {% endfor %}
      {% endfor %}
      {% endfor %}
      {% endfor %}```

[harttle]

Liquid is not designed to support true secure sandboxing. You'll have to trust users who write templates not to be malicious. Otherwise you'll need something like tripwire or process managers. Or we do support deno as you can find more info here: #253

Another option as you mentioned is put this work in client side. This way at least you don't have to worry about DoS attacks. Client-side rendering is not silver bullet, it's still up to your scenarios. For example, if we render a page for user A with a template written by user B, it can potentially crash the Web page for user A.

[Bessonov]

I'm looking for a safe/secure templating engine. Due to fs interface Liquid looks great. But if there is no protection for such use cases, then how to interpret the claim "LiquidJS is a [...] safe [...] template engine [...]"? If I look at other issues and discussions, then it's clear that people use Liquid for templating from untrusted sources, and, probably, aren't aware of this one.

Unfortunately, I didn't found any better alternative. @sudo-apt-get-updates how did you resolved your issue?