Preventing HTML character entities in locale files from getting munged by Rails3 xss protection
Posted
by
Chris S
on Stack Overflow
See other posts from Stack Overflow
or by Chris S
Published on 2010-08-13T13:58:27Z
Indexed on
2011/01/10
4:53 UTC
Read the original article
Hit count: 267
We're building an app, our first using Rails 3, and we're having to build I18n in from the outset. Being perfectionists, we want real typography to be used in our views: dashes, curled quotes, ellipses et al.
This means in our locales/xx.yml files we have two choices:
- Use real UTF-8 characters inline. Should work, but hard to type, and scares me due to the amount of software which still does naughty things to unicode.
- Use HTML character entities (’ — etc). Easier to type, and probably more compatible with misbehaving software.
I'd rather take the second option, however the auto-escaping in Rails 3 makes this problematic, as the ampersands in the YAML get auto-converted into character entities themselves, resulting in 'visible' &8217;s in the browser.
Obviously this can be worked around by using raw
on strings, i.e.:
raw t('views.signup.organisation_details')
But we're not happy going down the route of globally raw
-ing every time we t
something as it leaves us open to making an error and producing an XSS hole.
We could selectively raw
strings which we know contain character entities, but this would be hard to scale, and just feels wrong - besides, a string which contains an entity in one language may not in another.
Any suggestions on a clever rails-y way to fix this? Or are we doomed to crap typography, xss holes, hours of wasted effort or all thre?
© Stack Overflow or respective owner