This is an interesting idea. It's certainly easy at the moment to
forget the h on a field and open yourself up to XSS attacks.
Defaulting to h and having a way to get around it would be more
likely to show up problems in testing rather than in production. On
the other hand, it may be more trouble than it's worth. I'll reserve
judgement.
On the implementation side, I would think you'd add a "html_safe?"
attribute to String. Link_to et al could return strings that are
marked as html_safe, and %= could spit this straight out. (They'd
also have to look at strings passed in to them and determine whether
or not to escape them based on their html_safe flags.) Regular
strings would not be html_safe by default, and would be escaped by %
=. You could then provide a method to change a given string into its
html_safe version, and provide a one character abbreviation (similar
to 'h') so that you could do <%=s "<b>whatever</b>" %> when you
needed to.
The other useful thing would be a little ActiveRecord extension so
that you could mark an attribute of a model object as returning a
html_safe string, for those times you want to store HTML in the
database.
Hmm...it's all a little like string tainting in perl, really. You
could even go so far as to make, for example, concatenating two
html_safe strings return another html_safe string, but that'd be a
lot of work and probably not worth it.
So, the upshot of all that is that thinks like <%= link_to 'A
link!', ... %> would still work as they always have, but anytime you
want to put your own html in via %=, you'll have to mark it as safe.
That's reasonably neat and undisruptive I think.
If somebody does implement any of this as a plugin, I'd definitely
give it a go in our production code.
Cheers,
Pete Yandell
_______________________________________________
Rails-core mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails-core
