阻止语言环境文件中的HTML字符实体被Rails3 xss保护所消除 [英] Preventing HTML character entities in locale files from getting munged by Rails3 xss protection

问题描述

我们正在构建一个应用程序，我们首先使用Rails 3，并且从一开始就必须构建I18n。作为完美主义者，我们希望在我们的视图中使用真正的印刷术：破折号，卷曲引号，省略号等。

这意味着在我们的locales / xx.yml文件中两种选择：

1. 内联使用真正的UTF-8字符。
   应该可以工作，但很难打字，
   会让我感到恐慌，因为
   软件的数量仍然会对unicode
   调皮捣蛋。


2. 使用HTML
   字符实体（&＃8217;
   &＃8212;等）。更容易输入，
   ，并可能与
   行为不当的软件兼容。

我宁愿花第二个选项，但是Rails 3中的自动转义会导致这个问题，因为YAML中的&符号会自动转换为字符实体本身，导致浏览器中出现'可见'& 8217; s

显然这可以通过在字符串上使用 raw 来解决，例如：

  raw t（'views.signup.organisation_details'）
  

但是我们并不乐意沿着全球原始 -ing的路线走下去，因为每当我们 t >我们可以选择 raw 我们知道包含字符实体的字符串，但这很难扩展，只是感觉不对 - 此外，包含一种语言实体的字符串可能不会在另一种语言中。

任何一个聪明的rails-y方式来解决这个问题的建议？或者，我们注定要废话排版，xss洞，小时的浪费精力或所有这些？ 解决方案

有一个灯塔上的票证，这个问题的解决方案是将 _html 附加到 locales / xx.yml 文件中的i18n键，并使用 t alias ¹ 表示一个html_safe字符串。例如：

  en：
 hello：这是一个带有口音的字符串：& oacute; 
  

变成：

  en：
 hello_html：这是一个带有口音的字符串：& oacute; 
  

它会创建以下输出：

< blockquote>

这是一个带有口音的字符串：ó

这样可以防止您不得不写 raw t（'views.signup.organisation_details'）并且会产生更清晰的输出： t（'views.signup.organisation_details_html'）。而在交换 raw 时， _html 似乎并不是最大的交易，但它确实表明，重新输出假定为html_safe字符串的内容。

---

1 我测试了灯塔票上建议的代码。我发现的是你必须特别使用 t 别名。如果您使用 I18n.t 或 I18n.translate ，则翻译不会将 _html 为html_safe：

  I18n.t（'hello_html'）
 I18n.translate（' hello_html'）
＃Produces => 这是一个带有口音的字符串：& oacute; 
 
 t（'hello_html'）
＃Produces => 这是一个带口音的字符串：
  

我不认为这是预期行为根据 RoR TranslationHelper文档。

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:

1. 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.
2. Use HTML character entities (&#8217; &#8212; 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?

解决方案

There is a ticket in lighthouse for this problem, and the resolution is to append _html to the i18n key in the locales/xx.yml file and use the t alias¹ to denote an html_safe string. For example:

en:
  hello: "This is a string with an accent: ó"

becomes:

en:
  hello_html: "This is a string with an accent: ó"

And it would create the following output:

This is a string with an accent: ó

This would prevent you from having to write raw t('views.signup.organisation_details') and would result in a cleaner output of: t('views.signup.organisation_details_html'). And while exchanging raw for _html doesn't seem like the greatest of trades, it does make things clear that you're outputting what is assumed to be an html_safe string.

---

¹ I've tested the code suggested in the lighthouse ticket. What I found was that you had to specifically use the t alias. If you used I18n.t or I18n.translate the translation didn't treat _html as html_safe:

I18n.t('hello_html') 
I18n.translate('hello_html') 
# Produces => "This is a string with an accent: ó"

t('hello_html')      
# Produces => "This is a string with an accent: ó"

I don't think this is the intended behavior per the RoR TranslationHelper documentation.

这篇关于阻止语言环境文件中的HTML字符实体被Rails3 xss保护所消除的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！