Nathaniel S. H. Brown wrote:
As I said before, I (or we, for whoever is in support) can solve the minor
details, and provide solutions with a little bit of creativity. I am of the
opinion that if you see points such as the ones you mentioned, you may also
be able to see how to fix them, if you so desire. I have some suggestions.

  
* Introducing this will break existing applications, which 
already make use of h, since h isn't idempotent.
    

As I said previously, this could be available as a configuration option,
negating your remark about breaking existing applications. You would have to
explicitly choose to break your own application. And where would that leave
you? Providing the option to enable the XSS security for those who do choose
for it. When enabled, the h function would be wiser at detecting what it is
that it's encoding.

One idea is to have a safe list of tags and html code which can be verified,
such as those found on the 
  
In order to implement this properly you'd need to do a HTML parse (including _javascript_!) of the string passed to h and validate that. Obviously, parsing HTML is overkill for performance. And it's still open whether the question "should something be escaped here" is decidable at all. I believe it isn't.
* And of course, it would severely hurt performance.
    

I wouldn't mind seeing a benchmark of <%= '<p>test</p> %> vs. <%=h
'<p>test</p>' %> to back this statement up. Understandably, the h method
does do a bit more. But how much more? And what about caching?
  
Nice try, but the proof obligation w.r.t. implementability and performance is on the proposer of the change.

Why don't you go ahead and implement a plugin that changes <%= semantics? Not that I would recommend it or give it a good chance of success in the community, but it's up to you if you want to put effort into this.

-- stefan

-- 
For rails performance tuning, see: http://railsexpress.de/blog
Subscription: http://railsexpress.de/blog/xml/rss20/feed.xml
_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

Reply via email to