Hacker News Reader

Comment by dave1010uk | Hacker News Reader

I'm not sure I understand this. Are the number helpers now escaping for a HTML context? Isn't it best practice to escape user input just before outputting it (so you know the context) rather than in every helper function?

Disclaimer: not a RoR developer.

View on HN

some helpers produce escaped output, some don't. Think: "link_to(name, url)" must produce html that must not be escaped again while "strip(text)" can produce unescaped text.

So why would a currency formatter generate HTML instead of plain text? That seems very strange to me. How does the helper know if I want to use the number in HTML, an email header or even a shell argument? Or are RoR helpers designed to be only usable directly with HTML?

PHP's number_format() doesn't escape for HTML - is that an XSS bug too?

The view-dependent stuff is in fact separated from the business conversion logic and can be used in a non-web context if you want.

Here's the version for use in a view context: https://github.com/rails/rails/blob/master/actionview/lib/ac...

You can see that this method has some XSS prevention logic.

Here's the converter itself: https://github.com/rails/rails/blob/master/activesupport/lib...

Doesn't really affect this case though. Why does the numbers_to_ family need to produce HTML?

As far as I know, it doesn't emit HTML. The Rails view layer uses a string subclass called SafeBuffer (http://yehudakatz.com/2010/02/01/safebuffers-and-rails-3-0/) to manage implicit escaping.

I can't look at the diff for some reason (too many redirects), but I'd guess this issue was the result of some logic that was implemented before SafeBuffers were added.

Currency, for one might include an html/utf8 symbol

Reply on news.ycombinator.com