haml / haml

HTML Abstraction Markup Language - A Markup Haiku
http://haml.info
MIT License
3.77k stars 574 forks source link

Upgrading from 5.1.2 to 5.2.2 #1078

Closed choubacha closed 2 years ago

choubacha commented 2 years ago

And a string that used to parse correctly is now being over-encoded:

      %a{href: "[%= app.internalPath(h.path(\'profile\')) %]".html_safe, target: "_blank" }= s.t('header.link')

The result is that the apostrophe's around profile are encoded as:

h.path('profile')
choubacha commented 2 years ago

It looks like this is intentional and only by completely turning off escaping attrs globally does it work again.

I'm not sure how the latest version caused this to start happening but would it be possible for attributes to allow html_safe strings?

k0kubun commented 2 years ago

We're being consistent with Rails in the way we approach the "vulnerability" with a CVE. Rails helpers escape attributes even if you pass an html_safe object, and we did the same https://github.com/haml/haml/pull/1028. If you want Haml's Rails support to be changed, I suggest you to let Rails change the behavior first.

mockdeep commented 2 years ago

This seems like a breaking change. We've got a bunch of handlebars style templates in our haml and upgrading causes quite a bit of breakage in our app:

- class_name = "requested-field {{= required ? 'required' : '' }}".html_safe
%div{ class: class_name }

the 'required' is becoming 'required'