Rob Lacey wrote:
I guess its a bit of a whinge as well as to gauge other people's
opinions on it. Personally I haven't used the 'h' method a great deal
in the past 4 years of developing with Rails, I guess because our
validation generally doesn't allow for html being injected into our
database. But of course its always possible.
I have a feeling you're affording yourself a lot more confidence than
deserved. Just because you haven't been hacked yet, doesn't mean your
system is truly secure. It more likely means that, so far, nobody has
been interested in hacking your system. Hopefully that won't happen to
you, but if you're not "generally" using the h method, I'm betting you
have holes in your security (well less so now that you're moving to
"Generally" just doesn't cut it when it comes to security. Security is
like a chain, in that the integrity of the chain depends on its weakest
link. It doesn't matter if you have a thousand perfectly strong links,
if just one of them is weak then your system is vulnerable.
In my opinion it is far better to default secure, and then tell the
system when you want to loosen security when necessary. This is what
html_safe provides us.
Its a tricky one as I might expect that calling html_safe on a string
that has already been escaped because its deemed to be unsafe, would
actually unescape it again. As it stands you end up with calling
html_safe in lots of different places on every new string that's
introduced along the way, and therefore repeating yourself a lot.
Most developers will be calling html_safe far less often than the old h
method. So I'll gladly take that trade-off.
Also, don't make snap judgments on an implementation such as html_safe.
If you sure that it works the way you have described it, then fine.
Otherwise you're just going to confuse people. I highly recommend you
find a blog written by someone who actually knows how html_safe works. I
think you'll be pleasantly surprised by both its function and its